7 ms·

> The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Th

> The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. There is some truth to this, but it's largely irrelevant. When text is laid out for books, it's based on a fixed width and each sentence follows the next. Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line width. Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed. But having the option to use longer lines when it makes the code more readable is also valuable. Putting a fairly short, arbitrary limits on line length just makes other parts of coding less pleasant, variable names in particular suffer quickly when you can't make comparisons on a single line. Where I work, we wrap lines at 120 characters but the overwhelming majority of the code is less than 80 characters wide. Longer lines are reserved for if statements with multiple conditions or ternary assignments.

l0b0 6y ago
Another reason the assumption that style rules for natural language is transferrable to code is kinda baffling. I wonder if there's ever been much research in this space which doesn't make that assumption.
- taeric 6y ago
  It is more than just natural language. You could look at math journals, for their jargon. Music notation. Recipes. Really, is there any writing that doesn't seem to apply?
  - fauigerzigerk 6y ago
    It doesn't apply to code to the same extent, because reading code rarely means reading every single line left to right. Also, lines ending on column 100 are not necessarily 100 characters long. There could be indentation on that line and on the next. Vertical alignment has meaning in code whereas it ususally doesn't have meaning in natural language text. So if you insert line breaks into code purely to follow some arbitrary rule, you are misleading readers into looking for meaning where there is none.
    - taeric 6y ago
      Same is true for most all reading. Skim then read, is a predominant form is reading. Is why newspapers scatter their stories throughout. Indeed, they punish linear reading... Recipes often do two columns of some things. Math jargon is all about repetition. Narrative, explanation, exposition. Don't get me wrong, I am inclined to agree with you. But we don't have a ton of empirical evidence on our side.
      - fauigerzigerk 6y ago
        >But we don't have a ton of empirical evidence on our side Neither does the other side, unless you accept the premise that reading natural language text is similar enough to reading heavily indented code where that indentation has meaning. I don't accept that at all. The studies that were done on natural language text assume that line length is equal to the column where the line ends (i.e all lines begin on the left edge). That's not usually the case for indented code. If reading long lines takes more effort because your eyes have to travel further to find the next line, then the amount of indentation the next line has matters are great deal.
        taeric 6y ago
        My point was that there is no writing that extends to long lines. If anything, the fact that no other writing form has made such extensive use of indentation is enough to give me pause and think if that is making any sense. (I do note the amusing lines in the Linux style guide on the use of heavy indentation.) And looking at this before I hit go. You seem to ultimate be agreeing. Taking opening indentation into consideration concedes that long lines are bad. You just give some room for margins. And are ok with all of the mental stacking that the indentation implies.
rmrfstar 6y ago
> If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems In math-heavy stuff, lines tend to be longer. You are usually trying to convert one line of math into one line of code. I myself shoot for 160 character columns. See, e.g. [1]. [1] https://docs.fast.ai/dev/style.html https://docs.fast.ai/dev/style.html
- ogre_codes 6y ago
  I agree, math is a perfect example where code is more clear to have a single long statement on one line. I am a bit skeptical that you have a big codebase with math on more than a quarter of the lines of code though. Most likely there are a lot of shorter lines between your formulas which is exactly my point here. When long lines improve readability/ clarity you should have the ability to use them.
JoeAltmaier 6y ago
Tell that to 'functional programming' people, or the lambda-crazy people who put entire functions in argument lists to the point you can't parse a statement to save your soul. I've had to print and highlight code to figure out where it began and ended.
- ogre_codes 6y ago
  > ...who put entire functions in argument lists to the point you can't parse a statement to save your soul. As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code.
  - u801e 6y ago
    > As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code. Isn't perceived difficulty of reading code correlated with how familiar one is with the language it's written in? For example, code may be harder to read for someone who lacks experience or is new to the language, but it's not difficult for someone who is experienced and is familiar with the language.
- dkersten 6y ago
  I mainly use Clojure and keep most of my lines under 80 characters.
ThrowawayR2 6y ago
> "Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed." I can't agree with that. When you've got class names like AbstractSingletonProxyFactoryBean and similar naming conventions for variables, 80 characters just isn't adequate a lot of the time.
- deepspace 6y ago
  To be fair though, if you have class names like AbstractSingletonProxyFactoryBean, then terminal width is the LEAST of your problems.
  - im3w1l-alt 6y ago
    You may be in a position where using a verbose framework or libraries save you way more effort than the small pain they bring.
    - yellowapple 6y ago
      You may also be in a position where you can alias those names to something more reasonable.
- ogre_codes 6y ago
  Just skimming our codebase, 20+ character variable names are fairly common. Even with verbose variable names, the majority of our lines of code are less than 80 characters. Probably 1 our of every 15-20 lines of code stretches longer and we greatly appreciate that we can go longer, but the majority are shorter.
naikrovek 6y ago
> Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed. This kind of thing is really obtuse and it drives me insane that so many people subscribe to ideas like these. This kind of thinking is what leads to linters with completely arbitrary rules telling me how I should solve my own problem. Me: "Hey linter, I'm going to shadow a variable name here, because that's the right thing to do in this situation, so shut up about it." Linter, and 5 billion HN commenters: "you're shadowing a variable. Compile warning." Me: "it's a language feature, and it's ok to use." Linter: "you're shadowing a variable. Compile warning." Etc. Arbitrary rules like line width (and I assure you, those rules ARE arbitrary) help exactly 0 people per day, and cause problems for more than 0 people per day. I PROMISE that a human brain is better at discovering general code quality problems than the best linter with the best rules, and that will be true until a time when every reasonable computer is a general purpose AI. Yes, tell me when I have a memory leak. Use static analysis to tell me about weird issues I have difficulty seeing. I know best about line width and how to solve things in my own application better than any linter could ever hope to, because linters do not have anything approximating the intelligence of gnat, nevermind a human being.
- labawi 6y ago
  > Arbitrary rules like line width help exactly 0 people per day I use a linter, it warns about long lines (adjusted to 100), so I reformat or split them and the code seems more readable. Also, it has consistent formatting (other rules), though I occasionally mark some lines to be ignored. I'd say it helps me, which is >0 people. You don't have to follow norms and/or best practices, but some find it useful.
- shultays 6y ago
  When is shadowing is right thing to do? Why picking a new variable name wouldnt work?
  - naikrovek 6y ago
    No matter what I say here, I feel it would be very likely you will tell me I'm wrong.
dragonwriter 6y ago
> Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line width. No, it doesn't, especially for code that isn't written in a very basic simplistic imperative style. Expressions have no natural size limits (and statements, in languages that even have them, can generally each contain one or more expressions.) Languages tend to develop conventional line width limits and conventions for where to prefer to break within expressions to achieve them, but there is no natural length limit to the length of a single statement.

l0b0 6y ago

Another reason the assumption that style rules for natural language is transferrable to code is kinda baffling. I wonder if there's ever been much research in this space which doesn't make that assumption.

taeric 6y ago
It is more than just natural language. You could look at math journals, for their jargon. Music notation. Recipes. Really, is there any writing that doesn't seem to apply?
- fauigerzigerk 6y ago
  It doesn't apply to code to the same extent, because reading code rarely means reading every single line left to right. Also, lines ending on column 100 are not necessarily 100 characters long. There could be indentation on that line and on the next. Vertical alignment has meaning in code whereas it ususally doesn't have meaning in natural language text. So if you insert line breaks into code purely to follow some arbitrary rule, you are misleading readers into looking for meaning where there is none.
  - taeric 6y ago
    Same is true for most all reading. Skim then read, is a predominant form is reading. Is why newspapers scatter their stories throughout. Indeed, they punish linear reading... Recipes often do two columns of some things. Math jargon is all about repetition. Narrative, explanation, exposition. Don't get me wrong, I am inclined to agree with you. But we don't have a ton of empirical evidence on our side.
    - fauigerzigerk 6y ago
      >But we don't have a ton of empirical evidence on our side Neither does the other side, unless you accept the premise that reading natural language text is similar enough to reading heavily indented code where that indentation has meaning. I don't accept that at all. The studies that were done on natural language text assume that line length is equal to the column where the line ends (i.e all lines begin on the left edge). That's not usually the case for indented code. If reading long lines takes more effort because your eyes have to travel further to find the next line, then the amount of indentation the next line has matters are great deal.
      - taeric 6y ago
        My point was that there is no writing that extends to long lines. If anything, the fact that no other writing form has made such extensive use of indentation is enough to give me pause and think if that is making any sense. (I do note the amusing lines in the Linux style guide on the use of heavy indentation.) And looking at this before I hit go. You seem to ultimate be agreeing. Taking opening indentation into consideration concedes that long lines are bad. You just give some room for margins. And are ok with all of the mental stacking that the indentation implies.

rmrfstar 6y ago

> If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems In math-heavy stuff, lines tend to be longer. You are usually trying to convert one line of math into one line of code. I myself shoot for 160 character columns. See, e.g. [1]. [1] https://docs.fast.ai/dev/style.html https://docs.fast.ai/dev/style.html

ogre_codes 6y ago
I agree, math is a perfect example where code is more clear to have a single long statement on one line. I am a bit skeptical that you have a big codebase with math on more than a quarter of the lines of code though. Most likely there are a lot of shorter lines between your formulas which is exactly my point here. When long lines improve readability/ clarity you should have the ability to use them.

JoeAltmaier 6y ago

Tell that to 'functional programming' people, or the lambda-crazy people who put entire functions in argument lists to the point you can't parse a statement to save your soul. I've had to print and highlight code to figure out where it began and ended.

ogre_codes 6y ago
> ...who put entire functions in argument lists to the point you can't parse a statement to save your soul. As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code.
- u801e 6y ago
  > As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code. Isn't perceived difficulty of reading code correlated with how familiar one is with the language it's written in? For example, code may be harder to read for someone who lacks experience or is new to the language, but it's not difficult for someone who is experienced and is familiar with the language.
dkersten 6y ago
I mainly use Clojure and keep most of my lines under 80 characters.

ThrowawayR2 6y ago

> "Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed." I can't agree with that. When you've got class names like AbstractSingletonProxyFactoryBean and similar naming conventions for variables, 80 characters just isn't adequate a lot of the time.

deepspace 6y ago
To be fair though, if you have class names like AbstractSingletonProxyFactoryBean, then terminal width is the LEAST of your problems.
- im3w1l-alt 6y ago
  You may be in a position where using a verbose framework or libraries save you way more effort than the small pain they bring.
  - yellowapple 6y ago
    You may also be in a position where you can alias those names to something more reasonable.
ogre_codes 6y ago
Just skimming our codebase, 20+ character variable names are fairly common. Even with verbose variable names, the majority of our lines of code are less than 80 characters. Probably 1 our of every 15-20 lines of code stretches longer and we greatly appreciate that we can go longer, but the majority are shorter.

naikrovek 6y ago

> Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed. This kind of thing is really obtuse and it drives me insane that so many people subscribe to ideas like these. This kind of thinking is what leads to linters with completely arbitrary rules telling me how I should solve my own problem. Me: "Hey linter, I'm going to shadow a variable name here, because that's the right thing to do in this situation, so shut up about it." Linter, and 5 billion HN commenters: "you're shadowing a variable. Compile warning." Me: "it's a language feature, and it's ok to use." Linter: "you're shadowing a variable. Compile warning." Etc. Arbitrary rules like line width (and I assure you, those rules ARE arbitrary) help exactly 0 people per day, and cause problems for more than 0 people per day. I PROMISE that a human brain is better at discovering general code quality problems than the best linter with the best rules, and that will be true until a time when every reasonable computer is a general purpose AI. Yes, tell me when I have a memory leak. Use static analysis to tell me about weird issues I have difficulty seeing. I know best about line width and how to solve things in my own application better than any linter could ever hope to, because linters do not have anything approximating the intelligence of gnat, nevermind a human being.

labawi 6y ago
> Arbitrary rules like line width help exactly 0 people per day I use a linter, it warns about long lines (adjusted to 100), so I reformat or split them and the code seems more readable. Also, it has consistent formatting (other rules), though I occasionally mark some lines to be ignored. I'd say it helps me, which is >0 people. You don't have to follow norms and/or best practices, but some find it useful.
shultays 6y ago
When is shadowing is right thing to do? Why picking a new variable name wouldnt work?
- naikrovek 6y ago
  No matter what I say here, I feel it would be very likely you will tell me I'm wrong.

dragonwriter 6y ago

> Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line width. No, it doesn't, especially for code that isn't written in a very basic simplistic imperative style. Expressions have no natural size limits (and statements, in languages that even have them, can generally each contain one or more expressions.) Languages tend to develop conventional line width limits and conventions for where to prefer to break within expressions to achieve them, but there is no natural length limit to the length of a single statement.