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

需积分: 9 169 浏览量更新于2024-08-02 收藏 344KB PDF 举报

"GNU编码规范" GNU编码规范是由理查德·斯托曼和其他GNU项目志愿者编写的，旨在使GNU系统保持整洁、一致，并易于安装。这份文档也可以作为编写可移植、健壮且可靠的程序的指南。它主要关注用C语言编写的程序，但其中的许多规则和原则对使用其他编程语言的开发者也同样有指导价值。规范中通常会说明按照特定方式编写代码的理由。在"GNU Coding Standards"中，涵盖了多个方面的内容： 1. **关于GNU编码规范**：这份文档不仅关注代码的编写方式，也强调了保持自由软件自由的重要性。它提供了指导方针，以确保软件的开源和可共享性质不会因为开发实践而受到限制。 2. **保持自由软件的自由**： - **引用专有软件**：鼓励开发者避免在文档和代码中直接引用专有软件，以免暗示对专有软件的依赖或认可。 - **接受贡献**：规定了接收和整合外部贡献的规则，以确保所有贡献都符合自由软件的许可证要求。 - **商标**：提醒开发者尊重并正确使用商标，以免引起法律问题。 3. **一般程序设计**： - **使用哪种语言**：推荐使用C语言，因为它具有广泛兼容性和高效的性能。 - **与其他实现的兼容性**：建议考虑程序与其他实现的兼容性，以增加其普遍适用性。 - **使用非标准特性**：尽管C语言有扩展，但应谨慎使用，避免降低程序的可移植性。 - **标准C与预标准C**：鼓励使用标准C，以确保代码的可读性和可维护性。 - **条件编译**：提倡使用条件编译来处理不同平台的差异，但要避免过度使用。 4. **所有程序的程序行为**： - **编写健壮的程序**：提倡编写能够处理异常情况、内存管理和错误处理的程序，以提高稳定性。 - **库的行为**：库应提供一致的行为，无论是在哪个平台上运行，以增强可预测性。 - **格式化错误消息**：强调错误消息应清晰易懂，方便用户理解和解决问题。这些标准和指导原则旨在提升软件的质量，保证代码的可读性、可维护性和可移植性。遵循这些规范的开发者可以创建出更可靠、更易于协作的软件，同时促进整个开源社区的健康发展。

Chapter 4: Program Behavior for All Programs 9

program :source-file-name :lineno : message

when there is an appropriate source ﬁle, or like this:

program : message

when there is no relevant source ﬁle.

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 mess ages ,

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

4.4 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 b e havior 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.5 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”).

Chapter 4: Program Behavior for All Programs 10

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.6 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 c ommon long-option names when you choose the option names for your

program (see Section 4.7 [Option Table], page 12).

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 idiosyncracies 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 inokving ‘p.cgi --help’ from the command line.

--version

This option should direct the program to print information about its name,

version, origin and legal status, all on standard output, and then exit success-

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

program should not p erform 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.

Chapter 4: Program Behavior for All Programs 11

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 men-

tion 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 brief statement that the program is free software, and that

users are free to copy and change it on certain conditions. If the program is

covered by the GNU GPL, say so here. Also mention that there is no warranty,

to the extent permitted by law.

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 Emacs 19.34.5

GNU Emacs comes with NO WARRANTY,

to the extent permitted by law.

You may redistribute copies of GNU Emacs

under the terms of the GNU General Public License.

For more information about these matters,

see the files named COPYING.

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

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.

Translations of the above lines must preserve the validity of the copyright no-

tices (see Section 5.8 [Internationalization], page 38). If the translation’s char-

acter set supports it, the ‘(C)’ should be replaced with the copyright symbol,

as follows:



剩余75页未读，继续阅读

napuolunllm

粉丝: 7
资源: 189

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最新版更新详情及版权授权

最新资源