review for unittests

[Jonathan M Davis]

On Saturday 29 January 2011 22:10:29 Andrei Alexandrescu wrote:
> On 01/29/2011 09:48 PM, Jonathan M Davis wrote:
> > You mean 80 lines of code in the examples or in the actual code? I'm fine
> > with 80 columns for examples, but I'll go insane if we start requiring
> > 80 columns for normal code. That starts getting restrictive and ugly
> > _really_ fast.
> 
> Yes, once you go beyond 80 columns.
> 
> > You're
> > quickly forced to put the next part of a statement on the next line just
> > because you're hitting the 80 character limit instead of properly lining
> > things up, and it makes them much harder to read.
> 
> When Gutenberg built the first press, the resolution and the coarseness
> of the paper forced him to make the sheets pretty large. Since then the
> resolution of printing has increased amazingly, but people quickly
> figured out that reading is seriously impaired if the layout has more
> than about ten words per row of text. So in the hundreds of years that
> people have had available for improving printing media, the ten words
> pattern has stayed put. It's a human constant.
> 
> Such a measure definitely to code, too. 80 columns should be enough for
> writing and reading meaningful code. Lines that go significantly beyond
> that limit have an intrinsic readability problem.

I'm afraid that we're going to disagree on this one completely. Restricting code 
to 80 columns makes formatting a mess. 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. 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. 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. 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.

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.

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. 
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 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.

- Jonathan M Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110129/f776aa1d/attachment-0001.html>