review for unittests

[Andrei Alexandrescu]

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