5 ms·
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
by nunofgs 10y ago
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"
- kornish 10y agoAs 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?
- paulddraper 10y agoScreen 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.
- foopod 10y agoI 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.
- ams6110 10y agoYes. 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.
- simplicio 10y agoWell, 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
- benwills 10y agoI 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.
- geoka9 10y agoI 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.
- nolemurs 10y agoIn 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!
- byllgrim 10y agoThis! It's not just an aesthetic preference. Like the tab limit, it is instrumental to impede bad logic.
- Cpoll 10y ago> 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.
- brudgers 10y agoThe 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.
- chj 10y agoIt'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.
- sedatk 10y agowith 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.
- derefr 10y agoThis 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!
- erik_seaberg 10y agoHaskell has a module block, but you don't need to indent the content because the block can end at EOF.
- a3n 10y agoWhile 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.
- morbidhawk 10y agoI 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.