Slashdot Mirror
Is the 80 Columns Limit Dead?
Dancing Primate asks: "Reading through the code of co-workers and various open source projects, I'm finding that people are no longer formatting their code to 80 columns. With most people using X and the wide range of non-vi editors, is the 80 column limitation disappearing? Am I the only one who gets grumpy when I do a diff or print code, and it's hard to read?"
I know in a lot of my coding classes at U of T they required no more than 80 characters on a line, lest you get some hefty mark deductions. I dont stick to it for my stuff tho i usually limit it to when my screen starts scrolling to the right....
Because of the way that people name their methods and variables now (int IHaveToDoABunchOfNiftyStuffHere( INT nThisIsAReallyImportantInt ) ) 80 columns isn't particularily feasible. That said, I don't understand why people don't just standardize on a column width and stick with it. When I first started working here, I tried to work within 80 columns, but my coworkers hated it when I reformatted their code, and I hated it when they touched mine. Now I format to 132 columns, and nobody really notices when I reformat their code to fit.
All the important stuff happens at the END of the line. It's where the actual methods get called and the work gets done. Seeing the beginning the line is usually entirely meaningless, and I hate scrolling to have to see the end of the line at 160 characters. I've already got my hands on the keyboard, and the mouse isn't a tool that I can use to input code, so it's just a waste of my time to put my hand on it. Most editors even indent and format the code pretty nicely if you manually break the line in a language like C or C++ which don't care about whitespace.
It doesn't really matter what the column width is as long as
1) Everyone sticks to it
2) You don't have to scroll to see the end of the line.
We're still suffering from the days of card readers and punches.
I've not punched a card since 1981. But I've edited lots of MVS (aka OS/390 aka z/OS) datasets that are fixed to 80 bytes (sequence in 73-80) by the architecture.
Sigs. We don't need no steenking sigs.
Right, what happens if you do this is that the bozo that has tabs=4 sometimes uses tabs and sometimes uses spaces, and then when you try to load it into an editor with 8-character tabs, the indentation is all screwy. Whereas if everybody uses 8-character tabs, which is the usual meaning of ascii character number 9, then this never happens.
The bottom line, though, is that this is a religious war, and as the person who's currently at the top of the list said, it's better for a team to just agree on what the indentation style is going to be, and stick with it. Otherwise you wind up with non-terminating flame wars (or terminated team members).
There are a few things in your post that you seem to feel strongly about, which are plainly false or wrong, and which made me think twice about replying. But I'll do it anyway.
First, the emacs interface is not idiotic. It's not idiot-friendly, I give you that. vi's and emacs' interfaces do not suck. They are however tools meant to increase productivity if you spend the effort to learn them. And they do. If you go by the definition that a good UI is one you can just start using, then they don't have a good UI. Their are powerful tools way beyond joe or pico or whatever it is you consider a good UI that is not "broken".
TAB is a special character. It is not printable, you need to convert it to a series of spaces to do that. Treating it as a character would mean inserting ONE item in the line, not a variable number depending on your current position.
Finally, think about it for a moment.
- A file with space indentation will look the same everywhere.
- A file with TAB indentation will look good only when your TAB width setting happens to match the author's, so when you open such a file you have to figure that out and change your TAB setting first (which gets old really fast).
The reason for that is that not all code starts on a TAB boundary, some of them may have a few more spaces (for example where wrapping a function call). Which begins to look nasty when your idea of what a TAB is differs from the author's. And don't say that everyone should use the standard 8-space TAB to fix that problem.
Lots of programs already use TAB for something else, emacs is not the only one. Bash is another one. Any decent command-line interface now uses TAB for auto-completion. I'm sure there are other examples. If TAB were really a character they would just display it instead, I suppose.
The first one makes code folding useless.
I'd paste an example, but the slapdash lameness filter won't let me, so just paste the code into vim, add (expression) after the if statement (not needed, but shows a point), and set these things:
:set foldenable
:set foldmarker={,}
:set foldmethod=marker
then "zc" while on the if { line and it should collapse all of that block down to one line showing the if statement, indentation level, and how many lines are folded. Now try it on the first method, and it has no idea what the if statement is which now awkwardly sits on top.
Which ones easier to work with?
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx