On 04/10/2011 10:15 AM, Robert Jacques wrote:
> My take would be a soft limit at 80 and a hard limit at min(80+indent, some_upper_limit). Also, we should consider if short, inline comments and assert/enforce error messages should have a different soft limit than regular code. (i.e. recommend code in lines 1-80 with brief comments in 80-100/120.)

+++

(Not a Phobos contributor). I find silly and annoying to artificially split single-line string defs in general. Would make a no-limit for this.

         enum valueRangeErrorFormat = "Expected numeric value in range %s..%s,
\n" ~
                                      "found: %s.";    // GRRR!

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

> 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

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.

- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110410/4f26c1f1/attachment.html>

I wanted to make it clear that this is not the time to bring again the arguments, as there have been ample discussions on the topic in the past. In particular your arguments that you now repeated have been definitely read and understood, as well as refuted.

This is the time to conclude all that discussion with a simple decision. Again, clearly some limit must exist because current code editors don't handle long lines satisfactorily and some contributors want to keep editing windows less than most or full screen width.

I think a soft limit (very strongly recommended) of 80 columns and a hard limit (absolute, forget about merging your code if you don't observe) of 120 columns would be agreeable to all current and potential contributors.


Thanks,

Andrei

On 04/10/2011 12:04 PM, Jonathan M Davis 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

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>

> I wanted to make it clear that this is not the time to bring again the arguments, as there have been ample discussions on the topic in the past. In particular your arguments that you now repeated have been definitely read and understood, as well as refuted.

Well, I definitely disagree that they were refuted rather than only argued against, but it's obvious that we're never going to agree.

> This is the time to conclude all that discussion with a simple decision. Again, clearly some limit must exist because current code editors don't handle long lines satisfactorily and some contributors want to keep editing windows less than most or full screen width.
>
> I think a soft limit (very strongly recommended) of 80 columns and a hard limit (absolute, forget about merging your code if you don't observe) of 120 columns would be agreeable to all current and potential contributors.

That's fine with me.

What I really don't want to see is a hard limit of 80. And I'll code to whatever we decide. But I definitely would like it if we could just reach a decision on this and be done with it.

- Jonathan M Davis

On 4/10/2011 2:08 PM, Jacob Carlborg wrote:
> 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.
>

One thing I find helps specifically for function declarations is to put every parameter on its own line, like the following:

SomeLongType someFunction(
     ParameterType1 parameter1,
     ParameterType2 parameter2,
     SomeEnumType flag1,
     SomeOtherEnumType flag2
) const pure nothrow {

     // Function body.
}

This is much more readable for long functions with more than 2-3 parameters and long, verbose names than putting the entire function declaration on one line.

On 04/10/2011 01:12 PM, Jonathan M Davis wrote:
>> I wanted to make it clear that this is not the time to bring again the arguments, as there have been ample discussions on the topic in the past. In particular your arguments that you now repeated have been definitely read and understood, as well as refuted.
>
> Well, I definitely disagree that they were refuted rather than only argued against, but it's obvious that we're never going to agree.

To the extent the arguments were of the flavor "I can't figure how anyone could find 80 columns enough", they were effectively refuted by the simple fact that a lot of Phobos code does actually obey the limit.

>> This is the time to conclude all that discussion with a simple decision. Again, clearly some limit must exist because current code editors don't handle long lines satisfactorily and some contributors want to keep editing windows less than most or full screen width.
>>
>> I think a soft limit (very strongly recommended) of 80 columns and a hard limit (absolute, forget about merging your code if you don't observe) of 120 columns would be agreeable to all current and potential contributors.
>
> That's fine with me.
>
> What I really don't want to see is a hard limit of 80. And I'll code to whatever we decide. But I definitely would like it if we could just reach a decision on this and be done with it.

OK. 80/120.


Andrei

110

Sent from my iPhone

On Apr 9, 2011, at 4:02 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:

> I must bring this back into discussion because it seems the recent traffic in the matter left the impression that "anything goes".
> 
> We have a pull request (https://github.com/D-Programming-Language/phobos/pull/27) with at least one line that is 195 characters long and others of comparable lengths.
> 
> I think as far as presenting arguments the ship has sailed. Let's now agree on a maximum line length. What should that be? 80? (Yes please.) 100? 120? Give me your vote for a number, but please let's avoid reviewing telex rolls going forward.
> 
> 
> Thanks,
> 
> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Same. Revise the 110 comment.

Sent from my iPhone

On Apr 9, 2011, at 5:45 PM, Brad Roberts <braddr at puremagic.com> wrote:

> I don't contribute to phobos much, but regardless, hard 80 is too few, though soft 80 with a hard limit near 100 would match my habits quite well.
> 
> On 4/9/2011 4:02 PM, Andrei Alexandrescu wrote:
>> I must bring this back into discussion because it seems the recent traffic in the matter left the impression that "anything goes".
>> 
>> We have a pull request (https://github.com/D-Programming-Language/phobos/pull/27) with at least one line that is 195 characters long and others of comparable lengths.
>> 
>> I think as far as presenting arguments the ship has sailed. Let's now agree on a maximum line length. What should that
>> be? 80? (Yes please.) 100? 120? Give me your vote for a number, but please let's avoid reviewing telex rolls going forward.
>> 
>> 
>> Thanks,
>> 
>> Andrei
>> _______________________________________________
>> 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