# whitespace/brace/indentation conventions for LaTeX programming

This question is not about formatting the text/markup of a document. I'm really focused on the programming aspect of LaTeX. I'm working on a fairly large set of document classes and packages, and I'm wondering what's conventional for bracing and indentation.

Looking at the latex.ltx file, I see some groups which have their closing braces as the end of the last line, e.g.,:

\def\vgl@{\par \dimen@\prevdepth \hrule \@height\z@
\nobreak\vskip\skip@ \prevdepth\dimen@}


Other times the closing brace is in the next line, as in

\def\ltx@sh@ft #1{%
\dimen@ #1%
\kern \strip@pt
\fontdimen1\font \dimen@
} % kern by #1 times the current slant


I suppose the latter style could be called K&R. I don't know if the former has enough adherents in the C world to have a name.

As of this morning I'm considering K&R style braces with indents of four spaces. latex.ltx and other sources I've read use two, but four seems a bit more readable. Extra newlines means one has to be careful about extra spaces and \pars being added, but for purposes of readability I like the space.

I'm interested to hear what other conventions LaTeX programmers have used and come to like.

-
As there will probably be no “right” answer to this question, it should be better placed as a Community Wiki. –  Juan A. Navarro Oct 7 '10 at 13:11
Thanks for the advice, but I don't know what you mean. What should I do and how should I do it? –  Matthew Leingang Oct 7 '10 at 13:22
Edit the question, near the bottom right of the textfield, there is a small checkbox labeled "community wiki". Tick it. –  Willie Wong Oct 7 '10 at 13:27
Thanks @Willie. It is done. –  Matthew Leingang Oct 7 '10 at 13:38

I'll reply to this question in more detail when I've got a few more minutes, but my currently favored approach for LaTeX2e programming is to always have the closing brace on it's own line (and two spaces indentation, since sometimes it stacks up a lot). E.g.,

\def\foo{%
\bar{abc}%
}


The more inline style, as in your first example, I used to use religiously, but I've since found it makes re-reading code that little bit harder (especially when the closing braces stack up several deep).

I strongly dislike and discourage the form of your first example where multiple commands are placed on the same line. When people say that TeX programming is hard to read, these are the examples they use.

In LaTeX3 programming, I have a few more rules of thumb, but they'll have to wait for another day.

-
I agree that four can stack up quickly. The thing about only two spaces indent is with all the backslashes I just see diagonal lines all over the screen. –  Matthew Leingang Oct 7 '10 at 13:40
Maybe three then :-) –  Will Robertson Oct 7 '10 at 14:11

I agree with what Will wrote, but I find that 2 spaces makes it quite hard to read code. My code tends to be indented with a tab (so set your tab stops to whatever you want). I find that even with the default 8 space tab stop, my code stays under 80 columns (more or less).

If a macro I write is really simple, I'll keep it all in one line. E.g., \temp in

\newcommand\foo[1]{%
\edef\temp{#1}%
% do something with \temp
}


\newcommand\foo[1]{%
\edef\temp{%
#1%
}%
% do something with \temp
}


which is clearly harder to read.

-
Linus Torvald's C coding style agrees with this, saying Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. –  Charles Stewart Oct 28 '10 at 17:23

Both Will and TH. have answered well. I'm going to go with a modified K&R style brace/indentation style. I won't indent functions differently from control structures as they do. TH. is wise in saying there are some obvious exceptions.

I haven't settled yet on the number of spaces of indent. I think somewhere between 2 and 4 is good.

-