[openbeos] Coding Style Guideline

  • From: Michael Lotz <mmlr@xxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sat, 09 Jul 2005 23:25:44 +0200

I was bored today and, while not wanting to work on something bigger, wanted contribute something to Haiku again. So I decided to clean up some sources / headers and to check for uninitialized variables and unneeded leftovers.

But when trying to apply "the code guideline" I noticed that there is not really one complete guideline. As I understand it the official style guideline is the one from OpenTracker, which is also linked from Haiku-OS.org (Contribute -> Coding Guidelines). I read them some times in the past and just read them again.
But I came to the conclusion that they are just not in line with the Be header style I adapted to and use since quite some time (which rather surprised me as the OpenTracker headers should be similar to the Be headers).
The very first bit of "Indendting and Whitespaces" describes a class you may have in a header (I used spaces here because of possible tab-width issues):


Guideline:

class Foo : public Bar {
    public:
        Foo(int32);
        virtual ~Foo();

        virtual void SomeFunction(SomeType *);
            // you may omit argument names if they don't help
            // documenting their purpose

        virtual const char *FunctionWithLotsOfArguments(
            const char *name, const char *path, const char *user);
            // indent long argument lists by a tab

    private:
        int32 fMember1;
        int32 fMember2;
        const char *fMember3;
};

Be:

class Foo : public Bar {

public:
                              Foo(  int32 indented_to_align_args,
                                    int32 if_wrapped_over,
                                    int32 multiple_lines);
virtual                       ~Foo();

                              Foo(BMessage *data);
static  BArchivable           *Instantiate(BMessage *data);
virtual status_t              Archive(BMessage *data, bool deep) const;

virtual void                  Pulse();
virtual void                  FrameMoved(BPoint new_position);

private:
        int32                 fMember1;
        int32                 fMember2;
        const char            *fMember3;
};


While the first one may be more "structured" I find the second one far more easy to read. The keywords like "virtual", "static", "typedef" or "friend" are on the left, then a tab, the type, then tabs to align with the rest, and then the function/variable. If there is no keyword, there are two tabs instead. The only keyword where this doesn't work out is "volatile" because it's too long. Also all the "*" or "&" stick to the variables/functions in the Be headers.


Another question the guideline leaves out is what to do with blank lines. In the headers they are usually stripped and have no indenting at all. But in the code it's different. Some leave the indent on blank lines and some remove them:

This:
{
        int32 variable = 0;
        float another = 1.0;
        <-- line starts here
        while () {
                // more code
        }
}

Vs. that:
{
        int32 variable = 0;
        float another = 1.0;
<-- line starts here
        while () {
                // more code
        }
}

I personally find the first one better, as you can just start typing and don't have to care about indenting at all, but this obviously depends on personal taste and your editor of choice. I think things like this should just be decided and written down.

So my question is: Should I try to write a complete guideline as a mix between OpenTracker and Be headers, should I use both as I like, should I just stick with one, or should I just leave the whole topic and do something else.

Applying style guides is just a very easy task you can do without the need for a BeOS machine or other developing platform. And you can look over the code to eliminate old variables/forward declarations/includes that are not needed anymore in the same run. Perfect for the time between leaving home in the morning and getting back at evening, if you know what I mean.

Thoughts?

Other related posts: