Re: GNUstep Coding Standard Additions

[Sheldon Gill]

Richard Frith-Macdonald wrote:
> > Functions, though, are much more ambiguous:
> > The NeXT standard is GSFunction() pretty much everywhere.
> > The GNU standard is gnu_function().
> > Both are followed internally in different places.
>
> I try to stick to the GSFunction() style everywhere, and reserve the 
> underscore for macros.

Underscore for macros? Really?

In my view macros should be:

MACRO(x)

unless there is a very good reason otherwise.

So your recommendation is

static NSString *
BundleObjectName(NSString *path, NSString* executable)

over

static NSString *
bundle_object_name(NSString *path, NSString* executable)

in this module private case?

> > For ObjC object instances, the issue is less clear but should be 
> > "anObject" generally. What if it's a single word? "Object" or "object"?
>
> Variable names begin with a lowercase letter.

Excellent. We agree for that its "object" or "anObject" for all obj-c 
variable instances.

I think the current standard isn't clear enough on this issue and should 
be revised accordingly.

> > I think we should also be clear that "dictionary" or "dict" is 
> > preferred over "d". Except for mathematical function implementations 
> > single or double character identifiers are a bad idea.
>
> I think the rule is that variables should be clear, readable, and not 
> misleading ... so it depends a lot on context.  In general, shorter is 
> better as long as it's very obvious what the variable is ... so if a 
> variables's scope is larger (many lines), it needs to be longer and more 
> descriptive.

I disagree that in general, shorter is better. In my view, more apparent 
and descriptive is always better than terse or cryptic. Trying to work 
with legacy C code taught me that in spades.

Even when it is common parlance in a project I still think more apparent 
is better. For example, I don't think that 'arp' is better than 'anARP'. 
Rather, I'd go for 'aMemPool' or 'aMemoryPool'.

This, though, is moving from standard to style.

My focus for this post is to clarify ambiguities and establish doctrine 
where we reasonably could.

{Doesn't mean I'm not up to continuing a thread on style ;-) }

> > What about static (ie local) variables? Especially if they refer to a 
> > C type rather than an object. Consider
> >
> > static int word_count; // GNU style
> > static int wordCount;  // NeXT style
> >
> > Both methods are used internally. I feel we should standardise on the 
> > GNU style.
>
> I stick to the NeXT style .... just like functions and classes.

You preference has been noted.

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?

> > Conditional compilation
> > =======================
> >
> > In trying to accommodate differences between platforms and particular 
> > build requirements there is a lot of code which is conditionally 
> > compiled using the pre-processor.
> >
> > I recommend standarising on
> >
> > #ifdef REQ_DEF
> >
> > instead of
> >
> > #if defined(REQ_DEF)
>
> If you use defined(X) you can combine it with other checks using logical 
> operators ... which is much more powerful (and easier to read than 
> nested #ifdefs, so if yoiu have to have a standard, it should be to use 
> defined() rather than ifdef

Fair enough. Personally I quite like defined() and am happy to go with 
that as the standard.

My recommendation was based purely on the first form being 50% more used 
in -base.

> > Are there other coding standard issues which should be addressed?
>
> I hate sounding negative about this ... but I think you are already 
> wanting to go too far.

Fair enough. I'm glad you're voicing your opinion.

> 1. People should be free to code as they like as long as we keep to a 
> sufficient degree of consistency for code to be readily readable by 
> everyone (and I think the code libraries have that degree of consistency).

Well in this we differ. For code to be readily readable by everyone I'd 
say that:

  if (cond)
      {
      <body>
      }

is every bit as readable as:

  if (cond)
    {
      <body>
    }

and actually makes more sense from a logic and CS viewpoint. I'd also 
say that:

  if (cond)
  {
      <body>
  }

is also better the second example. However, in contributing to GNUstep 
I'm *not* free to make that decision. That's fine. Linux kernel 
contribution goes

  if (cond) {
      <body>
  }

but it doesn't matter either because the rules are clear.

Sorting out discrepancies and establishing rules is more important from 
a software engineering view point than a simple question of readability.

In writing code to be contributed I encountered these situations where 
the standards and guidelines weren't clear or conflicting. I had to make 
a determination. That the source chose differently in various places 
points to others going through the same process. If there was a rule in 
place that time and effort would be saved.

I also note that you have modified source to move from one 
interpretation to the other. If your view was truly "free to code as 
they like", why take the time to do this?

Plus, if you take the time to move from one way to another then surely 
someone else can come along later and move it back?  Back and forth. 
Lets decide, then move on.

> 2. I seem to agree with some of your suggestions, but disagree with just 
> as many.  I suspect other people will feel the same way (probably not 
> with the same ones).

In my view it isn't so much with agree/disagree as the level of 
sentiment behind the expression.

I'll take for example the question of tabs. So far a few people have 
said essentially "yes, get rid of all tabs now!". The other responses 
have been more luke-warm in the "I don't mind" vein.
There hasn't been anyone to stand up and champion the "tabs are good" cause.

Hence, I think we can have a "No tabs" rule and put zero noses out of joint.


Regards,
Sheldon