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 suffix1 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.
Best Answer
Technical reasons for choosing an environment over a command form are that if the definition only involves setting up declarations then it never has to scan the content in advance, so list environments or
longtableetc can start typesetting and shipping out pages before the end of the environment is seen. A command form necessarily has to scan to the end of the argument. If there is the possibility of verbatim-like material it is again easier to use an environment form.Other reasons are mostly just to do with the aesthetics of the document structure you are defining. If you want to think of it as a scoped region define it as an environment. If you want to think of it as a block of text passed to a command, define it as a command.