Best practices for source file line lengths?

Question

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?

Answer 1

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.

Answer 2

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 ...

Answer 3

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.

Answer 4

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.

Answer 5

After having tried both hard and soft line breaks the last few years, and read the comments of others, here's a compilation of advantages/disadvantages I've come across.

One paragraph per line + soft wrap:

• Yields optimal line breaks in a text editor at no maintenance.
• Doesn't look the same to everyone.
• The least graceful option to diffs and VCSs.
• It is difficult to identify bugs because there's so much on each line.
• Unusual approach, so it may put off collaborators.
• In many editors using the up and down keys (or j and k in Vim) result in moving one paragraph at a time instead of visually up or down (in Vim gj and gk may be used to move visually up or down, but that is cumbersome). Likewise, you may have to move the cursor far to the left/right.

Hard (actual) line breaks at fixed width:

• Doesn't make the best use of the screen real estate because screen layout is individual. Author must choose line width.
• Line breaks must be maintained manually (automatic hard wrap and commands such as gqap in Vim helps, but there's usually still some manual maintenance).
• Not optimal for diffs and VCSs, because lines will be rearranged.
• It is often useful to search for text fragments found in the PDF to locate the same spot in the code. Searching for xt fr in this post for instance, would quickly reveal this item. This is more difficult if there's hard line breaks between words. Editor tools (e.g. fuzzy search or search with general whitespace characters) may help.

One sentence per line (with or without soft wrap):

• Perhaps the most optimal for diffs and VCSs (but convenience for humans is more important, IMO).
• Uneven line lengths and visually unaesthetic. If using soft wraps, it comes with the same disadvantages mentioned under "One paragraph per line + soft wrap". If not, some lines will require scrolling left/right.

Hard (actual) line breaks at position of the author's choice:

• Doesn't make the best use of screen real estate.
• Requires manual maintenance, and moreover, conscious thought spent on deciding where to break the lines.
• Line breaks may appear at inconsistent places.
• May be difficult to search for text fragments.

To me the prospect of letting the editor do all the formatting for me (one paragraph per line and soft wrapping) is very appealing. I tried it, and it works to some extent, but the disadvantages are real. I'm therefore leaning towards the second option. Your mileage may vary. I will try to update this list continually.