Re: GNUstep Coding Standard Additions

[Nicola Pero]

> Fine. We're mostly agreed. I'm just really against single letter 
> identifiers for the non-mathematical case. Always. That was really the 
> point that I was making, even if I wasn't so clear about it.

Single letter identifiers can make sense for the non-mathematical case.

I think on this there is no agreement and different developers have
different tastes / habits.  I don't see why we should force developers to
follow one way of coding if there is no agreement. ;-)


 
> >> As I said, both are used internally and I think that situation is bad. 
> >> Thus, we should pick the "one true style" for this as part of the canon.
> >>
> >> Can we agree that *one* method is better than two?
> > 
> > Yes ... but I don't think it's sufficiently better that one should be 
> > insisted upon when people contribute.  I think that the NeXT style is 
> > overwhelmingly more common, so I prefer it, and it's no real trouble to 
> > convert gnu-style function names to NeXT style ones.
> 
> Ahah!
> 
> Take a look at what you wrote. I take it that you're saying that the 
> NeXT style is the standard and gnu_style_function names should be 
> changed to comply. Isn't that so?

Well you seem to ignore why we have this mixture of different styles.

The OpenStep API uses a certain style (like NSDrawRect).  The GNU 
Objective-C runtime API though uses a different style (like objc_free).  

We are in the middle between the two. ;-)

Moreover, we are supposed to be following the GNU Coding Standards, which
require GNU C style to be used for all C code (it doesn't talk about ObjC
code though).

Eg, think of public stuff we add: if we're adding something which looks
like an ObjC runtime extension, it becomes natural to use the GNU ObjC
style; if we're adding something that looks like an OpenStep extension it
becomes natural to use the OpenStep style.

Internal implementation details are a bit in the middle of those two
cases.  If you're doing mostly C stuff, it becomes natural to use GNU C
style conventions; if you're doing mostly ObjC stuff, it becomes natural
to use OpenStep ObjC conventions.

An idea is using OpenStep ObjC conventions for all ObjC
class/method/protocol/object names and for public functions meant to be
extensions of OpenStep (except when it has to do with the runtime), and
GNU C/ObjC conventions for all function/C variables.  I believe in the
mind of some developers this is what we are already doing ;-)

Anyway, the essential point is that there is a reason why we have two
styles in use, and you can't ignore it ...