On 01/30/2011 01:08 AM, Jonathan M Davis wrote:
I'm afraid that we're going to disagree on this one completely. Restricting code to 80 columns makes formatting a mess.
Apparently it's not a problem for all of my employers. All had such a standard. Facebook uses highlight-80+ with emacs and a commit hook to simply prevent lines longer than 80 characters from making it into the repository.
So whereas I understand that you may not like the rule, I refute the implied objectivity of that argument. Code that fits in 80 columns is not a mess at least for some people.
You start doing things like breaking the next line based on how close it is to 80 columns rather than where it would make sense to break it based on the statement itself.
A statement that is so long is either over-indented or too long. In either case it should be breakable into bite-sized chunks. You need to break it to allow readers to read it easily, not to conform to an arbitrary rule.
Often, you're forced to put the remainder of the line on the next line simply indented somewhat more than the previous line rather than indenting it far enough to line up paretheses and function arguments. I much prefer lines that look like auto a = func(replace(str, "hello", "world"), 13 + max(b, c)); to auto a = func(replace(str, "hello","world"), 13 + max(b, c)); or auto a = func(replace(str, "hello","world"), 13 + max(b, c)); Formatting becomes a _big_ problem when you force 80 character lines - _especially_ if you use descriptive names for functions and variables.
You'd be hard pressed to explain how quality code can arguably be written within 80 characters.
And if you allow for greater than 80 character lines, then lines that would 90 or 100 characters and look just fine can be left on one line without having to worry about formatting problems at all.
I worry that I don't see the code, or that it comes off stilted at the beginning of the next line.
The problem becomes particularly bad if you have code with multiple levels of scope. All of a sudden, your inner loop has to have all of its code take multiple lines just because it's indented far enough to be close to 80 characters.
Then the function is poorly written and needs to be refactored. The problems are never with the 80 characters. I appreciate that you have a different perspective because you have been used to writing e.g. 100-columns code, and you believe you'd be incredibly constrained otherwise. Believe me: you will write better code in 80 lines.
The _only_ reason I see to restrict the number of columns on a line like that is for printing code. If you make lines too long, they won't fit on paper. But they'll fit just fine on a computer screen at well beyond 80 columns. With gvim, a line with 80 columns takes up less than a third of my screen - and that's with stuff like line numbers being shown. Unless you're specifically restricting the size of your edit windown to 80 columns, I don't see why having more than 80 characters on a line would be a problem.
When you read a website, you don't maximize the browser (besides many sites forcibly limit the width of their text). Newspapers have columns to maximize parsing speed for their readers.
And sure, you don't want lines getting to be 120 characters long and the like. There is a limit to how much it makes sense to put in a single statement.
Let's choose that limit to be 80 characters.
However, I have routinely found that when I've been restricted to 80 column lines, code becomes far harder to format properly, statements which really should be on one line are forced to be on multiple lines because they're a bit passed 80 characters, and the code is harder to read.
I refute that because again there is overwhelming evidence to the contrary.
I find that code is formatted much better when you're not strict about the length of lines and the like. You try and limit how long lines get, and you break them up on multiple lines when they start getting too long, but if you're strict about it, lines quickly become ill-formatted and harder to read.
I understand. I hope you also understand that your argument has only subjective basis, with you as the subject. You are literally only the second or third fellow coder to ever tell me such.
Jonathan, I won't continue debating this. There is something to be said about picking one's fights, and that goes both ways. I will only say this.
Phobos is a team effort. As such, there is a simple necessity to find ways to live and let live in relative harmony. This means conforming to conventions that are not the most comfortable to us (that includes me; my favorite bracing is the one in TDPL, but when I write Phobos code I use Walter's). Also, there is sometimes a need to conform to authority that we might sometimes not agree with; but as certain decisions are subjective, some de facto authority must make some decisions to simply keep the style somewhat consistent. It's unclear how authority comes about but it's reasonable to say that Walter's and my word have a somewhat larger weight because we wrote most of Phobos.
I consider code that goes over 80 columns problematic, and I refactor it when I have the chance. This means that your commits mean more work for me. If you chose to use 80 columns, you'd be nice towards me and probably the other Phobosians, and you would get used to a widely used convention, which improves your adaptability to various workplaces.
Andrei
