bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnubg] Coding Styles - Indentation / Tabs / Spaces


From: Michael Petch
Subject: [Bug-gnubg] Coding Styles - Indentation / Tabs / Spaces
Date: Fri, 26 Oct 2012 16:14:36 -0600
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

Howdy All,

Having worked on a fair number of modules from a number of different
authors I feel like I sometimes I am banging my head on a wall looking
at code that doesn't show up in a code development editor very well.

I generally use emacs, vim, codeblocks, and if desperate nano, or nedit.
Usually one can set the tab width to an alternate size (our code happens
to use 2,4 and 8). Unfortunately in some modules the indentations may be
2 in some places, 4 in others etc (within the same file). Sometimes
spaces and tabs are mixed on the same line. This makes reading some
modules more tedious, and editing painful. Often I'll use Codeblocks
source formatting feature to realign the code (it uses astyle as a
backend) just to make it more readable.

Up until now I never saved back reformatted source to revision control,
but I am seriously considering it for each module I have to review.

Indentation and spacing is my primary concern. I actually have a
personal preference for K&R style formatting, although I have been known
to use the BSD/KNF(and Linux) style as well. The one style I don't
really like is the GNU style! K&R generally uses tab widths of 4 for
indentation. Linux kernel style is 8.

K&R style generally looks like this:

int main(int argc, char *argv[])
{
    ...
    while (x == y) {
        something();
        somethingelse();

        if (some_error) {
            /* the curly braces around this code block can be omitted */
            do_correct();
        } else
            continue_as_usual();
    }

    finalthing();
    ...
}

I prefer the curly braces on the same line as a statement because I
encountered a scenario in GNUBG code one time that looked similar to

        if (a)
                functionb(a)
        {
                ...
        }
        
        when in fact this was meant:

        if (a)
        {
                functionb(a)
                ...
        }

Putting the curly braces on the line with a C statement seems to help
avoid that.

I'm not interested in forcing my particular style on anyone, but I think
reformatting some of our source could make maintenance a tad bit easier
and the code a bit more readable.

If one has indent on their system, I often find myself using it to reformat:

indent -kr -l120 -fc1 -sc

kr is K&R style, The l120 sets the right margin at about 120 characters.
We do have some lengthy functions with deep indentation. That is likely
more indicative of a coding style issue than a formatting one. -fc1 and
-sc tries to fix up comments a bit more to my liking (and common in the
code).

Multi-line comments would end up something like:

/* line1
 * line2
 * line3
 * ..
 */

The comments would have an asterisk on each line in column 2 from the
indentation point. This style is heavily used in the headers of our
files, and I am comfortable with it.

My questions are.
How do people feel about reformatting the code?
What style is preferred?
Should we consider reformatting all the code at once or module by module
as we work on them?

If we do source reformatting I'd suggest if we take a file out, we do
the source formatting first, commit it back into revision control, and
then make code modifications. It makes trying to find code fixes easier
if one doesn't have to deal with all the reformatting changes in a diff,
and in my opinion would be less error prone.

Thanks,
-- 
Michael Petch
CApp::Sysware Consulting Ltd.
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304




reply via email to

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