遵循GNU编程规范：自由软件设计指南

需积分: 10 135 浏览量更新于2024-07-29 收藏 429KB PDF 举报

GNU编程规范是一份由Richard Stallman等人维护的官方文档，最后一次更新日期为2012年1月8日。这份规范旨在为GNU项目的开发者提供一套一致的编码标准，确保代码的质量、可读性和自由软件原则的遵循。该规范主要关注以下几个方面： 1. **关于GNU编码规范**：本规范不仅是一个技术指南，还强调了自由软件的精神。它倡导在编程时，不要直接引用专有程序，以保持软件的自由性。同时，鼓励接受来自社区的贡献，并尊重版权和商标规则。 2. **通用程序设计原则**： - **选择语言**：鼓励使用标准C或预标准C，因为它们具有广泛的兼容性和长久的生命周期，能保证代码的可移植性。 - **兼容性**：为了支持不同实现之间的互操作性，开发者需注意遵循跨平台的编程实践。 - **非标准特性**：尽管非标准特性可能在某些情况下有用，但建议避免过度依赖，以确保代码的广泛接受和长期支持。 - **条件编译**：提倡使用条件编译来处理不同平台或版本差异，但要保持代码简洁，避免不必要的复杂性。 3. **程序行为的一致性**： - **非GNU标准遵循**：尽管GNU项目可能有自己的特定偏好，但开发者应尽量遵循主流标准，以便与更广泛的用户群体和工具交互。 - **编写清晰易读的代码**：强调代码的可读性、可维护性和文档化，这对于任何项目都是至关重要的，尤其是自由软件，需要其他开发者能够轻松理解和修改。 4. **版权和许可**：规范附带了GNU Free Documentation License，允许在指定条件下复制、分发和修改文档，保证了信息的自由传播。 GNU编程规范是开发GNU项目时必须参考的重要文档，它结合了技术指导和社区价值观，帮助开发者写出高质量、遵循自由软件原则的代码。遵循这些规范有助于确保项目的一致性，增强代码的可读性和可维护性，同时也促进了开源软件生态系统的健康发展。

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.

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.

Chapter 4: Program Behavior for All Programs 11

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.

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:

Chapter 4: Program Behavior for All Programs 12

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.

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.

Chapter 4: Program Behavior for All Programs 13

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

剩余83页未读，继续阅读

天天向上_好好学习

粉丝: 261
资源: 14

遵循GNU编程规范：自由软件设计指南

gun c语言 编码标准

GUN.Linux.编程指南(第二版)

GUN_linux编程指南及源代码

GUN parted如何使用

如何安装GUN Nano

如何在VScode中实现C++的GUN工具环境

怎么进入gun gradio官网

gun make中文手册 ver3.8

如何在VScode中实现GUN工具环境

学习gun emacs

最新资源

gun c语言编码标准