discuss-gnustep
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]