kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/3/2010 10:44 PM, Amir Mohammadkhani-Aminabadi wrote:
>  Hi guys,
> 
> to brush up my latex skills and to have a document easily versioned I took the
> opportunity to transcribe Dicks and Waynes Coding Guide to LATEX.
> 
> Please see
> http://bazaar.launchpad.net/~amir-mohammadkhani/kicad/amir_1/revision/2518
> 
> Its not perfect, but since I didn't ask for permission first I thought I'd ask
> you guys now before I polish it up.

Amir,

Your a little late to the party on this one.  The coding policy was agreed on a
well over a year ago (actually a lot further back if you look at the initial
ground work that Dick did).  It has just formally been released.  The only
polishing to it would be clarifications and formatting, spelling, and/or
grammatical errors.  That is why Dick released it as a PDF file.  It was not
intended to be edited by everyone with commit access.  You can search the
mailing list and find lots of discussion on this issue if you are interested in
how we got to this point.

> 
> Also on the matter of guidelines:
> 
> I have come to value verbose code. Too many times I have seen people (me included)
> search for bugs that could have been prevented by being more verbose in first
> place.
> 
> That is why I'd like to ask for the following changes to the guide:
> 
> * Always use braces with control statements including inside switch blocks.
> * Although its shown in the example, its not explicitly stated: always remark
> the fact
>   with a comment if there is a fall through in a switch block.
> * Always initialize variables. Assigning NULL - a simple XOR $REG, $REG will be
> scheduled
>   somewhere in between other things on any modern cpu.
> * Use of C++ comments (Stricter wording than now)

I like using the C style comment for blocks and would resist this one myself.
Doxygen comments formatted this way will are syntax highlighted in emacs.  You
are free to used C++ comments as the policy does prevent you from using them in
this manner.

> * Use C++ style variable declaration (I guess violations of this are old C
> files renamed to C++)
> 
> Also JAVADOC info on all new code would be great.

None of the examples above are excluded by the policy so there is no reason
that you could not do these things in your own code.  As for them being added
to the policy, I doubt that is likely to happen.

Wayne

> 
> cheers
> amir
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>