What are coding conventions in LaTeX?

Question

What do I mean by Convention?

First of all, allow me to clear myself about the word 'conventions.

As most of you already know, coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices and methods for each aspect of a piece program written in this language [from WikipediA]. These conventions usually cover 'file organization', 'indentation', 'comments', 'declarations', 'statements', 'white space', 'naming conventions', 'programming practices', 'programming principles', 'programming rules of thumb', etc.

An Example!

As an example, consider Java (and other C-like programming languages). In Java Naming Conventions, class names should be in UpperCamelCase, methods and variables should follow lowerCamelCase and constants should be ALLCAPS.

A Personal Experience:

There are some of these conventions that I have realised while writing smaller reports. For example, the second time I wrote a report with LaTeX, I realized it's better to put each chapter in a separate file. Also, I learned about them reading other peoples code like this one that I learned about it recently: One-Sentence-per-Line. This looks very important for sake of readability of the latex source but I never thought about it until I read that answer.

Here comes the Question!

I'm about to write my master thesis and I want to know these conventions for LaTeX. My goal is to achieve a readable, reusable, easy to modify and standard source code.

If you know any conventions, or if you have your own personal ones, regarding any aspect of LaTeX, please share with me and I would be delighted if you support your answers/conventions with reasons or examples.

Answer 1

I'm about to write my master thesis and I want to know these conventions for latex. My goal is to achieve a readable, reusable, easy to modify and standard source code.

I am afraid I cannot offer any advice on the "easy to modify" and "standard source code" parts as they are contradicting the very essence of TeX and LaTeX2e. Your question sounds as if you have been influenced by some High Priest of Coding. Beware as their favorites, code and teachings change.

First let us distinguish between writing your thesis and programming LaTeX macros. I have a friend who is a painter and is one of the most untidy persons on the universe, but out of his workshop come out the most beautiful paintings. My late Supervisor's office and his desk was buried in books, papers and even old pizza boxes, but he wrote beautiful maths. Both the Professor and the artist had exceptional sharp and focus minds. Your purpose I guess is to write your thesis and get your Masters.

Organize yourself with a good distribution, set up a git or other version control system and perhaps a dropbox account, I recommend you organize your folders as follows (works for me),

    mythesis |
             - chapter01
                   - notes
             - chapter02
             - chapter-nn
             - graphics
             - plots
                  - data
             - any specials
             - delete
             bibliography files etc
             main


   mythesis-versions
             thesis-01.zip
             thesis-02.zip
             thesis-03.zip

Split the write-up from the coding. When I am writing, I don't want any distractions. It doesn't matter if the code is beautiful or not, if the text is ungrammatical or has spelling mistakes. I write quickly and focus on conveying my ideas or structuring code to work. This way I achieve "flow" much more easier. I am at my best when I do this on paper than computer. Find what works for you. In less productive hours I tidy up the code or do rewrites.

To make your code re-usable both for your older self as well as colleagues, means you need to package it and document it using literate programming, i.e, create a .dtx.

If you use re going to use LaTeX3 follow the conventions recommended by the LaTeX3 Team, is the closest thing to a standard. However, if you find yourself dealing with mostly LaTeX2e code, the following are some suggestions:

Use a suffix¹ to namespace rather that a prefix in internal macros. It makes LaTeX2e code more readable, i.e.,

   myfancysection@mex

rather than

   @mex@my@fancy@section

LaTeX3 code cannot be very readable by design so stick with conventions on prefixing etc.

   g_mex_my_fancy_section

Normally author interfaces have the convention of UpperCamelCasing, break the rule if possible. It is more difficult to type

   MyFancySection

rather

   myfancysection

and I personally find the latter as readable if not easier to read than the former. The Germans do this with their language all the time.

I would make an exception and any settings commands can be uppercased.

 DeclareDocumentFont and not declareDocumentFont or declaredocumentfont

Consistency is good for example the biblatex author created commands that are easy to remember and indicate their purpose well.

  textcite[][]{}
  Textcite

Took me about an hour to find out what was wrong with:

  setpgfkeys

where I should have typed

  setpgfqkeys

I couldn't see the difference. Choose your naming scheme carefully as it is a User Interface. Use a key value interface where possible.

Just to throw the spanner in the works, the most clean and readable code, which it almost seems as if it was organized with beauty in mind is that of ConTeXt. Unfortunately I don't use it that much.

There are a lot of QA on this site around the topic, search around and pick what you think will work for you.

NOTE:

[1] On suffixes: (it also appears that natural language evolution tends to add suffixes. "der Kommunis mus" (communism); "der Naturalis mus" (naturalism); "der Touris mus" (tourism). I guess one's background in coding and mother language impact on readability opinions. As noted earlier all are personal opinions. Perhaps a linguist can shed a bit more light here.

Answer 2

I would add an important remark concerning name conventions: In your code, always use \newcommand or other high-level macro to define a new command. The reason is that you cannot redefine an existing macro of some other package.

If you need to redefine it and you know what you are doing, you can use \renewcommand or you can say \let\mywhatevernamingconventioniprefer\relax (which makes macro "undefined" in some sense). This "relaxing" is necessary if you define new macro by other commands like \DeclareMathOperator or \DeclarePairedDelimiter.