@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate April 9, 2006
+@set lastupdate August 19, 2006
@c %**end of header
@dircategory GNU organization
2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.1
+under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no
Front-Cover Texts, and with no Back-Cover Texts.
(preferably @samp{-o} or @samp{--output}). Even if you allow an output
file 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.
+among GNU utilities, and fewer idiosyncrasies for users to remember.
@cindex standard command-line options
@cindex options, standard command-line
@item socket
Specify a file descriptor for a network server to use for its socket,
instead of opening and binding a new socket. This provides a way to
-run, in a nonpriveledged process, a server that normally needs a
+run, in a non-privileged process, a server that normally needs a
reserved port number.
@item sort
name} for the package. The text domain name is used to separate the
translations for this package from the translations for other packages.
Normally, the text domain name should be the same as the name of the
-package---for example, @samp{fileutils} for the GNU file utilities.
+package---for example, @samp{coreutils} for the GNU core utilities.
@cindex message text, and internationalization
To enable gettext to work well, avoid writing code that makes
Here is an example of what not to do:
-@example
-printf ("%d file%s processed", nfiles,
- nfiles != 1 ? "s" : "");
-@end example
+@smallexample
+printf ("%s is full", capacity > 5000000 ? "disk" : "floppy disk");
+@end smallexample
-@noindent
-The problem with that example is that it assumes that plurals are made
-by adding `s'. If you apply gettext to the format string, like this,
+If you apply gettext to all strings, like this,
-@example
-printf (gettext ("%d file%s processed"), nfiles,
- nfiles != 1 ? "s" : "");
-@end example
+@smallexample
+printf (gettext ("%s is full"),
+ capacity > 5000000 ? gettext ("disk") : gettext ("floppy disk"));
+@end smallexample
@noindent
-the message can use different words, but it will still be forced to use
-`s' for the plural. Here is a better way:
+the translator will hardly know that "disk" and "floppy disk" are meant to
+be substituted in the other string. Worse, in some languages (like French)
+the construction will not work: the translation of the word "full" depends
+on the gender of the first part of the sentence; it happens to be not the
+same for "disk" as for "floppy disk".
-@example
-printf ((nfiles != 1 ? "%d files processed"
- : "%d file processed"),
- nfiles);
-@end example
-
-@noindent
-This way, you can apply gettext to each of the two strings
-independently:
+Complete sentences can be translated without problems:
@example
-printf ((nfiles != 1 ? gettext ("%d files processed")
- : gettext ("%d file processed")),
- nfiles);
+printf (capacity > 5000000 ? gettext ("disk is full")
+ : gettext ("floppy disk is full"));
@end example
-@noindent
-This can be any method of forming the plural of the word for ``file'', and
-also handles languages that require agreement in the word for
-``processed''.
-
A similar problem appears at the level of sentence structure with this
code:
Adding @code{gettext} calls to this code cannot give correct results for
all languages, because negation in some languages requires adding words
at more than one place in the sentence. By contrast, adding
-@code{gettext} calls does the job straightfowardly if the code starts
+@code{gettext} calls does the job straightforwardly if the code starts
out like this:
@example
: "# Implicit rule search has not been done.\n");
@end example
+Another example is this one:
+
+@example
+printf ("%d file%s processed", nfiles,
+ nfiles != 1 ? "s" : "");
+@end example
+
+@noindent
+The problem with this example is that it assumes that plurals are made
+by adding `s'. If you apply gettext to the format string, like this,
+
+@example
+printf (gettext ("%d file%s processed"), nfiles,
+ nfiles != 1 ? "s" : "");
+@end example
+
+@noindent
+the message can use different words, but it will still be forced to use
+`s' for the plural. Here is a better way, with gettext being applied to
+the two strings independently:
+
+@example
+printf ((nfiles != 1 ? gettext ("%d files processed")
+ : gettext ("%d file processed")),
+ nfiles);
+@end example
+
+@noindent
+But this still doesn't work for languages like Polish, which has three
+plural forms: one for nfiles == 1, one for nfiles == 2, 3, 4, 22, 23, 24, ...
+and one for the rest. The GNU @code{ngettext} function solves this problem:
+
+@example
+printf (ngettext ("%d files processed", "%d file processed", nfiles),
+ nfiles);
+@end example
+
@node Character Set
@section Character Set
converted automatically into Texinfo. It is ok to produce the Texinfo
documentation by conversion this way, as long as it gives good results.
-Programmers often find it most natural to structure the documentation
-following the structure of the implementation, which they know. But
-this structure is not necessarily good for explaining how to use the
-program; it may be irrelevant and confusing for a user.
-
-At every level, from the sentences in a paragraph to the grouping of
-topics into separate manuals, the right way to structure documentation
-is according to the concepts and questions that a user will have in mind
-when reading it. Sometimes this structure of ideas matches the
+Make sure your manual is clear to a reader who knows nothing about the
+topic and reads it straight through. This means covering basic topics
+at the beginning, and advanced topics only later. This also means
+defining every specialized term when it is first used.
+
+Programmers tend to carry over the structure of the program as the
+structure for its documentation. But this structure is not
+necessarily good for explaining how to use the program; it may be
+irrelevant and confusing for a user.
+
+Instead, the right way to structure documentation is according to the
+concepts and questions that a user will have in mind when reading it.
+This principle applies at every level, from the lowest (ordering
+sentences in a paragraph) to the highest (ordering of chapter topics
+within the manual). Sometimes this structure of ideas matches the
structure of the implementation of the software being documented---but
-often they are different. Often the most important part of learning to
-write good documentation is learning to notice when you are structuring
-the documentation like the implementation, and think about better
-alternatives.
+often they are different. An important part of learning to write good
+documentation is to learn to notice when you have unthinkingly
+structured the documentation like the implementation, stop yourself,
+and look for better alternatives.
For example, each program in the GNU system probably ought to be
documented in one manual; but this does not mean each program should
a computer program. Please use ``invalid'' for this, and reserve the
term ``illegal'' for activities prohibited by law.
+Please do not write @samp{()} after a function name just to indicate
+it is a function. @code{foo ()} is not a function, it is a function
+call with no arguments.
+
@node Doc Strings and Manuals
@section Doc Strings and Manuals
variables. The previous descriptions of functions and variables in the
section will also have given information about the topic. A description
written to stand alone would repeat some of that information; this
-redundance looks bad. Meanwhile, the informality that is acceptable in
+redundancy looks bad. Meanwhile, the informality that is acceptable in
a documentation string is totally unacceptable in a manual.
The only good way to use documentation strings in writing a good manual
@cindex optional features, configure-time
Other options are permitted to specify in more detail the software
-or hardware present on the machine, and include or exclude optional
-parts of the package:
+or hardware present on the machine, to include or exclude optional parts
+of the package, or to adjust the name of some tools or arguments to them:
@table @samp
@item --enable-@var{feature}@r{[}=@var{parameter}@r{]}
Do not use a @samp{--with} option to specify the file name to use to
find certain files. That is outside the scope of what @samp{--with}
options are for.
+
+@item @var{variable}=@var{value}
+Set the value of the variable @var{variable} to @var{value}. This is
+used to override the default values of commands or arguments in the
+build process. For example, the user could issue @samp{configure
+CFLAGS=-g CXXFLAGS=-g} to build with debugging information and without
+the default optimization.
+
+Specifying variables as arguments to @code{configure}, like this:
+@example
+./configure CC=gcc
+@end example
+is preferable to setting them in environment variables:
+@example
+CC=gcc ./configure
+@end example
+as it helps to recreate the same configuration later with
+@file{config.status}.
@end table
-All @code{configure} scripts should accept all of these ``detail''
-options, whether or not they make any difference to the particular
-package at hand. In particular, they should accept any option that
-starts with @samp{--with-} or @samp{--enable-}. This is so users will
-be able to configure an entire GNU source tree at once with a single set
-of options.
+All @code{configure} scripts should accept all of the ``detail''
+options and the variable settings, whether or not they make any
+difference to the particular package at hand. In particular, they
+should accept any option that starts with @samp{--with-} or
+@samp{--enable-}. This is so users will be able to configure an
+entire GNU source tree at once with a single set of options.
You will note that the categories @samp{--with-} and @samp{--enable-}
are narrow: they @strong{do not} provide a place for any sort of option
projects / gnulib.git / blobdiff