[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep Coding Standard Additions
From: |
Riccardo |
Subject: |
Re: GNUstep Coding Standard Additions |
Date: |
Mon, 25 Apr 2005 14:35:52 +0200 |
Hello,
On Sunday, April 24, 2005, at 06:49 AM, Sheldon Gill wrote:
There are some things which don't seem clear from the coding standards.
there always are,
The NeXT standard is GSFunction() pretty much everywhere.
The GNU standard is gnu_function().
Both are followed internally in different places.
I would follow the NeXT style almost everywhere. For consistency.
By the way, when I first turned to objective-C I was essentially pleased
that my own informal coding standard was so close to it. SO maybe I am
biased.
For ObjC object instances, the issue is less clear but should be
"anObject" generally. What if it's a single word? "Object" or "object"?
I'd use object. It is an instance, instances start smallcaps.
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.
why? I'd use NeXT style. It is internal, so let's use our style!
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)
We should also prefer positive conditional tests over negative ones.
Hence
#ifdef REQDEF
{block A}
#else
{block B}
#endif
is preferred over
#ifndef REQDEF
{block B}
#else
{block A}
#endif
I would say the preferred method would be that the first clause should
be what is thought "standard" or "default". In case of doubt though,
positive is recommended.
In cases where the conditional block is reasonably large there must be
comments at the appropriate points:
#ifdef REQDEF
{block A}
#else
{block B}
#endif /* REQDEF */
I would always put this if it is more than a couple of lines. Putting it
since the beginning makes sure that even after further coding which
might involve adding more lines, the end is clearly marked.
Tabs vs Spaces
==============
Its an age old debate but my experience is that tabs confuse things
more than they are worth. Many programmer editors today support using
the tab key to insert spaces rather than a tab character. They also
support block indent/unindent.
GNUstep uses the GNU 2/4 character indenting convention which doesn't
match the use of 8 character indents most of the time.
So IMHO using tabs isn't particularly convenient. Use of tabs can also
confuse searches and diffs.
Hence, I move that use of tabs be dropped. All in favour?
I don't know what openstep did. Unfortunately many editors, like the
all-time favourite VIM and VI, tend to be tabs-friendly making a mess.
Nedit can be taught very conveniently to behave both ways very woell.
Apple's code-editor inside IB has both options and comes in default with
4 spaces and I find it very reasonable, but I really wonder what NeXT,
OpenStep and Apple (objc/cocoa) standards are and if they chnaged.
-R
- GNUstep Coding Standard Additions, Sheldon Gill, 2005/04/24
- Re: GNUstep Coding Standard Additions, Benhur Stein, 2005/04/24
- Re: GNUstep Coding Standard Additions, Adrian Robert, 2005/04/24
- Re: GNUstep Coding Standard Additions, Adrian Robert, 2005/04/24
- Re: GNUstep Coding Standard Additions,
Riccardo <=
- Re: GNUstep Coding Standard Additions, Adam Fedor, 2005/04/27
- Re: GNUstep Coding Standard Additions, Richard Frith-Macdonald, 2005/04/28
- Re: GNUstep Coding Standard Additions, Gregory John Casamento, 2005/04/28
- Re: GNUstep Coding Standard Additions, Nicola Pero, 2005/04/28
- Re: GNUstep Coding Standard Additions, Richard Frith-Macdonald, 2005/04/28