# Best practices for source file line lengths?

Are there any best practices for how long to make your lines in your source file? I'm also interested if there are best practices for it if there aren't any LaTeX-specific best practices.

I originally typed my LaTeX files like I was in Word:

• each paragraph on its own line.
• However, I eventually found that to be rather cumbersome and so I switched to one sentence per line (around the same time I moved from Dropbox to git).

That was large improvement for me.

Since I tend to write long sentences and like my footnotes, I tried an experiment in a file:

• break lines after commas as well as after periods.
• So far, it seems that this method would require a good bit of manual clean-up, since it produces some very short lines and there are still overly-long lines in the file.

What methods have you found to be the best for keeping your source's line lengths reasonable?

• I make a new line for each sentence, regardless of the length. This encourages me to write shorter sentences. I find it exceedingly difficult to edit my writing if the sentences are broken up over multiple lines. I briefly played with having my editor hard-wrap the lines automatically, but it made version control more difficult and, as I said, editing was a chore. – musarithmia Aug 18 '16 at 23:00
• personally I just let the editor (emacs in my case) to wrap to some arbitrary width such as 75 characters, I don't see any particular advantage in tying the source lines to sentence structure. – David Carlisle Aug 18 '16 at 23:17
• @DavidCarlisle Hard or soft wrap? – cjm Aug 18 '16 at 23:32
• @cjm real linebreaks (the whole soft wrap idea is just so confusing) – David Carlisle Aug 18 '16 at 23:33
• @DavidCarlisle The advantage to tying it to the sentence-structure is content-dependent, I think. If I do svn diff, I want to see the sentences I've changed even if I only changed one word in a long sentence. If, for example, I've added or removed not, reviewing the change is much, much easier if I have the full context. A sentence isn't always enough. But less than a sentence never is. – cfr Aug 19 '16 at 0:11

I'll use an example from the TeXBook source

This manual is intended for people who have never used \TeX\ before, as
well as for experienced \TeX\ hackers. In other words, it's supposed to
be a panacea that satisfies everybody, at the risk of satisfying nobody.
Everything you need to know about \TeX\ is explained
here somewhere, and so are a lot of things that most users don't care about.
If you are preparing a simple manuscript, you won't need to
learn much about \TeX\ at all; on the other hand, some
things that go into the printing of technical books are inherently
difficult, and if you wish to achieve more complex effects you
will want to penetrate some of \TeX's darker corners. In order
to make it possible for many types of users to read this manual
effectively, a special sign is used to designate material that is
for wizards only: When the symbol
$$\vbox{\hbox{\dbend}\vskip 11pt}$$
appears at the beginning of a paragraph, it warns of a ^{dangerous bend}''
in the train of thought; don't read the paragraph unless you need to.
Brave and experienced drivers at the controls of \TeX\ will gradually enter
more and more of these hazardous areas, but for most applications the
details won't matter.


the lines here are all less than 80 characters wide, I can show it here and everyone sees the same thing. I (or diff or similar tools) can refer to "experienced" in line 2, and everyone sees the same linebreaks and the whole whole thing is understandable.

If it was all one line it would look like

This manual is intended for people who have never used \TeX\ before, as well as for experienced \TeX\ hackers. In other words, it's supposed to be a panacea that satisfies everybody, at the risk of satisfying nobody. Everything you need to know about \TeX\ is explained here somewhere, and so are a lot of things that most users don't care about. If you are preparing a simple manuscript, you won't need to learn much about \TeX\ at all; on the other hand, some things that go into the printing of technical books are inherently difficult, and if you wish to achieve more complex effects you will want to penetrate some of \TeX's darker corners. In order to make it possible for many types of users to read this manual effectively, a special sign is used to designate material that is for wizards only: When the symbol $$\vbox{\hbox{\dbend}\vskip 11pt}$$ appears at the beginning of a paragraph, it warns of a ^{dangerous bend}'' in the train of thought; don't read the paragraph unless you need to. Brave and experienced drivers at the controls of \TeX\ will gradually enter more and more of these hazardous areas, but for most applications the details won't matter.


which is OK for TeX but looks horrible here

Even if your editor "soft wraps" to (say) 70 characters it would look like

This manual is intended for people who have never used \TeX\ before,
as well as for experienced \TeX\ hackers. In other words, it's
supposed to be a panacea that satisfies everybody, at the risk of
satisfying nobody. Everything you need to know about \TeX\ is
explained here somewhere, and so are a lot of things that most users
don't care about. If you are preparing a simple manuscript, you won't
need to learn much about \TeX\ at all; on the other hand, some things
that go into the printing of technical books are inherently difficult,
and if you wish to achieve more complex effects you will want to
penetrate some of \TeX's darker corners. In order to make it possible
for many types of users to read this manual effectively, a special
sign is used to designate material that is for wizards only: When the
symbol $$\vbox{\hbox{\dbend}\vskip 11pt}$$ appears at the beginning of
a paragraph, it warns of a ^{dangerous bend}'' in the train of
thought; don't read the paragraph unless you need to. Brave and
experienced drivers at the controls of \TeX\ will gradually enter more
and more of these hazardous areas, but for most applications the
details won't matter.


but the apparent line breaks come in more arbitrary places and as they are not really there different tools and different people would see different line breaks.

You could add a linebreak at major punctuation (here ,.;: and $$ math display) This manual is intended for people who have never used \TeX\ before, as well as for experienced \TeX\ hackers. In other words, it's supposed to be a panacea that satisfies everybody, at the risk of satisfying nobody. Everything you need to know about \TeX\ is explained here somewhere, and so are a lot of things that most users don't care about. If you are preparing a simple manuscript, you won't need to learn much about \TeX\ at all; on the other hand, some things that go into the printing of technical books are inherently difficult, and if you wish to achieve more complex effects you will want to penetrate some of \TeX's darker corners. In order to make it possible for many types of users to read this manual effectively, a special sign is used to designate material that is for wizards only: When the symbol$$\vbox{\hbox{\dbend}\vskip 11pt}
appears at the beginning of a paragraph,
it warns of a ^{dangerous bend}'' in the train of thought;
don't read the paragraph unless you need to.
Brave and experienced drivers at the controls of \TeX\ will gradually enter more and more of these hazardous areas,
but for most applications the details won't matter.


which is sort of OK, but still has some over-long lines and just makes editing harder as you edit the punctuation you have to merge lines.

• +1 Great editors like emacs and vim offer support for such features. :) – Paulo Cereda Aug 18 '16 at 23:52
• gqip, it's so intuitive! – Paulo Cereda Aug 19 '16 at 0:58
• The TeXbook was written 30 years ago. In those days there were solid reasons to stick to certain linewidths. Habit is still a good reason if that's what works for you, but modern editors on modern monitors give you more options – Chris H Aug 19 '16 at 8:39
• @ChrisH I used a modern (but old) editor, emacs, on a 27" screen quite capable of showing many more than 80 characters to a line, to reformat the text in the various ways above so yes there are more options, but I think for a text format like tex most of the options are not suitable, as I tried to explain. It is of course purely an opinion based thing so posting an answer with an alternative view, or in fact closing the question as "option based" are both reasonable responses. – David Carlisle Aug 19 '16 at 8:46
• @ChrisH Even today, there are good reasons not to let your lines get too long. Namely, readability: ever notice how painful old websites are to read in a full screen window on a widescreen monitor? Having an occasional excessively long line is fine, but for blocks of text, lines over 70 characters make it easier to lose your place. 80 isn't too bad, but proportional fronts seem to make long lines harder to read than fixed-width fonts. – cjm Aug 26 '16 at 19:00

TeX engines can essentially deal with lines of any (reasonable) length so in that sense there is no forced limitation and starting new lines largely comes down to personal preferences and your perception of readability.

There is however at least one area in which short lines (be it less than 80 chars or not) is superior longer ones (or worse in my opinion whole paragraphs on a single line, as some editors default to):

If you happen to store your text in some source control system, be it git or svn or CVS or whatever, then usually textual differences are recorded as line diffs and if you get those via email or in the browser or a git client then changes are much easier to identify if the lines are short. That is especially helpful if the work is in collaboration with other authors and you like to grasp their changes quickly.

• If you really want long lines, there are graphical diff programs like Meld, and I think KDiff3, that can do a "word level" diff and soft wrap lines. – StrongBad Aug 19 '16 at 13:42
• @StrongBad I' quite aware of that and I use them when appropriate, but that doesn't help if some svn sends me a diff per mail or I look at diffs in a git client like sourcetree or ... (besides even then the readability is lower as half of my pages might end up being a diff with only a word or a comma changed because they still show me the full paragraphs or more before and after) – Frank Mittelbach Aug 19 '16 at 13:48

The main problem is here that the error messages gives you the line number in which line the error was found. That means it could be in that line or the lines before.

If you have long or very long lines LaTeX can not be very exact helping you to find fast the error in the mentioned line.

The best practice is to have short lines. In my case I used the technic of my editor to show me a break line at line column 75 (See the red arrow in my image; use a number that the complete line can be shown on your screen) like you can see in the following image.

The advantage is that now the error message with mentioned error line number can be much more better and led you faster to the real error.

Not using an automatic line break shows the following case with a table:

\begin{longtable}[c]{lrrrrrrrrrrr}
\caption{A table of the first 10 rows of the mtcars data.}\\
\toprule
& mpg  & cyl & disp &  hp & drat &    wt &  qsec & vs   & am & gear & carb\\
\midrule
car type 1     & 21.0 & 6   & 160  & 110 & 3.90 & 2.620 & 16.46 &  0.0 &  1 &    4 & 4\\
car type 1 Wag & 21.0 & 6   & 160  & 110 & 3.90 & 2.875 & 17.02 &  0.0 &  1 &    4 & 4\\
car type 2     & 22.8 & 4   & 108  &  93 & 3.85 & 2.320 & 18.61 &  1.0 &  1 &    4 & 1\\
\bottomrule
\end{longtable}


Here I write one line of the table code in one editor line, writing the dividing & one above the other. This kind of pretty printing the table in the code makes it much more easier to find missing cells or wrong entrys. Suppose the given table has 5 or more columns ... An automatic line break would be unpleasant here ...

• Do you know if TeXShop has a similar feature? – cjm Aug 19 '16 at 0:16
• Know if your editor automatically breaks the lines for you or if it just gives you the red line and lets you do the work? – cjm Aug 19 '16 at 1:39
• Do you often find that an edit you made requires you to change the line structure of the entire paragraph? That seems like a fragile solution to me: if you significantly change a sentence, you may have to re-end the entire paragraph. Perhaps that's a much more unlikely scenario than I suspect. – cjm Aug 19 '16 at 2:10
• I figured that was the case, but the screenshot you posted made me suspect it could be the difficult way. – cjm Aug 19 '16 at 2:17
• Kile editor also provides this feature. – Loves Probability Aug 29 '16 at 10:57

I'll break this down into two cases:

# 1. When defining macros, drawing tikz pictures and othwerwise writing mostly code:

Short lines work well. Not necessarily one statement per line as is conventional in some languages - this is easy enough to read:

%And this implements a command "warn" for notes to self.
\newcommand\warn[1]{{\textcolor{red}{\textbf{**#1**}}}}


but (as in this answer) fine-grained enough to make debugging easy (you still have to work your way up to find the error though). Liberal use of trailing % signs is a good idea to avoid unwanted whitespace which can easy to miss until the final version is printed.

Similarly I'd never put two \begins on one line, and would indent below a \begin (also when there's an unclosed { or [ on the line). This means that a figure using \includegraphics takes up quite a lot of space -- and jumps out when scrolling. But any editor with even half-decent code folding can compress that if you don't want it.

# 2. When writing text:

Personally, I have a strong preference for sentence-per-line. I use a wide editor window (about 250 characters visible per line), and my editing often consists of moving chunks of text around within a sentence. This makes diffs easy (I usually turn on soft-wrapping for diffs, very occasionally for editing long sentences). I find keeping a sentence on a single line also helps with my tendency to write run-on sentences, as I get instant visual feedback of their length.

This editor window is much too wide for reading, but I read the pdf, not the source, when it comes to the content.

When I work on the same documents on a small screen (about half the width) line lengths in main text don't bother me, but scrolling even simple macros horizontally is too much.

# The conclusion:

If you're working mainly solo, do whatever works for you and don't worry about "right" or "standard". If you're writing collaboratively, either try to follow the main author's convention, or figure something out between you.