DESCRIPTION

Indent takes as input, source code of C or C++ programs and transforms
it to produce new output file, whose code will be written according to
ABB Industrial Systems style guide. So you can use your own style
while writing programs, and in the end use indent to get code which
satisfies style guide. If you only specify an input-file, the
formatted file is written back into input-file and a backup copy of
input-file is written in the current directory. If input-file is named
/usr/name/file, the backup file is named /usr/name/file.BAK. If
output-file is specified, indent checks to make sure it is different
from input-file. Order of options is not important.

OPTIONS

-+ Turns on support for C++. In C++ mode, :: is permitted in
identifiers, C++ keywords are supported. Files with extension .C
and .H are recognized as C++ files by default.
-Ttypename
Adds typename to the list of type keywords. Names accumulate: -T
can be specified more than once. You need to specify all the
typenames that appear in your program that are defined by
typedefs - nothing will be harmed if you miss a few, but the
program wont be formatted as nicely as it should. This sounds
like a painful thing to have to do, but its really a symptom of a
problem in C Typedef causes a syntactic change in the language
and indent cant find all typedefs.
-Ffilename
Specified file has to contain names of user defined types, one in
each line. This is only another way to pass typenames to
formatter if there is lot of them, and you dont want to use -T
option. This option can be specified more than once if there is
more than one file with typenames. Another way to tell formatter
name of file which contains typenames, is to define environment
variable TYPENAMES, and assign it name of file.
-v,-nv
Option -nv turns off verbose mode. When in verbose mode, indent
reports when it splits one line of input into two or more lines
of output, and gives some size statistics at completion. Default:
-v-st Causes indent to take its input from stdin, and put its output to
stdout.
THE FOLLOWING OPTIONS ARE SET TO SATISFY ABB Industrial Systems
STYLE GYIDE. IF, FOR SOME REASON, YOU WANT TO CHANGE THE
DEFAULT, YOU CAN USE THE FOLLOWING OPTIONS:
Options used to make blank lines or force new lines:
-bap,-nbap
A blank line after every procedure body. Default: nbap-bad,-nbad n
A blank line after every block of declarations. Default: b
a
d
-bbb,-nbbb
A blank line before every block comment. Default: nbbb-bl,-brr
Option bl lines up compound statements like this:
if (...)
{
code
}
Option brr(default) makes them look like this:
if (...)
{
code
}
-ce,-nce
Option -ce: }else
Option -nce (default): }
else
-psl,-npsl
Option psl: type_proc nps1: type_proc proc_name
proc_name
Default: npsl
Options to insert space in statement:
-pcs,-npcs
If true (pcs) all procedure calls will have a space inserted
between the name and the (. Default: npcs-prs,-nprs
If true (prs) all parentheses will have a space inserted after
the ( and before the ). Default: nprs
Options to regulate indentation:
-cin The continuation lines of the statement will be indented n from
the beginning of the first line of the statement. Parenthesized
expressions have extra indentation added to indicate the nesting,
unless -lp is in effect. Default: the same value as for -i.
-din
declaration_keyword identifier
<- n (char positions) ->
Default: di1-in The number of spaces for one indentation level. Default: 2-ip,-nip
Enables (disables) the indentation of parameter declarations from
the left margin. Default: ip-lp,-nlp
Code surrounded by parenthesis in continuation lines. For
example, with nlp in effect:
p1 = first_procedure(second_procedure(p2, p3),
third_procedure(p4, p5));
With lp in effect (the default):
p1 = first_procedure(second_procedure(p2, p3),
third_procedure(p4, p5));
Options for comments:
-cn The column in which comments on code start. Default: 33-cdn The column in which comments on declarations start. Default: the
same column as those on code.
-cdb,-ncdb
With this option enabled, comments look like this:
/*
* this is a comment
*/
Rather than like this:
/* this is a comment */
This only affects block comments, not comments to the right of
code. Default: cdb-dn Comments which are not to the right of code. Such comments are
placed n indentation levels to the left of code.Specifying d0
lines up these comments with the code. See the section on comment
indentation below. Default: d0-fc1,-nfc1
Do (Dont) touch comments starting in 1st column. Default: fc1
(it means touch them )
-sc,-nsc
Enables (disables) the placement of asterisks (*s) at the left
edge of all comments.
Miscellaneous options:
-ln Maximum length of an output line. Default: 78-npro
Profile files, ./.indent.pro and ~/.indent.pro, will be ignored.
-sob,-nsob
If sob is specified, indent will swallow optional blank lines.
You can use this to get rid of blank lines after declarations.
Default: nsob-troff
Indent will format the program for processing by troff. It will
produce a fancy listing in much the same spirit as vgrind. If
the output file is not specified, the default is standard output,
rather than formatting in place.

FURTHER DESCRIPTION

Comments:
Box comments. Indent assumes that any comment with a dash or star
immediately after the start of comment (that is, /*- or /**) is a
comment surrounded by a box of stars. Each line of such a
comment is left unchanged, except that its indentation may be
adjusted to account for the change in indentation of the first
line of the comment. Straight text. All other comments are
treated as straight text. Indent fits as many words (separated by
blanks, tabs, or newlines) on a line as possible. Blank lines
break paragraphs.
Comment indentation
If a comment is on a line with code it is started in the comment
column, which is set by the -cn command line parameter.
Otherwise, the comment is started at n indentation levels less
than where code is currently being placed, where n is specified
by the -dn command line parameter. If the code on a line extends
past the comment column, the comment starts further to the right,
and the right margin may be automatically extended in extreme
cases.
Special Comments
Indent produces and interprets some special comments. When indent
cannot parse the source, it prints a message on standard error
and inserts a comment into the output of the form /**INDENT**
ErrorMessage */
Indent interprets several special comments as directives. First,
it makes no attempt to format lines containing the error comment
described above.
Second, lines of the form: /* INDENT OFF */ or /* INDENT ON */
disable and re-enable indent formatting. Any amount of whitespace
may replace the spaces shown in the examples.
Third, indent allows formatting controls to be included in the
source via comments of the form: /* INDENT: arg1 arg2 arg3 ...
arg4 */ The arguments given are in the same syntax as the command
line or profile file. For example: /* INDENT: -cli.25 -nfc1 */
Preprocessor lines In general, indent leaves preprocessor lines
alone. The only reformatting that it will do is to straighten up
trailing comments. It leaves imbedded comments alone.
Conditional compilation (#ifdef...#endif) is recognized and
indent attempts to correctly compensate for the syntactic
peculiarities introduced.
C syntax
Indent understands a substantial amount about the syntax of C,
but it has a forgiving parser. It attempts to cope with the usual
sorts of incomplete and misformed syntax. In particular, the use
of macros like: #define forever for(;;) is handled properly.

EXTERNAL INFLUENCES

Environment variables:
Environment variable TYPENAMES is checked. If it is set it should
contain a name of a file which contains names of user defined
types.
Files:
You may set up your own profile of defaults to indent by creating
a file called .indent.pro in either your login directory or the
current directory and including whatever switches you like. A
.indent.pro in the current directory takes precedence over the
one in your login directory. If indent is run and a profile file
exists, then it is read to set up the programs defaults. Switches
on the command line, though, always override profile switches.
The switches should be separated by spaces, tabs or newlines.

BUGS

A common mistake that often causes grief is typing: indent*.c to the
shell in an attempt to indent all the C programs in a directory. This
does not work. You probably expect to get exactly the same file after
formatting of code which is already formated by formatter. Some
changes in comment look are possible.

EXAMPLES

To format C++ module infile.C you can use following command:
indentinfile.Coutfile.C
To tell indent that you are introducing types my_type1 and my_type2,
and that you have file which contains names of the types that you are
using in your program, you can use:
indentafile.cbfile.c-Tmy_type1-Tmy_type2-Ffile_with_types.txt