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

需积分: 12 157 浏览量更新于2024-08-02 收藏 427KB PDF 举报

"GNU Coding Standards 是一套由 Richard Stallman 和其他 GNU 项目志愿者编写的编程规范，旨在确保 GNU 系统的整洁、一致性和易于安装。这份文档也作为编写可移植、健壮和可靠的程序的指南，虽然主要针对用 C 语言编写的程序，但其中的规则和原则对使用其他编程语言的开发者同样有价值。" GNU 编程标准详细内容： 1. **关于 GNU 编码标准** (About the GNU Coding Standards) - 这些标准的目的是提高 GNU 软件的质量，使代码更易读、更易于维护，并促进软件之间的兼容性。 2. **保持自由软件的自由** (Keeping Free Software Free) - **引用专有程序** (Referring to Proprietary Programs)：在文档中避免推崇或推荐专有软件，鼓励使用自由软件替代方案。 - **接受贡献** (Accepting Contributions)：当接收他人贡献的代码时，需确保这些代码符合 GNU 自由软件定义，允许用户自由使用、修改和分发。 - **商标** (Trademarks)：正确使用 GNU 项目的商标，以防止混淆和滥用。 3. **一般程序设计** (General Program Design) - **选择使用的语言** (Which Languages to Use)：根据项目需求和目标来决定使用哪种语言，通常建议使用 C 语言，因为它具有高效且跨平台的特性。 - **与其他实现的兼容性** (Compatibility with Other Implementations)：考虑程序与不同系统和库的兼容性，确保广泛适用性。 - **使用非标准特性** (Using Non-standard Features)：除非必要，否则应避免使用特定编译器的非标准扩展，以保持代码的可移植性。 - **标准 C 与 pre-standard C** (Standard C and Pre-Standard C)：优先使用标准 C，避免依赖旧版本的 C 语言特性。 - **条件编译** (Conditional Compilation)：合理使用条件编译指令，以处理不同的编译环境和目标平台。 4. **所有程序的行为** (Program Behavior for All Programs) - **非 GNU 标准** (Non-GNU Standards)：尽管 GNU 规范是指导方针，但也应遵循其他行业认可的标准和最佳实践。 - **编写健壮程序** (Writing Robust Programs)：确保程序在各种输入和异常情况下都能正确运行，通过错误检查、异常处理和边界条件测试来增强程序的健壮性。以上内容仅仅是 GNU 编程标准的一部分，实际标准还包括更多的章节，如源代码格式化、程序错误报告、文档编写、版权和许可证声明等。这些规定不仅适用于 GNU 项目，也被许多其他开源软件项目采纳，成为了编写高质量软件的重要参考。

Chapter 4: Program Behavior for All Programs 10

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 X Windows 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 CORBA interface (for use from GNOME), 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

Chapter 4: Program Behavior for All Programs 11

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.8 [Option Table], page 13).

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

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.

Chapter 4: Program Behavior for All Programs 12

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 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 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/Guile

GNU GPL with the exception for Guile; for example, GPLv3+/Guile means the

GNU GPL version 3 or later, with the extra exception for Guile.

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/.

Chapter 4: Program Behavior for All Programs 13

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 Table of Long Options

Here is a table of long options used by GNU programs. It is surely incomplete, but we aim

to list all the options that a new program might want to be compatible with. If you use

names not already in the table, please send bug-standards@gnu.org a list of them, with

their meanings, so we can update the table.

‘after-date’

‘-N’ in tar.

‘all’ ‘-a’ in du, ls, nm, stty, uname, and unexpand.

‘all-text’

‘-a’ in diff.

‘almost-all’

‘-A’ in ls.

‘append’ ‘-a’ in etags, tee, time; ‘-r’ in tar.

‘archive’ ‘-a’ in cp.

‘archive-name’

‘-n’ in shar.

剩余83页未读，继续阅读

Killin10

粉丝: 5
资源: 7

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

GNU Coding Standards.pdf

C-2015-GNU Coding Standards

GNU Coding Standards(C/C++)

GNU编码标准

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

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

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

GNU Autoconf, Automake, Libtool 1.4.4 Unofficial Edition

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

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

最新资源