review for unittests

Jonathan M Davis jmdavisProg at gmx.com
Sat Jan 29 23:37:03 PST 2011


On Saturday 29 January 2011 23:08:49 Jonathan M Davis wrote:
> 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));

Hmmm. The HTML seems to have been lost when I sent it (I don't normally try and 
put HTML in e-mails, so I guess I screwed it up), so the code isn't formatted 
properly...

The idea, at least, is that the first one lines up the arguments for each 
function call, the second one just indents the second line, and the third one 
lines up the beginning of the second line with what's on the right-hand side of 
the assignment. It'll probably look correct if you copy and paste it into a code 
editor.

- Jonathan M Davis


More information about the Digitalmars-d mailing list