5 ms·
> Relatedly, the 80 column "rule" is as stupid in code as it would be in prose. Use your aesthetic sense. Horizontal scrolling is almost always a bad experienc
by 908B64B197 6y ago
> Relatedly, the 80 column "rule" is as stupid in code as it would be in prose. Use your aesthetic sense.
Horizontal scrolling is almost always a bad experience for the user. But 80 is way too restrictive. I'd say no more than half a standard monitor wide is the character limit. What's a standard monitor depends on what's used by the devs writing the code of course.
> Source code should liberally use Unicode symbols.
Give it a few years. But make sure there's a good normalization (there are several ways to print the same glyph on the screen that are different bytes in memory)
- spideymans 6y agoThe 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.
- skrtskrt 6y agoFor both Python and Go I use descriptive (often long) names and ~90-char line limit, and use linebreaks liberally to reconcile the two
- bjourne 6y agoDescriptive naming usually isn't. E=m*c^2 or objectEnergyInJoule = massOfObjectInKilograms * speedOfLightInVacuum^2 ?
- DangitBobby 6y agoNow 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
- bjourne 6y agoThe first one, no question about it.
- kazinator 6y agoYes. 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)
- spideymans 6y agoWith 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.
- DangitBobby 6y agoOpposite of my choice of which I also have no question.
- Viliam1234 6y ago> Also 80 columns is near impossible to adhere to for more verbose language. Not if you use Unicode (and Chinese language).
- josephg 6y agoAt 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.
- pc86 6y agoI 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.
- Brian_K_White 6y agoIt'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.
- elektronaut 6y agoThis 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.
- moron4hire 6y agoI just enable word wrap in my editor
- layer8 6y agoI 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).
- lostmsu 6y agoAlso sometimes comments.
- layer8 6y agoNah, comments are important and should be in the main field of view. :)
- iandinwoodie 6y agoI 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.
- selfhoster11 6y agoHorizontal 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.
- lolinder 6y agoLine 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.
- xigoi 6y agoVim has a setting to make line wraps start at the same indent as the line.
- egypturnash 6y agoWord wrap. Turn on word wrap.
- lolinder 6y agoIn 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.
- hollerith 6y agoVS 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.
- metaphor 6y agoThe 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.
- deleted 6y ago[deleted]
- kazinator 6y ago> 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.