www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - [Rosettacode] D code line length limit

reply "bearophile" <bearophileHUGS lycos.com> writes:
So far in Rosettacode D entries I've kept a line length limit of 
72 or 73 chars.

But now a little larger monitors are common, D UFCS chains are 
common, and we also have longer function signatures with "pure 
nothrow  safe  nogc" (that usually I put on a new line), so 
keeping that line length limit is becoming a little pain.

So probably I'll increase the maximum line length. Rosettacode 
rules forbids too much long lines, and while in my code I use a 
limit of about 90-100 in my code, this is too much for online 
wiki pages. So I'll do some tests, and I think for Rosettacode D 
entries I'll increase the limit to about 80 chars.

Bye,
bearophile
May 07 2014
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 7 May 2014 at 13:25:55 UTC, bearophile wrote:

 So far in Rosettacode D entries I've kept a line length limit 
 of 72 or 73 chars.

 But now a little larger monitors are common, D UFCS chains are 
 common, and we also have longer function signatures with "pure 
 nothrow  safe  nogc" (that usually I put on a new line), so 
 keeping that line length limit is becoming a little pain.

 So probably I'll increase the maximum line length. Rosettacode 
 rules forbids too much long lines, and while in my code I use a 
 limit of about 90-100 in my code, this is too much for online 
 wiki pages. So I'll do some tests, and I think for Rosettacode 
 D entries I'll increase the limit to about 80 chars.

 Bye,
 bearophile


Maybe D programmers need to adopt a new convention for 
annotations in the long term. Instead of:

void doSomething(int n) pure  safe  nogc nothrow
{
}

We should write:

pure  safe  nogc nothrow
void doSomething(int n)
{
}

The only problem being that this conflicts with the convention 
for UDAs...
May 07 2014
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Wed, 07 May 2014 13:39:55 +0000
Meta via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:

 Maybe D programmers need to adopt a new convention for
 annotations in the long term. Instead of:

 void doSomething(int n) pure  safe  nogc nothrow
 {
 }

 We should write:

 pure  safe  nogc nothrow
 void doSomething(int n)
 {
 }


My eyes... Oh, how that hurts readibily. Obviously, folks are free to format
their code how they like, but I very much hope that that style never becomes
prevalent. About the only place in a signature that I like to break it up
across lines is with the parameters, and I generally will let the signature
line get to the limit before I will break it up (which in the case of Phobos,
would be 120 characters, since it has a hard limit of 120, and a soft limit of
80 - and functions are one place where I will definitely go passed the soft
limit).

Regardless, formatting code is one are that's always going to be highly
subjective.

- Jonathan M Davis
May 07 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 7 May 2014 at 14:40:37 UTC, Jonathan M Davis via 
Digitalmars-d-learn wrote:

 My eyes... Oh, how that hurts readibily.


While I agree that

pure  safe  nogc nothrow
void doSomething(int n)
{
}

is quite ugly, it is really not much worse than

void doSomething(int n) pure  safe  nogc nothrow
{
}

I would argue that the latter hurts readability more, as parsing 
meaning from long lines is difficult for humans. Also, we can 
always go deeper ;-)

extern(C) public static immutable pure nothrow  safe void 
doSomething(int n)
{
}

I won't get into the `if` template guards, as those are cheating.
May 07 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 7 May 2014 at 18:51:59 UTC, Meta wrote:

 On Wednesday, 7 May 2014 at 14:40:37 UTC, Jonathan M Davis via 
 Digitalmars-d-learn wrote:

 My eyes... Oh, how that hurts readibily.


 While I agree that

 pure  safe  nogc nothrow
 void doSomething(int n)
 {
 }

 is quite ugly, it is really not much worse than

 void doSomething(int n) pure  safe  nogc nothrow
 {
 }

 I would argue that the latter hurts readability more, as 
 parsing meaning from long lines is difficult for humans. Also, 
 we can always go deeper ;-)

 extern(C) public static immutable pure nothrow  safe void 
 doSomething(int n)
 {
 }

 I won't get into the `if` template guards, as those are 
 cheating.


That `extern(C) public static immutable pure nothrow  safe` 
should be on the same line as the function declaration. The web 
interface is ruining my point =)
May 07 2014
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Wed, 07 May 2014 18:51:58 +0000
Meta via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:


 On Wednesday, 7 May 2014 at 14:40:37 UTC, Jonathan M Davis via
 Digitalmars-d-learn wrote:

 My eyes... Oh, how that hurts readibily.


 While I agree that

 pure  safe  nogc nothrow
 void doSomething(int n)
 {
 }

 is quite ugly, it is really not much worse than

 void doSomething(int n) pure  safe  nogc nothrow
 {
 }

 I would argue that the latter hurts readability more, as parsing
 meaning from long lines is difficult for humans. Also, we can
 always go deeper ;-)


Actually, I find the second version perfectly readable, and I think that it is
by far the best way for that function signature to be written, whereas I find
the first one to be much, much harder to read. But ultimately, this sort of
thing pretty much always ends up being highly subjective.

- Jonathan M Davis
May 08 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 ultimately, this sort of
 thing pretty much always ends up being highly subjective.


But please put the const/immutable of methods on the right:

struct Foo {
     void bar1() const {} // Good
     const void bar2() {} // Bad
}

Bye,
bearophile
May 08 2014
next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Thu, 08 May 2014 07:29:08 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 Jonathan M Davis:


 ultimately, this sort of
 thing pretty much always ends up being highly subjective.


 But please put the const/immutable of methods on the right:

 struct Foo {
      void bar1() const {} // Good
      const void bar2() {} // Bad
 }


Well, that's one case where there's actually an objective reason to put it on
the right due to one of the flaws in the language - that it's the one place
that const inconsistently does not apply to the type immediately to its right
(though it's consistent with how attributes are applied to the function itself
- just not consistent with variables).

It's also because of this that I favor putting most attributes on the right
(though that's subjective, unlike with const). I only put attributes on the
left if they're on the left in C++ or Java (e.g. static, public, or final).
Everything else goes on the right.

Unfortunately, making this consistent by doing something like enforcing that
all function attributes go on the right would then be inconsistent with other
languages with regards to the attributes that they have which go on the left,
so I don't know how we could have gotten it completely right. No matter which
way you go, it's inconsistent in one way or another. If it were up to me, I'd
probably enforce that all attributes which could be ambiguous go on the right
but that all others could go on either side, but Walter has never liked that
idea. So, we're stuck with arguing that everyone should put them on the right
by convention in order to avoid the ambiguity.

- Jonathan M Davis
May 08 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 Unfortunately, making this consistent by doing something like 
 enforcing that
 all function attributes go on the right would then be 
 inconsistent with other
 languages with regards to the attributes that they have which 
 go on the left,


This is a job for a Lint. like DScanner :-)

Bye,
bearophile
May 08 2014
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Thu, 08 May 2014 09:30:38 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 Jonathan M Davis:


 Unfortunately, making this consistent by doing something like
 enforcing that
 all function attributes go on the right would then be
 inconsistent with other
 languages with regards to the attributes that they have which
 go on the left,


 This is a job for a Lint. like DScanner :-)


Sure, that could point out that putting const or the left is bug-prone and
warn you that you should change it, but while it's not really possible to
have a fully consistent design with regards to function attributes, I still
think that allowing const on the left is simply a bad design decision. A
linter is then just a way to help you work around that bad design decision.

- Jonathan M Davis
May 08 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 I still think that allowing const on the left is simply a
 bad design decision.


I opened a request on this, and it was closed down :-)

Bye,
bearophile
May 08 2014
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Thu, 08 May 2014 10:27:17 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 Jonathan M Davis:


 I still think that allowing const on the left is simply a
 bad design decision.


 I opened a request on this, and it was closed down :-)


I know. Walter doesn't agree that it was a bad decision. He thinks that being
consistent with the other function attributes and letting them all be on both
sides of the function is more important, but given the fact that that's
highly error-prone for const and immutable, I definitely think that it was a
bad decision. Unfortunately, we're stuck with it, because Walter doesn't
agree, and I don't expect that anyone is going to be able to convince him.

- Jonathan M Davis
May 08 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Thu, May 08, 2014 at 01:59:58AM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:

 On Thu, 08 May 2014 07:29:08 +0000
 bearophile via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
 wrote:
 

 Jonathan M Davis:


 ultimately, this sort of thing pretty much always ends up being
 highly subjective.






FWIW, for very long function signatures I write it this way:

	const(T)[] myVeryLongFunction(T)(const(T)[] arr,
	                                 int        x,
	                                 int        y,
	                                 int        z,
	                                 ExtraArgs  extraArgs)
		pure  safe nothrow
		if (is(T : int) &&
		    someOtherLongCriteria!T &&
		    yetMoreVeryLongCriteria!T)
	{
		...
	}



 But please put the const/immutable of methods on the right:

 struct Foo {
      void bar1() const {} // Good
      const void bar2() {} // Bad
 }


 
 Well, that's one case where there's actually an objective reason to
 put it on the right due to one of the flaws in the language - that
 it's the one place that const inconsistently does not apply to the
 type immediately to its right (though it's consistent with how
 attributes are applied to the function itself - just not consistent
 with variables).


Due to this flaw, I've stopped writing "const T" completely -- now I
only ever write "const(T)". Besides, there is also the ambiguity between
const(T)[] and const(T[]), so I regard writing const without parens
(const T[]) as a bad practice in D.



 It's also because of this that I favor putting most attributes on the
 right (though that's subjective, unlike with const). I only put
 attributes on the left if they're on the left in C++ or Java (e.g.
 static, public, or final).  Everything else goes on the right.


[...]

Ditto. I think this is the closest we can come to consistency given the
current language.


T

-- 
My program has no bugs! Only undocumented features...
May 08 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:


 FWIW, for very long function signatures I write it this way:

 	const(T)[] myVeryLongFunction(T)(const(T)[] arr,
 	                                 int        x,
 	                                 int        y,
 	                                 int        z,
 	                                 ExtraArgs  extraArgs)
 		pure  safe nothrow
 		if (is(T : int) &&
 		    someOtherLongCriteria!T &&
 		    yetMoreVeryLongCriteria!T)
 	{
 		...
 	}


You also need the pre&post-conditions :-)

Bye,
bearophile
May 08 2014
parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Thu, May 08, 2014 at 02:50:54PM +0000, bearophile via Digitalmars-d-learn
wrote:

 H. S. Teoh:
 

FWIW, for very long function signatures I write it this way:

	const(T)[] myVeryLongFunction(T)(const(T)[] arr,
	                                 int        x,
	                                 int        y,
	                                 int        z,
	                                 ExtraArgs  extraArgs)
		pure  safe nothrow
		if (is(T : int) &&
		    someOtherLongCriteria!T &&
		    yetMoreVeryLongCriteria!T)
	{
		...
	}


 
 You also need the pre&post-conditions :-)


[...]

I actually had them in my first draft. :)

	const(T)[] myVeryLongFunction(T)(const(T)[] arr,
	                                 int        x,
	                                 int        y,
	                                 int        z,
	                                 ExtraArgs  extraArgs)
		pure  safe nothrow
		if (is(T : int) &&
		    someOtherLongCriteria!T &&
		    yetMoreVeryLongCriteria!T)
	in {
		assert(x >= 0 && x < 5);
		assert(y >= 0 && y < 5);
		assert(z >= 0 && z < 5);
	}
	out(result)
	{
		assert(result[0] >= 0 && result[0] < 5);
		assert(result[1] >= 1 && result[1] < 6);
		assert(result[2] >= 2 && result[2] < 7);
	}
	body
	{
		...
	}

There. :)


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel
May 08 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 8 May 2014 at 14:34:27 UTC, H. S. Teoh via 
Digitalmars-d-learn wrote:

 FWIW, for very long function signatures I write it this way:

 	const(T)[] myVeryLongFunction(T)(const(T)[] arr,
 	                                 int        x,
 	                                 int        y,
 	                                 int        z,
 	                                 ExtraArgs  extraArgs)
 		pure  safe nothrow
 		if (is(T : int) &&
 		    someOtherLongCriteria!T &&
 		    yetMoreVeryLongCriteria!T)
 	{
 		...
 	}


I like this one with only exception that I prefer to keep 
parameter list to fill the line and always match brackets:

const(T)[] myVeryLongFunction(T)(const(T)[] arr,
     int x, int y, int z, ExtraArgs  extraArgs
)
     pure  safe nothrow
     if (is(T : int) &&
         someOtherLongCriteria!T &&
         yetMoreVeryLongCriteria!T
     )
{
}

for quick overview of parameters DDOC fits better IMHO
May 08 2014
parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Thu, May 08, 2014 at 03:13:48PM +0000, Dicebot via Digitalmars-d-learn wrote:

 On Thursday, 8 May 2014 at 14:34:27 UTC, H. S. Teoh via Digitalmars-d-learn
 wrote:

FWIW, for very long function signatures I write it this way:

	const(T)[] myVeryLongFunction(T)(const(T)[] arr,
	                                 int        x,
	                                 int        y,
	                                 int        z,
	                                 ExtraArgs  extraArgs)
		pure  safe nothrow
		if (is(T : int) &&
		    someOtherLongCriteria!T &&
		    yetMoreVeryLongCriteria!T)
	{
		...
	}


 
 I like this one with only exception that I prefer to keep parameter
 list to fill the line and always match brackets:
 
 const(T)[] myVeryLongFunction(T)(const(T)[] arr,
     int x, int y, int z, ExtraArgs  extraArgs
 )
     pure  safe nothrow
     if (is(T : int) &&
         someOtherLongCriteria!T &&
         yetMoreVeryLongCriteria!T
     )
 {
 }
 
 for quick overview of parameters DDOC fits better IMHO


I find the hanging )'s rather jarring. But, it's subjective after all,
right? :)

One thing I haven't quite figured out, is what to do when there are many
of both compile-time and runtime-parameters. None of my usual formatting
techniques seem to produce a nice result; it always looks ambiguous:

	Result myFunc(alias veryLongCompileTimeArgument,
	              alias anotherVeryLongCompileTimeArgument,
	              int   compileTimeIntegerArgument)
	             (int          runtimeArg1,
	              const(int)[] runtimeArg2,
	              int          moreRuntimeArgs)
		pure  safe nothrow
	...

This is the best I can do, but I'm not very happy with it. One
alternative is:

	Result myFunc(
		alias veryLongCompileTimeArgument,
		alias anotherVeryLongCompileTimeArgument,
		int   compileTimeIntegerArgument
	)(
		int          runtimeArg1,
		const(int)[] runtimeArg2,
		int          moreRuntimeArgs
	)
		pure  safe nothrow
	in { ... }
	out(result) { ... }
	body
	{
	}

This doesn't look that great either. :-/


T

-- 
The fact that anyone still uses AOL shows that even the presence of options
doesn't stop some people from picking the pessimal one. - Mike Ellis
May 08 2014
prev sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Thu, 8 May 2014 07:32:52 -0700
"H. S. Teoh via Digitalmars-d-learn"
<digitalmars-d-learn puremagic.com> wrote:


 On Thu, May 08, 2014 at 01:59:58AM -0700, Jonathan M Davis via
 Digitalmars-d-learn wrote:

 On Thu, 08 May 2014 07:29:08 +0000
 bearophile via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:


 Jonathan M Davis:


 ultimately, this sort of thing pretty much always ends up being
 highly subjective.






 FWIW, for very long function signatures I write it this way:

   const(T)[] myVeryLongFunction(T)(const(T)[] arr,
                                    int        x,
                                    int        y,
                                    int        z,
                                    ExtraArgs  extraArgs)
       pure  safe nothrow
       if (is(T : int) &&
           someOtherLongCriteria!T &&
           yetMoreVeryLongCriteria!T)
   {
       ...
   }


That's that I do with the params, but I'd still put the attributes to the
right of the last param rather than on their own line. I don't think that I'd
_ever_ put attributes on their own line. But as always, it's all quite
subjective, and everyone seems to prefer something at least slightly
different.

- Jonathan M Davis
May 08 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Wed, May 07, 2014 at 01:25:52PM +0000, bearophile via Digitalmars-d-learn
wrote:

 So far in Rosettacode D entries I've kept a line length limit of 72 or
 73 chars.
 
 But now a little larger monitors are common, D UFCS chains are common,
 and we also have longer function signatures with "pure nothrow  safe
  nogc" (that usually I put on a new line), so keeping that line length
 limit is becoming a little pain.


I have a 1600x1200 monitor, and I still prefer a maximum of 80 chars per
line. Lines that are too long are hard to read at a glance, regardless
of how narrow/short the monitor is.

But, how you choose to format your code is really up to you. ;-)


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in
common: they don't depend on the language. -- Luca De Vitis
May 07 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/7/2014 9:25 AM, bearophile wrote:

 So far in Rosettacode D entries I've kept a line length limit of 72 or
 73 chars.

 But now a little larger monitors are common, D UFCS chains are common,
 and we also have longer function signatures with "pure nothrow  safe
  nogc" (that usually I put on a new line), so keeping that line length
 limit is becoming a little pain.

 So probably I'll increase the maximum line length. Rosettacode rules
 forbids too much long lines, and while in my code I use a limit of about
 90-100 in my code, this is too much for online wiki pages. So I'll do
 some tests, and I think for Rosettacode D entries I'll increase the
 limit to about 80 chars.

 Bye,
 bearophile


72-73 chars would indeed be a pain. In my own code I like to use a soft 
limit of 80, FWIW.

I do find I need to break up lines in D more than I would in other 
languages, especially function signatures.
May 07 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


 72-73 chars would indeed be a pain. In my own code I like to 
 use a soft limit of 80, FWIW.


This is not regular code, it's an online wiki. The situation is a 
little different. But I think 80 is now acceptable.

Bye,
bearophile
May 07 2014
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/07/2014 06:25 AM, bearophile wrote:


 limit to about 80 chars.


I've never worked at a place where the limit was not 80. So, from my 
point of view it is still the industry standard and I like it. :)

Ali
May 07 2014