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

[Matt Rice]

On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero
<address@hidden> wrote:
>>
>>>> Additionally I really dislike the coding style, not because it's not
>>>> mine, but because it fails to make the code more readable. On the
>>>> other hand, there was code by Fred which looked really ok, so maybe
>>>> it's just about using the coding style in a sane way.... All I
>>>> wanted to say is, that it's not that easy to start hacking inside
>>>> the GNUstep core libraries.
>>>
>>> Completely agree.  Good coding conventions are picked because they
>>> make things that are wrong look wrong or generate compiler errors /
>>> warnings.  The GNU coding conventions were picked by selecting at
>>> random various bits from all existing coding conventions in the hope
>>> that that would make everyone happy.  They are a horrible mash of
>>> things.  The indenting style is horrible, for example, and only works
>>> if you have your editor set up in exactly the same way as RMS;
>>> mixing  tabs and spaces for indenting is one of the most stupid ideas
>>> I've  ever seen.  The convention of putting a space after function
>>> names and  before the open bracket makes code harder to read because
>>> it makes it  difficult to tell without reading the context that
>>> something is an  argument list rather than a subexpression.  In fact,
>>> almost everything  about the GNU coding conventions looks painfully
>>> stupid to anyone with  a basic understanding of how the human visual
>>> system works, but as an  official GNU project we are stuck with it.
>>
>> I didn't know you have to stick to the GNU coding guidelines if you are
>> an official GNU project. Now I understand all the people complaining
>> about gcc being unreadable...
>
> Just to clarify for the non-developers, GCC being unreadable is a completely
> different problem,
> not particularly due to the coding style. ;-)
>
> Having a standard coding style for the whole GNUstep project is really
> important as it makes
> it easier to copy/move code from one part of the project to the other.
>  Using a "standard" coding
> style that is documented and used by many other projects is also good as
> contributors will
> be immediately familiar with it.
>
> The GNU coding standards are used by a large number of projects with a lot
> of contributors
> and popularity so can't really be blamed if GNUstep is less popular than,
> say, GIMP (which also
> happens to follow the GNU coding standards) or any of the other million
> projects that use the
> GNU coding standards or some variants of them.
>
> While I sympathize with David who prefers (or is used) to some other coding
> style,
> the GNUstep project needs a consistent coding style and the GNU coding
> standard
> are as good a choice as any.  Since GNUstep is a GNU project, it's a natural
> choice.
>
> 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...

> If it's a burning issue for many developers, I guess changing the coding
> style to something else
> could be discussed.  There would be *lots* of reformatting to do if we ever
> reach an agreement
> on some other coding style. ;-)

consider me on fire then, the reformatting is no issue for me, since I
generally reformat the code i'm looking at anyways
then I fix whatever i'm doing, and to send a patch to GNUstep do a
clean checkout then uglify my code to fit the GNUstep style...

I did a quick google code search on some random method
and counted up how the arguments were formatted

92: with space between colon and argument
265: without space between colon and argument

not really a scientific study of developer preference... (considering
some of my code showed up in the with-space list which i can't stand),
there is also bound to be duplicates of code between different
versions of the same software...

so if you're going to insist on one true whitespace,
don't insist on one only a minority of developers use,
or people are bound to complain, and call the gnustep code ugly.

so just in case i haven't made my stance on the subject clear, I'd
have to Ditto what icicle and David are saying.