Hacker News Reader

Comment by nunofgs | Hacker News Reader

Only thing I really don't agree with is the 80 char max.

I'm not suggesting unlimited but isn't it time we revisit this?

It really feels like one of those "we've always done it this way so just leave it"

In truth, longer lines would probably be fine, except that 99% of the time when your line is more than 80 characters long, there's a better way to do it with shorter lines. I've made a habit of reducing lines to 80 characters or less, and I would guess that for every 50 times I take a line I wrote that's 80-100 characters long and figure out how to split it into shorter lines, 49 of those times, the shorter version is better. That seems like a good reason to prefer the shorter line limit.

Note that it isn't a hard limit. The actual rule is "[s]tatements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information." So longer than 80 is fine, but only if it significantly increases readability. That sounds about right to me!

This! It's not just an aesthetic preference. Like the tab limit, it is instrumental to impede bad logic.

> In truth, longer lines would probably be fine, except that 99% of the time when your line is more than 80 characters long, there's a better way to do it with shorter lines.

myDescriptiveResultVariable = myDescriptiveMethod(myWordyVariable, myVerboseVariable);

That's 87 characters.

The Linux kernel coding style was developed to meet the needs of the Linux kernel project. When the code base is nearly 20 million lines, precedent counts.

Most projects aren't that big and don't have needs that are like the Linux kernel. There may be (and probably are) good reasons not to adopt its idiosyncratic choices.

I would disagree with the reason being "because we've always done it this way."

I started programming C full time about 2.5 years ago (after many more with PHP, et al). There's an aesthetic to writing C that I don't find with other programming languages. I believe this is, in part, due to the generalized use of shorter variables and keeping everything as compact and simple as possible.

Since deciding to keep everything at an 80-char width, I can say that it has helped me maintain a certain kind of readability I don't find with other languages. And, while aesthetics don't matter once the compiler takes over, I can say that good aesthetics do improve my ability to program more effectively and efficiently.

I second that, and want to add that scanning a shorter line is easier on the eyes, too. There's a reason typography conventions limit line width to 60-70 characters.

As someone who routinely has 5 or 6 files open in various configurations of Emacs windows, 80 char max is a huge convenience. Out of interest, what's changed since it became a norm which would make it worth reexamining?

Screen size. On my two 24 inch monitors, I can easily have four side-by-side files with 100 characters and a large font size.

This being HN, naturally someone's going to tell me they do most of their programming on a 7 inch terminal screen.

But 80 chars comes with a cost: over terse code, or a lot of scrolling.

Exactly, I do the same: dual 24-inch monitors with 4 windows, and a 100-character line limit.

Very true. Perhaps I'll have to switch to 100 characters for personal projects.

I heard once that it was because punch cards were 80 columns. But my guess is screen resolution? We have much higher definition screens and can fit more on a line now? Should we have longer lines of code? Probably not. Could we? Heck yeah.

Yes. Punch cards were 80 columns. Later, Teletypes for the most part were also (I think some could do 132 columns). Then terminals like the VT100 carried this forward (again, some could do more, but 80 was still the default and they added the 24-line convention). The IBM PC kept to this standard also. And in 2017, the "default" terminal window is still 80x24.

Well, no ones coding on a VT100 terminal anymore :) It started as a physical constraint. Most computers, even laptops, have wide enough screens that 80 characters looks kinda compressed.

Personally, I've started using 100 columns for personal projects. But I stick to 80 for anything someone else is going to have to look at. To some extent, its more important to have a standard, so you don't have to worry about weird line-wrapping placements when someone else looks at your code, than it is to have one that fits superwell on the average modern screen. So we're probably stuck with 80

While it's true that most of us have more than 80 character width displays most of the time, reducing the strength of that argument ... I dislike having to turn my head to read a long line. Personal preference of me.

I also think that code that has been constrained to 80 columns reads better. Personal opinion of me.

I agree that it reads a lot better and if you have to scroll horizontally it reads a whole lot worse, as a C# dev I have to constantly scroll back and forth to read a particular code block. I'm pretty sure C# code would fail terribly at fitting within 80 chars w/ its long names and generic type declarations and everything being indented withing a namespace it'd practically be useless to try to edit C# code from a shell interface.

It's impossible to place such a limit on Java/C#, but for C, it's not that hard especially if you go for 4 spaces indentation.

with c# you need at least two more indents for class and a completely frivilous namespace block. i wish c# had adopted java's namespace syntax too.

This reminds me of one diamond-in-the-rough of Erlang's syntax: rather than a module block, you just have a module-name attribute at the top of each file (where the entire file is then related to that module.) Your functions are just right there against the left of your screen!

Haskell has a module block, but you don't need to indent the content because the block can end at EOF.

Reply on news.ycombinator.com