65

Even though I don't work at Google, the Google Styleguides have been very helpful for me in adopting consistent, readable style conventions for my code. Unfortunately, there is no Google Styleguide for LaTeX.

Q: For LaTeX, does anyone know of something equivalent to the Google Styleguides?

Quick searches of the web for LaTeX styleguides have returned plenty of styleguides emphasizing how compiled LaTeX documents should appear. I couldn't find anything emphasizing how the uncompiled .tex document should appear.

I suppose if there weren't anything equivalent to the Google Styleguides, a standard, very cleanly written and commented .tex template would suffice.

UPDATE: Over at StackOverflow, I've found a similar post asking about Ruby coding style guidelines. There are a number of helpful links provided there. I'm looking for something kind of similar.

lowndrul
  • 5,323
  • 1
    This would be a great idea! (Although I doubt you'll be able to find consensus for writing LaTeX code, as styles vary quite significantly.) – Will Robertson Feb 27 '11 at 04:11
  • 1
    @brianjd — Are you referring more to LaTeX documents or package code? – Will Robertson Feb 27 '11 at 06:15
  • 1
    As Will knows, I have some ideas for formatting LaTeX3 code - see for example how siunitx is laid out (there are some updates, though, so also expect changes!) – Joseph Wright Feb 27 '11 at 08:59
  • 1
    Be aware that the Google style guides are meant for Google products, not as a general programming guidelines. Unfortunately they have become so popular that people on SO have to invest a lot of time to tell people not to apply them. – Philipp Feb 27 '11 at 12:35
  • @Phillipp: I'm not sure I understand your comment. The Guidelines are for specific languages (e.g., R, Python, etc.). So, I don't think anyone takes them to be general programming guidelines. But then, it's worth asking: is the, say, R Guideline a good general R programming guideline? I think so! As far as style goes (and that's all the Guidelines are trying to speak to), I see it working in a very general sense. Sure, every individual will have some style preferences that are at odds with Google's. But at least with R, I see most code following closely Google's advised style. – lowndrul Feb 27 '11 at 15:13
  • @Will: I'm referring more to LaTeX documents since that's what I write (maybe once I'm a superuser I'll start writing packages :>). As for your comment that "styles vary quite significantly", isn't all the MORE reason to have style guide for LaTeX? I'm sure you could say the same thing for C, Python, R, etc., but they've become a great success. The more people's idiosyncratic programming style comes to dominate program documents the less readable they become to other users. I think the success of the Google Styleguides speaks to the desire of programmers to systematize things a bit? – lowndrul Feb 27 '11 at 15:20
  • @Joseph. Thank you for the pointer. I'm looking at sinuitx. – lowndrul Feb 27 '11 at 15:39
  • 1
    @brianjd: No, I'm referring to (language-specific) general-purpose style guides vs. company-specific style guides. The Google style guides are only partially valid for non-Google software. I can't comment on the R style guide, but the C++ guide is often at odds with current best practices and experts' suggestions. – Philipp Mar 01 '11 at 20:33
  • To be a bit more on topic, I think you don't find that many style guides because TeX code is rarely shared or edited collaboratively. You just don't have large-scale projects with hundreds of developers in TeX. Furthermore, most LaTeX documents I know contain mostly plain text with few straightforward commands. So I think that a elaborate style guide for LaTeX documents is not required (but I agree with the points discussed by TH. and Villemoes). For packages the situation might look different. – Philipp Mar 01 '11 at 20:49

2 Answers2

44

The most general advice is: Use whitespace to make your code readable.

Let me give a few examples.

  1. Always put \begin{environment} and \end{environment} on separate lines, without other content. An environment usually indicates that you are doing something "radically different", and it's easier to find the environment this way. Related:

  2. Inside an environment, use indentation as you would in any programming language. Whether you use 2, 4 or some other number per nesting level doesn't matter much (but if your editor uses a proportional font you probably want at least 4; spaces are usually much smaller than printed characters in proportional fonts).

    \begin{equation}
      \det
      \begin{pmatrix}
        1 & 2 \\
        3 & 4
      \end{pmatrix}
      = -2
    \end{equation}
    
  3. Whenever you force a line break with \\ (in a table, a matrix, an align-environment...), it goes without saying that it should be followed by a linebreak in the code.

  4. In math mode, spaces are ignored. So use spaces around binary relations, and in some cases also binary operators. Write $a^2 + b^2 = c^2$ instead of $a^2+b^2=c^2$. Also spaces after commas as in $(x, y, z)$ is a good idea.

  5. In environments such as align, blank lines are not allowed. But you can give yourself some vertical blank space by putting a single % on a line between the equations.

    \begin{align*}
      \sum_{n=1}^{\infty} \bigl(F(\tau^n m) - F(\tau^{n-1} m)\bigr)       &= x\\
    %
      \sum_{n=1}^{\infty} \bigl(F(\tau^{-n} m) - F(\tau^{-(n-1)} m)\bigr) &= y
    \end{align*}
    
  6. The same trick applies in ordinary text if you don't want a paragraph break. But also remember that one blank line has the same effect as five blank lines; around \chapter and \section headings it can be a good idea to have several blank lines. This makes it easier to navigate.

Most of the above points have the effect of making your code look somewhat like the compiled document, which I find very nice. Of course, an editor with syntax-highlighting, indentation facilities and brace matching is also great help.

David Carlisle
  • 757,742
Villemoes
  • 4,131
  • @Villemoes: your formatting issue was discussed on meta a while ago - you need to use four indent spaces per list level, so 8 for 'code inside a list' – Joseph Wright Feb 27 '11 at 08:19
  • 1
    @Villemoes: I've fixed it – Joseph Wright Feb 27 '11 at 08:20
  • @Joseph: Odd. I didn't have any luck with that when I tried it for my answer. I ended up using pre and code HTML tags. – TH. Feb 27 '11 at 08:22
  • The bit about extra space around \chapter or \section sounds good but it's editor dependant. For example I use AUCTeX which makes chapter and section titles use a larger font – kahen Feb 27 '11 at 08:32
  • @TH. Well it 'worked for me' :-) Take a look at the code to see how I've laid it out. – Joseph Wright Feb 27 '11 at 08:42
  • @Joseph: There we go. I think I just needed an extra line. – TH. Feb 27 '11 at 10:25
  • @Villemoes: Thanks for the post. These seem like some good guidelines. I never knew about th % trick. Will use that. – lowndrul Feb 27 '11 at 14:35
  • @Joseph: Thanks for the explanation, and for fixing it. – Villemoes Feb 27 '11 at 16:49
  • @kahen: I also use emacs+AUCTeX, and it has lots of other nice features for writing LaTeX. But this wasn't a question about editors, so I restrained myself from going out of that tangent too much. Also, the OP seems to come from a programming background, so he is probably aware of the benefits of using an editor with a certain amount of "language-awareness" (or whatever the right word is). – Villemoes Feb 27 '11 at 16:54
  • @Villemoes: Nice answer! I took the freedom and tried to improve it a bit. Did I guess right that you mean "per" when you write "pr."? – Hendrik Vogt Mar 01 '11 at 18:41
  • @Hendrik: Yes. Thanks for the correction. (In Danish "pr." is often used as an abbreviation of "per"; but it's clearly rather silly, and I usually avoid it.) – Villemoes Mar 02 '11 at 00:52
18

(This was originally a comment, but I think I need formatting to be clear.)

I can't answer your question, and I think even a community wiki post attempting to distill a guide would be a failure since, as Will says, styles vary a lot.

Two suggestions:

  1. For anything even slightly complicated, put one command per line. For example, if you need to define a macro that say, ends the current paragraph, skips two lines, and then puts its argument in a framed box, write something like this.

    \def\foo#1{%
        \par
        \vskip2\baselineskip
        \fbox{#1}%
    }
    

    I sometimes violate this when multiple things logically belong together like in the example below.

  2. Use indentation to show grouping just as you would in another programming language. It matter less how many spaces/tabs you use (although I personally find 1 or 2 to be too few, I know others disagree), than that you do it. The above code is an example. Another place is inside of a box like \vbox or when you use explicit grouping like \begingroup ... \endgroup.

    \begingroup
        \setbox0=\vbox{%
            \hsize=4in
            \parindent=0pt
            \hrule height.08em
            \kern.65ex
            \hfil\TeX\hfil
            \par
            \kern.4ex
            \hrule height.08em
        }%
        % other stuff
        \box0
    \endgroup
    

    I violated my first suggestion with the \hfil\TeX\hfil which seems easier to read when it is on a single line.

I find that following these two "rules" makes my own code reasonably easy to read.

TH.
  • 62,639
  • 1
    Thanks for the response. I just wanted to cross-apply my comment to Will's here: I think style varying a lot is PRECISELY the reason that a general style guideline should be adopted. – lowndrul Feb 27 '11 at 16:03
  • With your \vbox example, shouldn't the % be at the end of the line preceding the }? – Mateen Ulhaq Dec 25 '19 at 05:48