|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
9.6 Coding StyleThe Autoconf macros follow a strict coding style. You are encouraged to follow this style, especially if you intend to distribute your macro, either by contributing it to Autoconf itself, or via other means. The first requirement is to pay great attention to the quotation, for more details, see 3.1.2 The Autoconf Language, and 8.1 M4 Quotation. Do not try to invent new interfaces. It is likely that there is a macro in Autoconf that resembles the macro you are defining: try to stick to this existing interface (order of arguments, default values, etc.). We are conscious that some of these interfaces are not perfect; nevertheless, when harmless, homogeneity should be preferred over creativity. Be careful about clashes both between M4 symbols and between shell variables.
If you stick to the suggested M4 naming scheme (see section 9.2 Macro Names),
you are unlikely to generate conflicts. Nevertheless, when you need to
set a special value, avoid using a regular macro name; rather,
use an "impossible" name. For instance, up to version 2.13, the macro
No Autoconf macro should ever enter the user-variable name space; i.e.,
except for the variables that are the actual result of running the
macro, all shell variables should start with
Do not use M4 ignores the leading spaces before each argument, use this feature to indent in such a way that arguments are (more or less) aligned with the opening parenthesis of the macro being called. For instance, instead of
write
or even
When using Feel free to use various tricks to prevent auxiliary tools, such as syntax-highlighting editors, from behaving improperly. For instance, instead of:
use
so that Emacsen do not open a endless "string" at the first quote. For the same reasons, avoid:
and use:
Otherwise, the closing bracket would be hidden inside a `#'-comment,
breaking the bracket-matching highlighting from Emacsen. Note the
preferred style to escape from M4: `$[1]', `$[@]', etc. Do
not escape when it is unneeded. Common examples of useless quotation
are `[$]$1' (write `$$1'), `[$]var' (use `$var'),
etc. If you add portability issues to the picture, you'll prefer
`${1+"$[@]"}' to `"[$]@"', and you'll prefer do something
better than hacking Autoconf
When using
See section 9.1 Macro Definitions, for details on how to define a macro. If a
macro doesn't use You should not rely on the number of arguments: instead of checking whether an argument is missing, test that it is not empty. It provides both a simpler and a more predictable interface to the user, and saves room for further arguments.
Unless the macro is short, try to leave the closing `])' at the
beginning of a line, followed by a comment that repeats the name of the
macro being defined. This introduces an additional newline in
you would write:
If the macro is long, try to split it into logical chunks. Typically,
macros that check for a bug in a function and prepare its
In order to highlight the recommended coding style, here is a macro written the old way:
and the new way:
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Marketplace: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| " Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long? " | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||