discuss-gnustep
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep Coding Standard Additions

From: Richard Frith-Macdonald
Subject: Re: GNUstep Coding Standard Additions
Date: Sun, 01 May 2005 06:27:47 +0100 
On 2005-04-30 08:04:57 +0100 Sheldon Gill <sheldon@westnet.net.au> wrote:


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.
I would use MACRO(X) or MULTI_WORD_MACRO(X) ... purely because macros are entirely uppercase, which means you can't use capitalization of the initial letters of words to make them more readable. 


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?
Actually, my recommendation is to not force people to a single style when contributing. However, our standard style would be without underscores (ie the one used generally because it *has* to be used for the public api). I think function names usually have a lowercase initial letter if they don't have the NS or GS prefix though.
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.
My point was/is that, very often shorter == more apparent and longer/more-descriptive is less apparent/readable ... it varies with circumstances ... so I think it's not an area that can be reasonably ruled upon. The aim is to make things clear/readable. I'm not advocating terse and cryptic any more than you are advocating verbose and obfuscated.
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.
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>
    }
Fundamentally yes, but people get used to particular styles and then find the alternatives unclear. There are also cases (mostly misuse of spaces) which I consider fundamentally difficult to read, 
and others apparently do not, so perhaps tghey are habit too...

if( cond ){
  <body>}
Sorting out discrepancies and establishing rules is more important from a software engineering view point than a simple question of readability.
The two are inseparable imo. Readability is a major factor in determining rules.
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?
I don't know about individual instances ... but generally when reviewing patches I modify them to conform to our standards, and I guess I also modify to conform to our general practices (eg names are NeXT style almost everywhere, even if we don't formally say so in the standards). It doesn't really 'take time' to do it ... as it's somethig I can do pretty automatically, while thinking about the code to understand what it's doing.
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.
Probably ... I just worry about alienating possible contributors ... we need all the new people we can get. I think someone else in this thread suggested 'guidelines' rather than 'standards'. Basically, I think of 'standards' as the minimal set of rules to be fairly sure that as contributed patch can be applied then read/understood reasonably efficiently (if a patch does not meet these standards, then trying to review it might be more trouble than the patch is worth), wheras 'guidelines' might tell peopole how we would like things in an ideal world.
reply via email to
[Prev in Thread] Current Thread [Next in Thread]