rfc: indenting and coding style

[Hynek Hanke]

On 20.12.2010 01:51, William Hubbs wrote:
> I see that we still haven't decided on a coding style or run our code
> through an indenting tool.

Hello William and all,

we had written the following proposal some time ago, but
it got stuck on the new webpage which we hoped to have released
already but is still being improvedn :) The proposal is of course
open to discussion, but we need to limit discussions about
this to technical matters not matters of taste.

Coding Style Guidelines for C code (draft)
==========================

1. We use the Linux Kernel coding style
    http://kerneltrap.org/files/Jeremy/CodingStyle.txt
with the following exceptions and extensions

2. A single level of indentation is 4 spaces. Tab characters
must not be present in the code.

3. Goto statements should not be used unless in very special cases.

4. Function names should be
     a. lowercase words separated by underscores
     b. functions which are only implementation details of the given
        source file should be declared as static
     c. names of all other functions in a file should start with
        a prefix specific to that file (generally the filename
        without suffix)

5. Variable names
     a. global variables should follow the same conventions
        as functions (e.g. output_modules)
     b. the verbosity of the name of local variables should
        be appropriate to its scope

6. Macro names
     a. Macro names should be in uppercase, words separated
        by underscores (e.g. SPEECHD_OPTION_CB_STR)

7. Type names
     a. New types are defined in mixed uppercase (e.g. MessageType)

Indent parameters
-------------------------

indent -kr -i4 -nut file


Emacs environment (untested)
---------------------------

(defun speechd-c-mode ()
   "C mode with adjusted defaults for use with Speech Dispatcher."
   (interactive)
   (c-mode)
   (c-set-style "K&R")
   (setq indent-tabs-mode f)
   (setq c-basic-offset 4))


> I am willing to do the work for this if everyone is ok with it, and here
> is what My thoughts are.

That would of course be very much appreciated!

> Once we decide which style to use, we can start re-indenting the code.
> If we do it all at once, we have to wait until all of the current pending
> patches have been encorporated or sent back to the contributor.

I think we should follow this path as it is the easiest thing
to do. If in the process we find a really justified case for
an exception, we can make it.

Best regards,
Hynek