What coding standard are you using for C?

On Thu, 05 Nov 2009 01:40:44 -0600,
wrote:

>On Thu, 05 Nov 2009 06:20:01 GMT, (42Bastian
>Schick) wrote:
>
><snip>
>>Pre-processor macros all upper-case and the values always surrounded
>>by brackets.
>>E.g.:
>>#define VALUE (1)
>I always thought brackets were [] not () ?

They are still, I was wrong.

--
42Bastian
Do not email to , it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

On Thu, 05 Nov 2009 09:13:26 -0600, Tim Wescott <>
wrote:

>On Wed, 04 Nov 2009 20:35:11 -0500, Rube Bumpkin wrote:
>
>> Geek wrote:
>>> What coding standard are you using for C (if any)?
>>>
>>> Like naming variables, functions, constants, globals, locals, types
>>> etc.?
>>>
>>> for example:
>>>
>>> MyFunction();
>>> myFunction();
>>> My_Function()
>>> my_function()
>>>
>>> UART_read()
>>> UartRead()
>>> UARTRead();
>>>
>>>
>>>
>> Jack Ganssle has written quite a bit on this in Embedded Systems Design
>> (Is that their current name?)
>
>Yes. They changed their name from one that made you think you could read
>minds to one that made you worry about sparks destroying what you were
>working on.
>
>Dunno why...

IIRC, back when they were still Embedded Systems Programming, a rival
magazine started up with the title Embedded Systems Design. This was,
oh, a decade or so ago? Perhaps a bit less.

Anyway, the old ...Design faded out after a while. It was never quite as
beefy as ...Programming and there was always the confusion with the
phone calls "Would you like a free subscription to Embedded Systems
Design?" "Er, I already have one." "No, no, not that one, we're the
other one." "Oh. Ooookay..."

After the original ESD left the scene (or were bought out?), I'd guess
that ESP decided that "Programming" sounded too limiting and didn't
encompass all the other aspects and so ... voila!

--
Rich Webb Norfolk, VA

42Bastian Schick wrote:
> On Wed, 4 Nov 2009 23:10:37 +0100, "Geek" <> wrote:
>
>> What coding standard are you using for C (if any)?
>>
>> Like naming variables, functions, constants, globals, locals, types etc.?
>
> What ever you choose, keep it throughout the project.

If you can *impose* your standard on others, you'll need
a tool to verify compliance "mechanically". If you *can't*
impose your standard on others, you are best to confer with
them beforehand and try to come to some concensus as to
what you will *all* agree to adopt.

Whatever you do, don't sweat the "appearance" details
(which seems to be the basis of most holy ways on the subject).
Agree on naming conventions, standards for commentary,
how aggressive/pedantic you want run-time checks to be,
etc. and let some tool (e.g., indent) handle the formatting
of the code for you -- everyone can view it however they
like, mainatin it and, when next checked out of the
repository, it gets redressed to suit the style preferences of
its latest beholder! :>

Paul Carpenter wrote:
>> Use spaces, good code should not look like prose rather like poetry.
>
> Despite C, being free format, avoid too much free format, remembering
> that at some time it may well be printed, 300 character lines wrap
> very interestingly, if they wrap. Choosing indentation matching
> can make following the code easier, even if you have managed
> to get the function to fit on one page.

There is also a style issue about the language constructs that
you use as idioms, of a sort. This can affect indents in subtle
ways (being the type that uses verbose identifiers, each level
of indentation has a big impact on the length of identifier
that can be employed without ending up with a "too long" line).

For example, I like to use bogus do-while's to encapsulate
sections of code that I can *break* out of (continue can be
a friend as well) instead of lots of nested conditionals
or <gasp> a "goto". But, each costs me a level of indent. :<

Comment styles can also waste a lot of maintenance effort.
E.g., using comments "alongside" lines of code ends up
lengthening the line of text *and*, when the code snippet
gets "wider", the comment gets pushed further into the
margin requiring a rewrite to "make it fit, again".
So, write comments *above*/below code fragments instead
of alongside (unless they are very short or you are
commenting table entries, argument list in function prototypes,
etc.)

Uniden wrote:
> I "saw the light" with Steve Oualline's book "C Elements of Style".
>
> When I read that I learned that writing code is much more than just
> hacking out code that only works. Quality comes from communication.

I think the *biggest* advantage of a "coding standard" comes
from consistency. If someone "following you" (i.e. in the
maintenance process) can learn to *recognize* what you are
doing just by the way you are doing it (choices of identifiers,
programming constructs used, etc.) then their chance of
accurately understanding the intent and mechanism is
greatly increased.

E.g., if you look through my code and see lots of while loops
and then "suddenly" see a do-while, it gives you reason to
pause -- "why has he opted to abandon his established 'style'
in this instance?".

OTOH, if you never do the same thing the same way, the reader
is always "starting from zero" each time he encounters a new
stanza in your code...

Geek wrote:
> What coding standard are you using for C (if any)?
>
> Like naming variables, functions, constants, globals, locals, types etc.?
>
> for example:
>
> MyFunction();
> myFunction();
> My_Function()
> my_function()
>
> UART_read()
> UartRead()
> UARTRead();
>
>

The first thing is to find a good 132 column editor with rectangular cut
and paste and with tabs set to 4 or so spaces. I know that sounds a bit
oblique, but you need to be able to keep a view of the big picture at
all times and weedy ide or even 80 col editors can make this hard work.
How often are the comments and code all over the place in indent terms,
because some team members use tab stops and others use spaces ?. 132 col
editor also means you can indent all comments to the left of the line of
code that it relates to and not jumbled up at odd places in the code,
making it unreadable. I spend most coding time in front of an editor, so
it's arguably the most important tool in the box.

Style can be a very contentious issue and everyone develops their own
over the years, where this is not imposed. I use a modified hungarian
notation for all prototypes and variables, with no single letter vars.
Meaningfull names in all cases and a mixture of upper and lower case to
delimit. I nearly always need to know the size of a variable and doing
that is a prompt to think about the required range. Also, the first few
chars to indicate module. Type defines and defines are all upper case. I
use the misra guidelines in terms of a reliable subset of C to use. I
don't agree with or adhere to everything in it, but it seems like an
honest attempt to bring some order to the chaos. Oh yes, opening and
closing braces for all conditional expressions, even where there is only
a single following line of code. For me, making it look neat and tidy
improves clarity and results in better code because of the slower pace.
It's an intrinsic part of the process that often results incode that
works first time. Finally, module scope shared vars, fine, but declared
static. Strict rule otherwise of no globals at all other than for ro
const data, which is often defined in a separate module anyway.

There's more, but have probably said enough already to get well flamed,
so will stop now :-)...

Regards,

Chris

Geek wrote:

> What coding standard are you using for C (if any)?
>
[%X]

Whatever standard you end up following or imposing be consistent. I would
say you should have a whole series of standards within your company for
document layout, use of common identities, as well as software coding
standards. Use plenty of technical reviews throughout the development
process and enforce all your standards. Also, be aware of the dangers of
some constructs. MISRA-C guidelines are useful if you need to do dependable
development.

Alternatively you could also look at your language choices. ;>

--
************************************************** ******************
Paul E. Bennett...............<email://>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
************************************************** ******************

On Nov 5, 11:47*pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> .....
>
> Just don't write assembly code in capital letters and do fill tabs with
> spaces. Then you will be fine.

ROFL, Vladimir, that was good.

Dimiter

On Nov 5, 6:02*pm, ChrisQ <m...@devnull.com> wrote:
<snip>
> The first thing is to find a good 132 column editor with rectangular cut
> and paste and with tabs set to 4 or so spaces. I know that sounds a bit
> oblique, but you need to be able to keep a view of the big picture at
> all times and weedy ide or even 80 col editors can make this hard work.
> How often are the comments and code all over the place in indent terms,
> because some team members use tab stops and others use spaces ?.

They are all over the place because people insist on redefining the
TAB character, supported by misguided editors. TAB stops are every 8
characters. Indent by 4 or 2 spaces, or whatever you want, but TABs
are equivalent to 8 spaces.

<snip>
> There's more, but have probably said enough already to get well flamed,
> so will stop now :-)...
>
> Regards,
>
> Chris

s0lstice wrote:

>
> They are all over the place because people insist on redefining the
> TAB character, supported by misguided editors. TAB stops are every 8
> characters. Indent by 4 or 2 spaces, or whatever you want, but TABs
> are equivalent to 8 spaces.
>

Guilty as charged, but because I use the tab key for indenting. I know
you can can get auto indent from the editor, but prefer not to use it.
Spaces for tabs is much more the lowest common denominator and comes out
looking the same whatever editor it's loaded into and also when printing.

Even trying to get agreement on something as simple as that can be an
uphill struggle, which is why i'm moving over to the idea that an
enforced set of coding standards, perhaps agreed by the team, is the
least hassle way to develop. I don't think it needs to be too rigid, but
a common framework is beneficial. Once you get over the initial afront
about the fact you can't do it all your own way, you find that it works
quite well.

Above all, peer group review is the way to kick out all the clunky ideas
and poor standards, but many companies only pay lip service to the idea.
Takes up far too much time :-(...

Regards,

Chris