[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes I've been thinking of...

From: Quentin Mathé
Subject: Re: Changes I've been thinking of...
Date: Fri, 9 Oct 2009 21:51:58 +0200

Le 9 oct. 2009 à 20:48, Matt Rice a écrit :

On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero
<address@hidden> wrote:

By the way the GNU coding standards are not bad, in fact I personally like
them (mostly because
my eyesight is really bad and whitespace is much more effective at
separating tokens than
brackets or commas). There are some details I'd change, but they certainly
are not an unusual
or weird choice for a large free software project.

To me it is about separating groups of tokens, e.g. if you are going
to separate like this

[thing foo: arg1 bar: arg2];

and insist on including that space between the 'foo:arg1' group,
the whole message send looks androgynous with parts of the selectors
mixed in with their arguments...

compared with
[thing foo:arg1 bar:arg2];

it is very easy for me to pick out which args go with which parts of
the selector, and
which message is being sent...

Well it's possible to argue in the opposite way :-)
The first version is more readable than the second, because it's very easy to spot each 'colon + white space' combination. Then you know the left part is a method keyword and the right part is the argument. In the second case, 'colons' without white space seems slower to find because they are lost in the middle of other characters.

The first version is also closer to the spirit of Smalltalk, in the sense the punctuation related spacing is similar to a real sentence. imo Smalltalk code with this spacing style is clearer than Smalltalk code without a space between each method keyword and argument pair. This point is less important in Objective-C given the whole language syntax is far less clean (C syntax + brackets everywhere). But it still matters a bit I think. I agree I'm getting really subjective here :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]