[Courses] Style (was Lesson Three: Basic Declarations&Expressions)

[Jenn Vesperman]

On Mon, 2002-10-14 at 22:49, Julie wrote:

> "Style" is more than just whitespace or bracket position.  I'd say
> it is a collection of things which convey information about the
> structure and organization of a program and the nature of it's
> components. 

> Yet style can also (and often does) include information about the
> variables in a program

> Style also includes the way comments are added, how much comment
> text, how it is formated, etc.; how functions (and macros!) are
> named, defined and implemented (ex: return values, capitalization,
> parameter declarations); how typedefs are used and defined (ex:
> use of a trailing "_t" to indicate a typedef being a common
> convention); the use of header files, how named and where located
> and a bazillion other things.

Some aspects of style do need to be common (or at least reasonably
closely related) over a shared project, yes.

Some don't.

I believe that the aspects which can be easily changed by a machine
(where the braces are, indentation levels) shouldn't be strictly
enforced in a project.

Some of the other aspects matter a great deal. If the convention in your
project is that CONSTANTS are ALL CAPS, variables are all lower-case and
Functions are Capitalised, then do that. If all pointers_p have a
trailing _p, do that. 

If all functions must return a success/fail code and nothing else, DO
IT. The other programmers are counting on it, and probably surrounding
your functions with 'if (!function()) then error("foo")' code.

And I feel very, very strongly about adequate commenting. :)


But I don't like being in a project where someone wants me to count
spaces and tries to tell me to always use a blah-character indentation
and put my braces in a specific way. :(



Jenn V.
-- 
    "Do you ever wonder if there's a whole section of geek culture 
        	you miss out on by being a geek?" - Dancer.

jenn at anthill.echidna.id.au     http://anthill.echidna.id.au/~jenn/