GNU coding standards

From Wikipedia for FEVERv2
Jump to navigation Jump to search

The GNU coding standards are a set of rules and guidelines for writing programs that work consistently within the GNU system. GNU coding standards_sentence_0

The GNU Coding Standards were written by Richard Stallman and other GNU Project volunteers. GNU coding standards_sentence_1

The standards document is part of the GNU Project and is available from the GNU website. GNU coding standards_sentence_2

Though it focuses on writing free software for GNU in C, much of it can be applied more generally. GNU coding standards_sentence_3

In particular, the GNU Project encourages its contributors to always try to follow the standards—whether or not their programs are implemented in C. GNU coding standards_sentence_4

Code formatting GNU coding standards_section_0

The GNU Coding Standards specify exactly how to format most C programming language constructs. GNU coding standards_sentence_5

Here is a characteristic example: GNU coding standards_sentence_6

The consistent treatment of blocks as statements (for the purpose of indentation) is a very distinctive feature of the GNU C code formatting style; as is the mandatory space before parentheses. GNU coding standards_sentence_7

All code formatted in the GNU style has the property that each closing brace, bracket or parenthesis appears to the right of its corresponding opening delimiter, or in the same column. GNU coding standards_sentence_8

As a general principle, GNU Emacs can be considered a reliable authority on the GNU code formatting style. GNU coding standards_sentence_9

As such, it is desirable that any piece of code that looks ugly when indented by Emacs is changed into a more Emacs-friendly form—for example, by inserting additional parentheses. GNU coding standards_sentence_10

Splitting long lines GNU coding standards_section_1

"When you split an expression into multiple lines, split it before an operator, not after one." GNU coding standards_sentence_11

For example: GNU coding standards_sentence_12

Comments GNU coding standards_section_2

The standards greatly emphasise the importance of English-language comments: GNU coding standards_sentence_13

Comments should consist of complete, capitalized sentences, each followed by two spaces (so that Emacs can tell where one sentence ends and the next begins). GNU coding standards_sentence_14

For long or complex preprocessor conditionals, every #else and #endif should have a comment explaining the condition for the code below (for #else) or above (for #endif). GNU coding standards_sentence_15

Files GNU coding standards_section_3

The standards require that all programs be able to operate when /usr and /etc are mounted read-only. GNU coding standards_sentence_16

Therefore, files that are modified for internal purposes (log files, lock files, temporary files, etc.) should not be stored in either /usr or /etc. GNU coding standards_sentence_17

An exception is made for programs whose job it is to update system configuration files in /etc. GNU coding standards_sentence_18

Another exception is made for storing files in a directory when the user has explicitly asked to modify a file in the same directory. GNU coding standards_sentence_19

Portability GNU coding standards_section_4

The GNU Coding Standards define the issue of portability in this way: portability in the Unix world means 'between Unixes'; in a GNU program this kind of portability is desirable, but not vitally important. GNU coding standards_sentence_20

According to the standard, portability problems are very limited as GNU programs are designed to be compiled with one compiler, the GNU C Compiler, and only run on one system, which is the GNU system. GNU coding standards_sentence_21

There is one form of portability problem though, and that is the fact that the standard makes it clear that a program should run on different CPU types. GNU coding standards_sentence_22

The standard says that GNU doesn't and won't support 16-bit systems, but handling all the different 32- and 64-bit systems is absolutely necessary. GNU coding standards_sentence_23

Criticism GNU coding standards_section_5

The GNU coding standards are primarily used by GNU projects, though its use is not limited to GNU projects alone. GNU coding standards_sentence_24

The Linux kernel strongly discourages this style for kernel code, and refers to the style pejoratively: "First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. GNU coding standards_sentence_25

Burn them, it’s a great symbolic gesture.". GNU coding standards_sentence_26

Steve McConnell, in his book Code Complete, also advises against using this style; he marks a code sample which uses it with a "Coding Horror" icon, symbolizing especially dangerous code, and states that it impedes readability. GNU coding standards_sentence_27

See also GNU coding standards_section_6

GNU coding standards_unordered_list_0

Credits to the contents of this page go to the authors of the corresponding Wikipedia page: coding standards.