71–80 of 180 posts
Earlier quoted context omitted.
IMO 120 is the extreme limit but a good limit. Anything higher than 120 is to long and, personally, I'd ask for that to be fixed in a code review.
120 is way too small. IMO 180 is a good limit. We're not on 800x600 screens anymore
Long lines are less readable and I want to have several terminal panes or editor windows side by side.
> This is because, back in the bad old days, most computer terminals could only display 25 rows of 80 columns of text on screen at once. And this is because, back in the super old days, most computers used punched cards. Which had 80 columns.
Back in the super-super-super old days, looms were "programmed" using paper tape, which eventually influenced the 24-column Hollerith cards for the 1930 census, and ultimately resulted in a horrific application of technology.
Earlier 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.
Earlier quoted context omitted.
IMO 120 is the extreme limit but a good limit. Anything higher than 120 is to long and, personally, I'd ask for that to be fixed in a code review.
I just bought an ultrawide, and I just checked to see how wide my lines are in my code editor. 350 characters. When I'm coding for myself, I use all of that at times. I love that there are some things I no longer have to break onto multiple lines any longer. Also, if you have a ton of nested loops etc, then you don't end up with that problem where you can only see the first few characters of the deepest lines.
1. Use of DOS programs.
2. Printing out on a paper.
3. Split screen.
4. Other people who view, with different screen resolutions, and preferences for font sizes, window sizes, etc.
These are also some reasons why you might still prefer to use a short line limit, too.
I maintain 80 characters in order to edit files side by side on a laptop screen without side scrolling. I seem to grok code better vertically too.
I love how everytime this debate comes up, the 80 character gang keeps adding more stuff to put side by side. Now we're shrinking the resolution/sizes of the devices we are using to justify it...
An 80 character limit is difficult to stay within when using highly descriptive variable names, and I think the benefits of highly descriptive variable names outweigh other considerations.
To me it is important to try to keep code concise so that it is easier to read. This applies to variable names as much as it does to how many lines a function is. The smaller the unit of functionality it is, the easier it is to understand in its entirety.
80 characters is way, way too short. I think 120 is a decent spot for today's displays, although I don't mind even longer than that either.
You want to be able to do side-by-side diffs on your laptop using a normal sized (not tiny) font.
You want to be able to paste snippets into design documents and emails and blogs without accidental wrapping or truncating or scrolling.
80 is nicely legible. It works really well.
Earlier quoted context omitted.
Well I just want to fix the bug or write the feature and move on, but some want other things from their code.
Yours is a good attitude in an org with thousands of engineers, where every change gets mediated through some process tool simply to avoid chaos. You'll be messing up the system if you step out of your lane, and you statistically don't even care about some particular project's health and future anyway. It's not a great one in smaller teams, which benefit from everybody quietly sweeping up whatever bit of the mess the…