Does it help readability? Sometimes a long line is crappy, and sometimes breaking it up is terrible. I HATE how my python looks after pep-8 gets ahold of it. Before Go, I was team 120-ish instead of 80 as it tends to not break as many otherwise legible lines. After Go, I removed my 120 char ruler in my editor.
Is the 80 character line limit still relevant? (2008)
31–40 of 180 posts
Re: Is the 80 character line limit still relevant? (2008)
#32Earlier quoted context omitted.
Took me a second to realize ETA was "edited to add." I was very confused on what an estimated time of arrival meant, here. :) I'm surprised reading on a phone is common. Not at all something I would want to do. I'm assuming largely read only there? Makes me curious if the CWEB idea of styling specifically for reading has extra merit in that flow?
I don’t know how “common” it is, but (like I said in my comment) the only reason I read code on my phone is that I am often on a bus or a subway. The comment about assuming I only read on my phone is bizarre: you are putting words in my mouth for reasons I do not understand. When it comes to books I like paper, and I usually read long PDFs on a tablet.
[deleted]
Re: Is the 80 character line limit still relevant? (2008)
#33I have a line length limit I personally stick with, because it works for the display setup I have. But - I don't actually care all that much! I have truncate-lines off, word wrap mode on - or whatever the text editor calls it - so I never miss anything. You could do this too, and now the question of the character line limit becomes much less relevant.
Re: Is the 80 character line limit still relevant? (2008)
#34I think the answer is pretty clearly "no, but" (or "yes, if"). Of course it depends on what you're doing – if you're writing shell scripts, it might make sense to keep them at 80 characters in case you have to go down to the data center and edit them from a terminal because your network card failed. But for most code, there's no particular limit that makes sense (in my opinion). I'm somewhat against code formatting "…
I agree with you that writing readable and aesthetically pleasing code is more art than science (that can be expressed with deterministic rules), I still find some of the rules and rule-checkers beneficial (though I dislike strict formatters).
As such, 80 is as good a limit as any, and makes you think carefully about avoiding deep nesting of blocks, which is usually a good idea anyway. It also allows putting many windows side-by-side on a modern big 4k screen.
Re: Is the 80 character line limit still relevant? (2008)
#35> formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that. (I hate tabs, but will never :retab someone else's code.) My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything. I would have serious reservations about any team…
Consistency makes it easier to compare apples to apples and oranges to oranges.
Just like you don't want to allow both underscore_split, camelCase and TitleCase names in a single JSON object (or even different JSON objects returned by the same API), you might want more consistency overall to exactly avoid people's editors rewriting code someone else did (eg. you edit a module and your editor reformats the entire file).
Re: Is the 80 character line limit still relevant? (2008)
#36> formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that. (I hate tabs, but will never :retab someone else's code.) My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything. I would have serious reservations about any team…
I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.
This approach comes with the benefit of automatically fixing those who simply don't realize their editor's settings disagreed with/didn't pick up on the conventions the project follows.
Re: Is the 80 character line limit still relevant? (2008)
#37> formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that. (I hate tabs, but will never :retab someone else's code.) My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything. I would have serious reservations about any team…
I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.
> I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions.
...it occurs to me, this feels like you're conforming to the tool instead of the other way around.
Is there a reason git blame doesn't have an "ignore whitespace" option? Is it harder than it seems?
Re: Is the 80 character line limit still relevant? (2008)
#38> formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that. (I hate tabs, but will never :retab someone else's code.) My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything. I would have serious reservations about any team…
Consistency makes it easier to compare apples to apples and oranges to oranges. Just like you don't want to allow both underscore_split, camelCase and TitleCase names in a single JSON object (or even different JSON objects returned by the same API), you might want more consistency overall to exactly avoid people's editors rewriting code someone else did (eg. you edit a module and your editor reformats the entire file…
Well I just want to fix the bug or write the feature and move on, but some want other things from their code.
Re: Is the 80 character line limit still relevant? (2008)
#39I think the answer is pretty clearly "no, but" (or "yes, if"). Of course it depends on what you're doing – if you're writing shell scripts, it might make sense to keep them at 80 characters in case you have to go down to the data center and edit them from a terminal because your network card failed. But for most code, there's no particular limit that makes sense (in my opinion). I'm somewhat against code formatting "…
I agree with you that writing readable and aesthetically pleasing code is more art than science (that can be expressed with deterministic rules), I still find some of the rules and rule-checkers beneficial (though I dislike strict formatters). As such, 80 is as good a limit as any, and makes you think carefully about avoiding deep nesting of blocks, which is usually a good idea anyway. It also allows putting many win…
I have to push back here a little bit. It really depends.
I mainly use Scala, and I think the majority of Scala code would be far less readable if forced to 80 columns, than if it were a larger number (or simply unconstrained).
My WFH monitor is an Apple Thunderbolt Display, which is woefully out-of-date now. Even on this display, and even though I use a much larger font than most people (16pt Hasklig), and even with a generous project/navigation/etc sidebar, I still get 180 characters. The display I have in the office is even wider, but I can't measure it right now because I'm not there.
My point is, displays are now wide enough where arbitrary line limits don't make sense. Nobody is going to cram stuff into one line unnecessarily, so just leave it up to the local decision about what makes the code most readable. If for some reason a 240-character line is more readable in some situation, then we should talk about that situation rather than why they didn't break the lines.
Re: Is the 80 character line limit still relevant? (2008)
#40One minor advantage which wasn’t so relevant in 2008: 80 character lines are much easier to read on a smartphone. This is especially true for Safari on iOS, which always seems to make bad wrapping / sizing decisions with plain text. ETA: thinking back on it, several years ago I switched from 120 characters to 80 specifically because of this. I don’t have a car, so I read a lot of code on my phone while taking public…
Took me a second to realize ETA was "edited to add." I was very confused on what an estimated time of arrival meant, here. :) I'm surprised reading on a phone is common. Not at all something I would want to do. I'm assuming largely read only there? Makes me curious if the CWEB idea of styling specifically for reading has extra merit in that flow?
I've made edits to config files on the GitHub mobile app while on-call. Not something I like doing but I like having the option.