Indenting Standards

We find it very hard to read code indented 8 columns at a time. Even 4 at a time uses a lot of space, so we have adopted indenting 3 spaces at every level. Note, indention is the visual appearance of the source on the page, while tabbing is replacing a series of up to 8 spaces from a tab character.

The closest set of parameters for the Linux indent program that will produce reasonably indented code are:

-nbad -bap -bbo -nbc -br -brs -c36 -cd36 -ncdb -ce -ci3 -cli0
-cp36 -d0 -di1 -ndj -nfc1 -nfca -hnl -i3 -ip0 -l85 -lp -npcs
-nprs -npsl -saf -sai -saw -nsob -nss -nbc -ncs -nbfda

You can put the above in your .indent.pro file, and then just invoke indent on your file. However, be warned. This does not produce perfect indenting, and it will mess up C++ class statements pretty badly.

Braces are required in all if statements (missing in some very old code). To avoid generating too many lines, the first brace appears on the first line (e.g. of an if), and the closing brace is on a line by itself. E.g.

if (abc) {
   some_code;
}

Just follow the convention in the code. For example we I prefer non-indented cases.

switch (code) {
case 'A':
   do something
   break;
case 'B':
   again();
   break;
default:
   break;
}

Avoid using // style comments except for temporary code or turning off debug code. Standard C comments are preferred (this also keeps the code closer to C).

Attempt to keep all lines less than 85 characters long so that the whole line of code is readable at one time. This is not a rigid requirement.

Always put a brief description at the top of any new file created describing what it does and including your name and the date it was first written. Please don’t forget any Copyrights and acknowledgments if it isn’t 100% your code. Also, include the Bacula copyright notice that is in src/c.

In general you should have two includes at the top of the an include for the particular directory the code is in, for includes are needed, but this should be rare.

In general (except for self-contained packages), prototypes should all be put in protos.h in each directory.

Always put space around assignment and comparison operators.

a = 1;
if (b >= 2) {
  cleanup();
}

but your can compress things in a for statement:

for (i=0; i < del.num_ids; i++) {
 ...

Don’t overuse the inline if (?:). A full if is preferred, except in a print statement, e.g.:

if (ua->verbose && del.num_del != 0) {
   bsendmsg(ua, _("Pruned %d %s on Volume %s from catalog.\n"), del.num_del,
      del.num_del == 1 ? "Job" : "Jobs", mr->VolumeName);
}

Leave a certain amount of debug code (Dmsg) in code you submit, so that future problems can be identified. This is particularly true for complicated code likely to break. However, try to keep the debug code to a minimum to avoid bloating the program and above all to keep the code readable.

Please keep the same style in all new code you develop. If you include code previously written, you have the option of leaving it with the old indenting or re-indenting it. If the old code is indented with 8 spaces, then please re-indent it to Bacula standards.

If you are using vim, simply set your tabstop to 8 and your shiftwidth to 3.

Possible Next Steps

Go to Naming Convention.

Go back to Developer Notes.

Go back to Developer Guide.