[phobos] Column limits again

[Jacob Carlborg]

On 10 apr 2011, at 19:28, Cliff Hudson wrote:

> If you have that much nesting, I would argue your code needs to be refactored.  All block level constructs within a function can themselves be made functions and removed from their original locality.  This doesn't necessarily have to reduce readability and frequently can improve it.  I am of the *general* opinion that if the method cannot fit onto a single page, then refactoring it is probably in order.  
> 
> Move switch cases to their own methods.  Sets of logically-related nested if's can be moved to their own cases as well (for the same reasons.)  Usually the work of a method is done in its leaf blocks, not in the setup which selects the appropriate leaf and it's often fair to consider them separately.  With good editing tools (which all of us have access to) there is almost no cost to having the code split up either.  Maybe when everyone was using edlin massive nested functions were acceptable - even necessary - but this is the 21st century.  Use the equivalent of 'Go To Definition' or open up another view of your code to see the implementation at the same time.
> 
> As for the difference between 80 and 120, I don't really care.  I would be more concerned actually about the reasons we are reaching that limit, particularly if it's due to excessive nesting.

To start with, if you're using an object orient language like D is, and using classes in your code you basically always loose four columns. Next, if you're writing platform specific code with static if's you're loosing another four columns. If you're also going to annotate all you're functions/methods to take full advantage of D's type system you quickly get quite long function decelerations. @property, @safe, nothrow, const/immutable (possibly several times), template constraints and others.

Have a look at the std.net.isemail module I'm writing: https://github.com/jacob-carlborg/phobos/blob/isemail/std/net/isemail.d

I'm the first one to say that this function is way too long but I*m finding it hard to split it up. But lets focus on the column width instead. This function deals a lot with email status codes which is declared as an enum. Everywhere the function is referring to an email status code it needs to be prefixed with the name of the enum, EmailStatusCode. Since I'm also having quite long names for the enum members, to make them more descriptive, it's quite hard to keep statements within the 80 column limit, even 120 columns. Look at the unit tests.

> - Cliff  
> 
> On Sun, Apr 10, 2011 at 10:04 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > 80 characters.  Not a phobos contributor, but I've been coding for 20 years
> > in various languages.  Long lines are hard to read - almost invariable
> > nasty compound expressions (which should be factored for readability) or
> > extremely long identifier names (nothing wrong with this, but ids should
> > be as long as necessary and no longer.  There is no benefit to putting so
> > much stuff onto a single line.
> >
> > If you don't like coding style rules, tough - welcome to the real world.
> >  Until we write an IDE that operates on ASTs and formats code on an
> > individual basis, we will continue to have to do these things.
> >
> > P.S. As a general rule, maintain the formatting style of the file in which
> > you are making edits (spacing, bracing, etc.)
> 
> I confess that I've never understood why anyone would think that 80 characters
> was enough. And almost everyone that I've ever discussed it with prior to it
> coming up on the newsgroups here has thought that an 80 character limit was
> outdated and constraining, so to find folks here thinking that 80 characters
> is a good limit is very odd. It's just too short.
> 
> The main problem is indenting. If no code were indented, then 80 characters
> wouldn't be so bad. But when you indent much at all (especially with 4
> characters per level of indentation), 80 characters very quickly becomes too
> short. And if you have appropriately descriptive symbol names, then you're
> doubly screwed.
> 
> So, while a character limit may make sense, I don't understand how anyone
> could be happy with only 80 characters. Sure, there are plenty of lines of
> code that will fit within 80 characters, but it doesn't take much at all
> before they don't - particularly with 4 characters per level of indentation
> and properly descriptive variable names. 80 is just too restrictive. 80
> characters after the indentation wouldn't generally be a problem, but when it
> includes the indentation, it's definitely a problem.
> 
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110410/7b3038be/attachment.html>