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

需积分: 9 36 浏览量更新于2024-07-31 收藏 431KB PDF 举报

"GNU Coding Standards" GNU编码标准是Richard Stallman等人于1992年至2010年间制定的一套编程规范，旨在确保GNU项目及其软件的自由、质量和可维护性。这些标准涵盖了许多方面，包括但不限于如何编写代码、如何处理第三方贡献、以及如何保证程序的兼容性和健壮性。 1. 关于GNU Coding Standards GNU编码标准不仅是一套技术指导，还涉及到对自由软件的哲学。它强调了保持软件自由的重要性，包括在文档和代码中不引用专有软件，以便不鼓励或间接支持非自由软件的使用。此外，标准还规定了如何接受和处理来自社区的贡献，以确保所有添加的代码都符合自由软件的定义。 2. 保持自由软件的自由 - Referring to Proprietary Programs：开发者应避免在源代码、文档或用户界面中直接提及或推荐专有软件。这有助于防止用户对专有软件产生依赖，保持软件生态的自由。 - Accepting Contributions：为了保证软件的自由，接收第三方贡献时，需要确保这些贡献符合GNU GPL等自由软件许可证的要求，并要求贡献者同意这些条款。 - Trademarks：尊重商标权，但不应使用它们来暗示与专有软件的官方关系。 3. 通用程序设计 - Which Languages to Use：根据项目的需要，选择最合适的编程语言，通常首选是C语言，因为它是GNU项目的基础，且具有良好的移植性。 - Compatibility with Other Implementations：如果可能，应尽量使代码与其他实现兼容，以促进互操作性和用户的选择。 - Using Non-standard Features：避免使用特定编译器的非标准扩展，以提高跨平台兼容性和可移植性。 - Standard C and Pre-Standard C：优先使用标准C，避免使用过时的非标准特性，以确保长期的代码稳定性和可维护性。 - Conditional Compilation：合理使用条件编译，以适应不同的操作系统和硬件平台。 4. 所有程序的程序行为 - Non-GNU Standards：尽管是GNU的标准，但也考虑了其他标准，如POSIX，以增加软件的广泛适用性。 - Writing Robust Programs：编写强壮的程序至关重要，包括错误处理、内存管理、并发安全等，以确保软件在各种情况下都能正确运行。 GNU编码标准是一个详尽的指南，不仅关注技术实现，还关注软件的道德和社会影响。它鼓励开发者遵循一套统一的实践，以增强代码的可读性、可维护性，同时也体现了自由软件运动的核心价值观。通过遵循这些标准，开发者可以为创建一个更开放、更自由的软件世界做出贡献。

Chapter 4: Program Behavior for All Programs 10

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

program:source-file-name: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.

Likewise, please don’t make the behavior of the program depend on the type of output

device it is used with. 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.

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.

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 and the GTK+ 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

Chapter 4: Program Behavior for All Programs 11

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.

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.

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

Chapter 4: Program Behavior for All Programs 12

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 abbrevations 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.)

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

Section 5.8 [Internationalization], page 41). 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 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.

Chapter 4: Program Behavior for All Programs 13

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://www.perlfoundation.org/legal.

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://www.python.org/2.0.1/license.html.

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.

4.7.2 ‘--help’

The standard --help option should output brief documentation for how to invoke the

program, on standard output, then exit successfully. Other options and arguments should

be ignored once this is seen, and the program should not perform its normal function.

Near the end of the ‘--help’ option’s output, please place lines giving the email address

for bug reports, the package’s home page (normally http://www.gnu.org/software/pkg,

and the general page for help using GNU programs. The format should be like this:

Report bugs to: mailing-address

pkg home page: <http://www.gnu.org/software/pkg/>

General help using GNU software: <http://www.gnu.org/gethelp/>

It is ok to mention other appropriate mailing lists and web pages.

4.8 Standards for Dynamic Plug-in Interfaces

Another aspect of keeping free programs free is encouraging development of free plug-ins,

and discouraging development of proprietary plug-ins. Many GNU programs will not have

anything like plug-ins at all, but those that do should follow these practices.

First, the general plug-in architecture design should closely tie the plug-in to the original

code, such that the plug-in and the base program are parts of one extended program. For

剩余84页未读，继续阅读

newton_liu

粉丝: 1
资源: 9

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

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

GNU编程规范：构建可靠与可移植的软件指南

GNU Autoconf, Automake, Libtool 1.4.4 Unofficial Edition

GNU Coding Standards.pdf

C-2015-GNU Coding Standards

GNU Coding Standards(C/C++)

GNU编码标准

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

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

GNU编程规范：编写可靠且兼容的自由软件

最新资源