"GNU编码规范文档：C-2015最新版更新详情及版权授权"

需积分: 0 17 浏览量更新于2024-03-23 收藏 430KB PDF 举报

The GNU Coding Standards, last updated on April 23, 2015, is a comprehensive document created by Richard Stallman and his team. It serves as a set of guidelines for developers to adhere to when writing code for GNU software. The standards cover a wide range of topics, including file formats, naming conventions, indentation, and documentation. One of the key principles emphasized in the GNU Coding Standards is compatibility with GNU tools and libraries. This ensures that code written following these standards can easily integrate with existing GNU software. Additionally, the document promotes portability by encouraging developers to write code that is compatible with multiple platforms and operating systems. The GNU Coding Standards also place a strong emphasis on clarity and readability. It recommends using meaningful variable names, comments, and consistent formatting to make the code easier to understand for other developers. This not only improves the maintainability of the code but also makes it easier for newcomers to contribute to GNU projects. Another important aspect of the GNU Coding Standards is licensing and copyright. The document clarifies the rights and responsibilities of developers regarding the use and distribution of GNU software. It also specifies the terms of the GNU Free Documentation License, under which the coding standards document is distributed. Overall, the GNU Coding Standards play a crucial role in maintaining the quality and integrity of GNU software. By following these guidelines, developers can create code that is not only compatible and portable but also well-documented and easily understandable. This contributes to the success and continued growth of the GNU project as a whole.

Chapter 4: Program Behavior for All Programs 10

program: message

when there is no relevant source ﬁle.

If you want to mention the column number, use this format:

program:sourcefile:lineno:column: message

In an interactive program (one that is reading commands from a terminal), it is better

not to include the program name in an error message. The place to indicate which program

is running is in the prompt or with the screen layout. (When the same program runs with

input from a source other than a terminal, it is not interactive and would do best to print

error messages using the noninteractive style.)

The string message should not begin with a capital letter when it follows a program name

and/or ﬁle name, because that isn’t the beginning of a sentence. (The sentence conceptually

starts at the beginning of the line.) Also, it should not end with a period.

Error messages from interactive programs, and other messages such as usage messages,

should start with a capital letter. But they should not end with a period.

4.5 Standards for Interfaces Generally

Please don’t make the behavior of a utility depend on the name used to invoke it. It is

useful sometimes to make a link to a utility with a diﬀerent name, and that should not

change what it does.

Instead, use a run time option or a compilation switch or both to select among the

alternate behaviors. You can also build two versions of the program, with diﬀerent names

and diﬀerent default behaviors.

Likewise, please don’t make the behavior of a command-line program depend on the type

of output device it gets as standard output or standard input. Device independence is an

important principle of the system’s design; do not compromise it merely to save someone

from typing an option now and then. (Variation in error message syntax when using a

terminal is ok, because that is a side issue that people do not depend on.)

If you think one behavior is most useful when the output is to a terminal, and another

is most useful when the output is a ﬁle or a pipe, then it is usually best to make the default

behavior the one that is useful with output to a terminal, and have an option for the other

behavior. You can also build two diﬀerent versions of the program with diﬀerent names.

There is an exception for programs whose output in certain cases is binary data. Sending

such output to a terminal is useless and can cause trouble. If such a program normally sends

its output to stdout, it should detect, in these cases, when the output is a terminal and give

an error message instead. The -f option should override this exception, thus permitting

the output to go to the terminal.

Compatibility requires certain programs to depend on the type of output device. It

would be disastrous if ls or sh did not do so in the way all users expect. In some of these

cases, we supplement the program with a preferred alternate version that does not depend

on the output device type. For example, we provide a dir program much like ls except

that its default output format is always multi-column format.

Chapter 4: Program Behavior for All Programs 11

4.6 Standards for Graphical Interfaces

When you write a program that provides a graphical user interface, please make it work

with the X Window System, using the GTK+ toolkit or the GNUstep toolkit, unless the

functionality speciﬁcally requires some alternative (for example, “displaying jpeg images

while in console mode”).

In addition, please provide a command-line interface to control the functionality. (In

many cases, the graphical user interface can be a separate program which invokes the

command-line program.) This is so that the same jobs can be done from scripts.

Please also consider providing a D-bus interface for use from other running programs,

such as within GNOME. (GNOME used to use CORBA for this, but that is being phased

out.) In addition, consider providing a library interface (for use from C), and perhaps a

keyboard-driven console interface (for use by users from console mode). Once you are doing

the work to provide the functionality and the graphical interface, these won’t be much extra

work.

Please make your program interoperate with access technology such as screen readers (see

http://www.gnu.org/accessibility/accessibility.html). This should be automatic

if you use GTK+.

4.7 Standards for Command Line Interfaces

It is a good idea to follow the POSIX guidelines for the command-line options of a program.

The easiest way to do this is to use getopt to parse them. Note that the GNU version

of getopt will normally permit options anywhere among the arguments unless the special

argument ‘--’ is used. This is not what POSIX speciﬁes; it is a GNU extension.

Please deﬁne long-named options that are equivalent to the single-letter Unix-style op-

tions. We hope to make GNU more user friendly this way. This is easy to do with the GNU

function getopt_long.

One of the advantages of long-named options is that they can be consistent from program

to program. For example, users should be able to expect the “verbose” option of any GNU

program which has one, to be spelled precisely ‘--verbose’. To achieve this uniformity,

look at the table of common long-option names when you choose the option names for your

program (see Section 4.9 [Option Table], page 14).

It is usually a good idea for ﬁle names given as ordinary arguments to be input ﬁles only;

any output ﬁles would be speciﬁed using options (preferably ‘-o’ or ‘--output’). Even if

you allow an output ﬁle name as an ordinary argument for compatibility, try to provide

an option as another way to specify it. This will lead to more consistency among GNU

utilities, and fewer idiosyncrasies for users to remember.

All programs should support two standard options: ‘--version’ and ‘--help’. CGI

programs should accept these as command-line options, and also if given as the PATH_INFO;

for instance, visiting ‘http://example.org/p.cgi/--help’ in a browser should output the

same information as invoking ‘p.cgi --help’ from the command line.

4.7.1 --version

The standard --version option should direct the program to print information about its

name, version, origin and legal status, all on standard output, and then exit successfully.

Chapter 4: Program Behavior for All Programs 12

Other options and arguments should be ignored once this is seen, and the program should

not perform its normal function.

The ﬁrst line is meant to be easy for a program to parse; the version number proper

starts after the last space. In addition, it contains the canonical name for this program, in

this format:

GNU Emacs 19.30

The program’s name should be a constant string; don’t compute it from argv[0]. The idea

is to state the standard or canonical name for the program, not its ﬁle name. There are

other ways to ﬁnd out the precise ﬁle name where a command is found in PATH.

If the program is a subsidiary part of a larger package, mention the package name in

parentheses, like this:

emacsserver (GNU Emacs) 19.30

If the package has a version number which is diﬀerent from this program’s version number,

you can mention the package version number just before the close-parenthesis.

If you need to mention the version numbers of libraries which are distributed separately

from the package which contains this program, you can do so by printing an additional line

of version info for each library you want to mention. Use the same format for these lines as

for the ﬁrst line.

Please do not mention all of the libraries that the program uses “just for completeness”—

that would produce a lot of unhelpful clutter. Please mention library version numbers only

if you ﬁnd in practice that they are very important to you in debugging.

The following line, after the version number line or lines, should be a copyright notice.

If more than one copyright notice is called for, put each on a separate line.

Next should follow a line stating the license, preferably using one of abbreviations below,

and a brief statement that the program is free software, and that users are free to copy and

change it. Also mention that there is no warranty, to the extent permitted by law. See

recommended wording below.

It is ok to ﬁnish the output with a list of the major authors of the program, as a way of

giving credit.

Here’s an example of output that follows these rules:

GNU hello 2.3

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

You should adapt this to your program, of course, ﬁlling in the proper year, copyright

holder, name of program, and the references to distribution terms, and changing the rest of

the wording as necessary.

This copyright notice only needs to mention the most recent year in which changes were

made—there’s no need to list the years for previous versions’ changes. You don’t have to

mention the name of the program in these notices, if that is inconvenient, since it appeared

in the ﬁrst line. (The rules are diﬀerent for copyright notices in source ﬁles; see Section

“Copyright Notices” in Information for GNU Maintainers.)

Chapter 4: Program Behavior for All Programs 13

Translations of the above lines must preserve the validity of the copyright notices (see

Section 5.8 [Internationalization], page 40). If the translation’s character set supports it,

the ‘(C)’ should be replaced with the copyright symbol, as follows:



Write the word “Copyright” exactly like that, in English. Do not translate it into another

language. International treaties recognize the English word “Copyright”; translations into

other languages do not have legal signiﬁcance.

Finally, here is the table of our suggested license abbreviations. Any abbreviation can

be followed by ‘vversion[+]’, meaning that particular version, or later versions with the

‘+’, as shown above. In the case of a GNU license, always indicate the permitted versions

in this way.

In the case of exceptions for extra permissions with the GPL, we use ‘/’ for a separator;

the version number can follow the license abbreviation as usual, as in the examples below.

GPL GNU General Public License, http://www.gnu.org/licenses/gpl.html.

LGPL GNU Lesser General Public License, http://www.gnu.org/licenses/lgpl.

html.

GPL/Ada GNU GPL with the exception for Ada.

Apache The Apache Software Foundation license, http://www.apache.org/licenses.

Artistic The Artistic license used for Perl, http: / / dev . perl . org / licenses /

artistic.html.

Expat The Expat license, http://www.jclark.com/xml/copying.txt.

MPL The Mozilla Public License, http://www.mozilla.org/MPL/.

OBSD The original (4-clause) BSD license, incompatible with the GNU GPL http://

www.xfree86.org/3.3.6/COPYRIGHT2.html#6.

PHP The license used for PHP, http://www.php.net/license/.

public domain

The non-license that is being in the public domain, http://www.gnu.org/

licenses/license-list.html#PublicDomain.

Python The license for Python, http: / / directory . fsf . org / wiki ?

title=License:Python2.0.1.

RBSD The revised (3-clause) BSD, compatible with the GNU GPL,

http://www.xfree86.org/3.3.6/COPYRIGHT2.html#5.

X11 The simple non-copyleft license used for most versions of the X Window System,

http://www.xfree86.org/3.3.6/COPYRIGHT2.html#3.

Zlib The license for Zlib, http://www.gzip.org/zlib/zlib_license.html.

More information about these licenses and many more are on the GNU licensing web

pages, http://www.gnu.org/licenses/license-list.html.

剩余84页未读，继续阅读

加菲猫0320

粉丝: 3
资源: 34

"GNU编码规范文档：C-2015最新版更新详情及版权授权"

GNU Coding Standards

GNU Coding Standards.pdf

GNU Coding Standards(C/C++)

GNU编码标准

ASP、PHP、JAVA、gnu、VB、VC、c语言编码规范.zip

linux下C语言工程模板，使用gcc编译.zip

automake-1.4-p6.tar.gz

automake16-1.6.3-18.el6.1.noarch.rpm

遵循GNU编码标准，打造专业C语言规范

GNU编码标准：自由软件的规范指南

最新资源