At google (at least when I was there) they have a hard rule of 120 character lines or something. (I think it varies by language).

I thought the rule was ridiculous - until I realised one of my colleagues had set his computer up with 3 tmux sessions side by side, each perfectly fitting a 120 column code window. He never had to scroll sideways, and he was very productive with his setup. The fact he knew exactly how wide to make his terminals made his workflow much better.

I don’t follow that rule on my own projects, beyond keeping line lengths “reasonable”. But that rule might be on to something.

This is why I’ve come around on the 80 character rule after switching to Emacs, fitting four buffers side by side on my 27” monitor just works.

120 characters/3 columns is great for more verbose languages, but I find it a bit too wide for a vertical split on a 15” laptop monitor.

I just enable word wrap in my editor

I don't think the fact that it worked for one guy (or more accurately, that he adjusted his workflow according to this rule) makes it a good rule by definition.

It's not that they contorted their workflow to satisfy some arbitrary rules, it's that the fact of the dependable consistent rule made it possible for them to formulate an efficient dependable consistent workflow at all.

The 80 column “rule” also discourages the use of descriptive naming, which IMO is far more important to readability than short lines.

Also 80 columns is near impossible to adhere to for more verbose language.

Descriptive naming usually isn't.

    E=m*c^2 or 
    objectEnergyInJoule = massOfObjectInKilograms * speedOfLightInVacuum^2 ?

Now imagine that you're not looking at a famous equation and you tell me which one you would rather have to sus out the intention of.

    a = b/c

or

    numApples = numBananas/apple BananaConversionRate

The first one, no question about it.

Yes. We would want the descriptive names for identifiers which have broad scope, but short names for the local variables that work with them.

I would rather give a function the descriptive name in such a way that the parameters can then be given trivial, mnemonic names.

Strawmannish example:

   incrementAccountBalance(a, n)
   {
      ...
   }

The descriptive function name gives away what a and n are, so it is unhelpful to make this:

   incrementAccountBalance(account, amountToIncrementBy)

Reasonable middle ground:

   incrementAccountBalance(acct, delta)

With incrementAccountBalance(a, n), it's impossible to tell exactly what each argument is from the function signature alone. Of course I could assume that a = account and n = amount to increment by, but that's nothing more than an assumption, which only invites inevitable bugs. Alternatively I could look at the function body, and try to figure out what's going on, but that's time wasted that could be spent more productively.

Further, non-descriptive naming often assumes that the programmer reading and modifying the code has domain-specific knowledge. That might be true of mid level or senior engineers have have been with a particular company for years, but the new grad coming into a financial services company (a field he has no training or familiarity with) will have no idea what "a" or "b" means. I was in that position, and the descriptive naming absolutely would have helped me to learn and become productive with the codebase faster.

I'd say that your reasonable middle ground would be the best practice.

Opposite of my choice of which I also have no question.

For both Python and Go I use descriptive (often long) names and ~90-char line limit, and use linebreaks liberally to reconcile the two

> Also 80 columns is near impossible to adhere to for more verbose language.

Not if you use Unicode (and Chinese language).

I settled on 100 characters as the sweet spot, with an exception for trailing punctuation being allowed to go beyond (because you don’t want to wrap a line just because of some trailing punctuation).

I remember hitting the punctuation dilemma with my self-imposed character limit. Putting the punctuation on the next line, looking at it displeased, moving it back, questioning the purpose of rules if they're not followed; racking my brain over the world's least consequential conundrum. Ultimately I decided to adhere to my limit, but to treat punctuation and the word that precedes it as a single unit to be wrapped together.

Also sometimes comments.

Nah, comments are important and should be in the main field of view. :)

Horizontal scrolling can be avoided with line-wrapping. It's not always a good way to deal with the problem, but it's useful for some edge cases.

Line wrapping is often difficult to read as well. If programmers wrap the line themselves, they can break it up logically, rather than letting the computer break lines wherever it's convenient. Further, they can respect the indentation level of the line, whereas most line wraps I've seen wrap starting all the way to the left.

Vim has a setting to make line wraps start at the same indent as the line.

Word wrap. Turn on word wrap.

In every editor I've tried it on, word wrap wraps the lines all the way to the left, instead of respecting indentation levels. This makes for very difficult grokking of control flow, both in languages with significant whitespace and C-style languages. If programmers simply wrap their own lines, they can respect the white space conventions of their language and make it much easier for other developers to read later.

VS Code respects the indentation level (provided editor.wordWrap has some value other than "off" and editor.wrappingIndent has some value other than "none"). In other words, if a line needs to be split into 2 "virtual" lines to fit in the window, VS Code inserts a "virtual copy" of the line's initial whitespace before the second virtual line. By "virtual copy", I mean that the copy of the whitespace is never inserted into the file, but is added during the rendering of the contents of the file into the window.

Emacs on the other hand, has the problem you describe, and probably always will because of how hard xdisp.c is to modify and because the maintainers of Emacs probably do not consider the problem important enough to justify a big change to xdisp.c.

I was never a vim user, but my cursory investigation led me to conclude that vim, too, has the problem you describe.

The parent assumes that word wrap, a feature we take for granted today, is even a thing in the editors/terminals of legacy systems that this 80-character rule likely targets.

> I'd say no more than half a standard monitor wide is the character limit.

So if "monitor wide" is 80 characters, like a DEC VT-100 terminal, or WYSE-50 or whatever, then we have a 40 column rule.