изменяет внешний вид программы C, вставляя или удаляя пробелы (changes the appearance of a C program by inserting or deleting whitespace.)
BREAKING LONG LINES
With the option '-ln', or '--line-lengthn', it is possible to
specify the maximum length of a line of C code, not including
possible comments that follow it.
When lines become longer than the specified line length, GNU
indent tries to break the line at a logical place. This is new
as of version 2.1 however and not very intelligent or flexible
yet.
Currently there are three options that allow one to interfere
with the algorithm that determines where to break a line.
The '-bbo' option causes GNU indent to prefer to break long lines
before the boolean operators && and ||. The '-nbbo' option
causes GNU indent not have that preference. For example, the
default option '-bbo' (together with '--line-length60' and
'--ignore-newlines') makes code look like this:
if (mask
&& ((mask[0] == '\0')
|| (mask[1] == '\0'
&& ((mask[0] == '0') || (mask[0] == '*')))))
Using the option '-nbbo' will make it look like this:
if (mask &&
((mask[0] == '\0') ||
(mask[1] == '\0' &&
((mask[0] == '0') || (mask[0] == '*')))))
The default '-hnl', however, honours newlines in the input file
by giving them the highest possible priority to break lines at.
For example, when the input file looks like this:
if (mask
&& ((mask[0] == '\0')
|| (mask[1] == '\0' && ((mask[0] == '0') || (mask[0] == '*')))))
then using the option '-hnl', or '--honour-newlines', together
with the previously mentioned '-nbbo' and '--line-length60', will
cause the output not to be what is given in the last example but
instead will prefer to break at the positions where the code was
broken in the input file:
if (mask
&& ((mask[0] == '\0')
|| (mask[1] == '\0' &&
((mask[0] == '0') || (mask[0] == '*')))))
The idea behind this option is that lines which are too long, but
are already broken up, will not be touched by GNU indent. Really
messy code should be run through indent at least once using the
'--ignore-newlines' option though.
The '-gts' option affects how the gettext standard macros _() and
N_() are treated. The default behavior (or the use of '-ngts')
causes indent to treat them as it does other functions, so that a
long string is broken like the following example.
if (mask)
{
warning (_
("This is a long string that stays together."));
}
With the '-gts' option, the underscore is treated as a part of
the string, keeping it tied to the string, and respecting the
fact that gettext is unobtrusively providing a localized string.
This only works if _(" is together as a unit at the beginning of
the string and ") is together as a unit at the end.
if (mask)
{
warning
(_("This is a long string that stays together."));
}
