Content deleted Content added
merge from Gnits standards |
|||
| (31 intermediate revisions by 25 users not shown) | |||
Line 1:
{{
{{about||the quantum error correcting code|gnu code}}
The '''GNU Coding Standards''' are a set of rules and guidelines for writing [[computer program|program]]s that work consistently within the [[GNU]] system. The GNU Coding Standards were written by [[Richard Stallman]] and other GNU Project volunteers. The standards document is part of the [[GNU Project]] and is available from the GNU website [http://www.gnu.org/prep/standards/]. Though it focuses on writing [[free software]] for GNU in [[C (programming language)|C]], much of it can be applied more generally. In particular, the GNU Project encourages its contributors to always try to follow the standards—whether or not their programs are implemented in C. The C code formatting style is well-known within the [[free software community]], but of course, anyone can choose to follow it.▼
▲The '''GNU
==Code formatting==
Line 6 ⟶ 8:
The GNU Coding Standards specify exactly how to format most [[C (programming language)|C programming language]] constructs. Here is a characteristic example:
<
int
main (int argc, char *argv[])
Line 43 ⟶ 45:
return 0;
}
</syntaxhighlight>
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. 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.
===Splitting long lines===
"When you split an expression into multiple lines, split it before an operator, not after one."<ref>{{Cite web|url=https://www.gnu.org/prep/standards/standards.html#Formatting|title=GNU Coding Standards|website=www.gnu.org|language=en|access-date=2020-11-29}}</ref>
For example:
<syntaxhighlight lang="c">
if (foo_this_is_long && bar > win (x, y, z)
&& remaining_condition)
</syntaxhighlight>
==Comments==
Line 70 ⟶ 81:
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 [[Central processing unit|CPU]] types. 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.
== Gnits standards ==
The Gnits standards are a collection of [[Standardization|standards]] and recommendations for programming, maintaining, and distributing [[software]]. They are published by a group of [[GNU project]] maintainers who call themselves "Gnits", which is short for "GNU nit-pickers". As such, they represent advice, not [[Free Software Foundation]] or [[GNU]] policy, but parts of the Gnits' standards have seen widespread adoption among [[free software]] programmers in general.
The Gnits standards are extensions to, refinements of, and annotations for the [[GNU Standards]]. However, they are in no way normative in GNU; GNU maintainers are not required to follow them. Nevertheless, maintainers and programmers often find in Gnits standards good ideas on the way to follow GNU Standards themselves, as well as tentative, non-official explanations about why some GNU standards were decided the way they are. There are very few discrepancies between Gnits and GNU standards, and they are always well noted as such.
The standards address aspects of [[software architecture]], program behaviour, [[human–computer interaction]], [[C (computer language)|C]] programming, [[Software documentation|documentation]], and [[Software release|software releases]].
As of 2008, the Gnits standards carry a notice that they are moribund and no longer actively maintained, and points readers to the manuals of [[Gnulib]], [[Autoconf]], and [[Automake]], which are said to cover many of the same topics.
== Criticism ==
The GNU coding standards are primarily used by GNU projects, though its use is not limited to GNU projects alone.
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. Burn them, it’s a great symbolic gesture.".<ref>{{Cite web|url=https://www.kernel.org/doc/html/v4.10/process/coding-style.html|title=Linux kernel coding style — The Linux Kernel documentation|website=www.kernel.org|language=en|access-date=2017-10-12}}</ref> [[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 by requiring an extra level of indentation for braces.<ref>{{cite book |title=Code Complete: A practical handbook of software construction |last=McConnell |first=Steve |publisher=Microsoft Press |year=2004 |isbn=0-7356-1967-0 |___location=Redmond, WA |pages=[https://archive.org/details/codecomplete0000mcco/page/746 746–747] |author-link=Steve McConnell |url=https://archive.org/details/codecomplete0000mcco/page/746 }}</ref>
== See also ==
{{Portal|Free and open-source software}}
==References==
▲*[[Gnits Standards]]
{{Reflist}}
==External links==
* [
* [https://web.archive.org/web/20090304122402/http://www.ronancrowley.com/Eclipse_GNU_Style.xml Eclipse Code Style Formatter for GNU Coding Standards]
{{DEFAULTSORT:Gnu Coding Standards}}
| |||