@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate February 12, 2006
+@set lastupdate May 24, 2006
@c %**end of header
@dircategory GNU organization
* Managing Releases:: The Release Process
* References:: References to Non-Free Software or Documentation
* Copying This Manual:: How to Make Copies of This Manual
-* Index::
+* Index::
@end menu
more maintainable by others.
The GNU Hello program serves as an example of how to follow the GNU
-coding standards for a trivial program which prints @samp{Hello,
-world!}. @uref{http://www.gnu.org/software/hello/hello.html}.
+coding standards for a trivial program.
+@uref{http://www.gnu.org/software/hello/hello.html}.
@node Legal Issues
@chapter Keeping Free Software Free
Trademark acknowledgements are the statements that such-and-such is a
trademark of so-and-so. The GNU Project has no objection to the basic
-idea of trademarks, but these acknowledgements feel like kowtowing,
+idea of trademarks, but these acknowledgements feel like kowtowing,
and there is no legal requirement for them, so we don't use them.
What is legally required, as regards other people's trademarks, is to
technique.
@cindex GUILE
-The standard extensibility interpreter for GNU software is GUILE, which
-implements the language Scheme (an especially clean and simple dialect
-of Lisp). @uref{http://www.gnu.org/software/guile/}. We don't reject
-programs written in other ``scripting languages'' such as Perl and
-Python, but using GUILE is very important for the overall consistency of
-the GNU system.
+The standard extensibility interpreter for GNU software is GUILE
+(@uref{http://www.gnu.org/software/guile/}), which implements the
+language Scheme (an especially clean and simple dialect of Lisp). We
+don't reject programs written in other ``scripting languages'' such as
+Perl and Python, but using GUILE is very important for the overall
+consistency of the GNU system.
@node Compatibility
@section Compatibility with Other Implementations
@example
@var{source-file-name}:@var{lineno}:@var{column}: @var{message}
-@var{source-file-name}:@var{lineno}.@var{column}: @var{message}
+@var{source-file-name}:@var{lineno}.@var{column}: @var{message}
@end example
character set supports it, the @samp{(C)} should be replaced with the
copyright symbol, as follows:
-@ifinfo
-(the official copyright symbol, which is the letter C in a circle);
-@end ifinfo
-@ifnotinfo
+@ifinfo
+(the official copyright symbol, which is the letter C in a circle);
+@end ifinfo
+@ifnotinfo
@copyright{}
-@end ifnotinfo
+@end ifnotinfo
Write the word ``Copyright'' exactly like that, in English. Do not
translate it into another language. International treaties recognize
@end example
@noindent
-or, if you want to use Standard C syntax, format the definition like
+or, if you want to use traditional C syntax, format the definition like
this:
@example
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" : "");
+printf ("%s is full", capacity > 5000000 ? "disk" : "floppy disk");
@end example
-@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" : "");
+printf (gettext ("%s is full"),
+ capacity > 5000000 ? gettext ("disk") : gettext ("floppy disk"));
@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:
+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:
: "# 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
Unicode contains the unambiguous quote characters required, and its
common encoding UTF-8 is upward compatible with Latin1. However,
-Unicode and UTF-8 are not universally well-supported, either.
+Unicode and UTF-8 are not universally well-supported, either.
This may change over the next few years, and then we will revisit
this.
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
history of how the conflicting concepts arose and who they came from.
@menu
-* Change Log Concepts::
-* Style of Change Logs::
-* Simple Changes::
-* Conditional Changes::
+* Change Log Concepts::
+* Style of Change Logs::
+* Simple Changes::
+* Conditional Changes::
* Indicating the Part Changed::
@end menu
alternatives for how to describe a machine. Thus,
@samp{athlon-pc-gnu/linux} would be a valid alias. There is a shell
script called
-@uref{http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub,
+@uref{http://savannah.gnu.org/@/cgi-bin/@/viewcvs/@/*checkout*/@/config/@/config/@/config.sub,
@file{config.sub}} that you can use as a subroutine to validate system
types and canonicalize aliases.
i686-pc-linux-gnu}. When the build type is not specified by an option
or argument, the @code{configure} script should normally guess it using
the shell script
-@uref{http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess,
+@uref{http://savannah.gnu.org/@/cgi-bin/@/viewcvs/@/*checkout*/@/config/@/config/@/config.guess,
@file{config.guess}}.
@cindex optional features, configure-time
of free documentation is found at
@url{http://www.gnu.org/philosophy/free-doc.html}. A list of
important licenses and whether they qualify as free is in
-@url{http://www.gnu.org/licenses/license-list.html}. The terms
+@url{http://www.gnu.org/@/licenses/@/license-list.html}. The terms
``free'' and ``non-free'', used in this document, refer to that
definition. If it is not clear whether a license qualifies as free
under this definition, please ask the GNU Project by writing to
projects / gnulib.git / blobdiff