What coding standard are you using for C?

You will get as many *different* answers as respondents! :>

Find one that *you* are comfortable with and be consistent within that.

Things you might consider: MaxValue vs. ValueMax -- the latter sorts better with names like ValueMin (contrast this with MinValue) Adding underbars improves readability but lengthens identifiers. If you adopt a naming convention that embeds the type of an object in the name of the object (e.g., "Hungarian" notation), then you have to change the name of the object if you end up changing its type. Globals are evil. :> You might also find limits on globals are different (number of characters, etc.) Decide if you want to be verbose or cryptic with your names. E.g., char *p vs. char *ptr vs. char *pointer...

Why so few? Anyone here who works on code of different vintages or for different platforms is probably working with at least three or four different styles/standards at once.

My own style (where I am free to choose it) is heavily influenced by having written code for OS/2 - I prefix all functions and variables with an abbreviation indicating the module in which they reside, for example...

Jack Ganssle has written quite a bit on this in Embedded Systems Design (Is that their current name?) magazine, his weekly newsletter, and has info on his website

RB

Here's a few:

Leo Havmøller.

What ever you choose, keep it throughout the project.

I myself prefer: Camel-style starting with lower letter, no type-information in symbols (i.e. no int *ip_a;). Types appended with _t, structs with _s and classes with _c. Classes start with an upper letter. Pre-processor macros all upper-case and the values always surrounded by brackets. E.g.: #define VALUE (1) (I just debugged customer code, who did not do this: #define VALUE 1

I always thought brackets were [] not () ?

Op Thu, 05 Nov 2009 08:40:44 +0100 schreef :

Yes and no. There are four main types of brackets:

- round brackets, open brackets or parentheses: ( )

- square brackets, closed brackets or box brackets: [ ]

- curly brackets, squiggly brackets, swirly brackets, braces: { }

- angle brackets, diamond brackets, cone brackets, wickets, chevrons: < > or ? ?

Choice of fonts printed can have a bearing avoid the ONE and L confusions, let alone the zero and letter o confusions. There are others.

My personal preference on that would be how the parntheses are done always put a space between, even for empty list. Avoids problems with some fonts the parentheses being confused as a letter eg 0.

....

More importantly indent with spces the block of code by the same amount. Tabs can be different on systems/IDE/editors

My personal method is ensure the opening parentheses for functions, language construct ( if, while.. ) are by the name. All others spaced out, so in a complex if( .... ), it becomes easier to spot at a glance what is a function and what is a variable.

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.

Look up 'obfuscated C' for examples of how not to do things, one year they had code that compiled correctly but printed out you could see the code made a picture.

Confusing. I call them (in the order above) parentheses, brackets, braces, and angle brackets OR less & greater.

And there is always « » (174 & 175) which I don't call much of anything. :-)

They are still, I was wrong.

It appears that it depends where you live.

--------------------------------------- This message was sent using the comp.arch.embedded web interface on

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!

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! :>

I'm in near-violent agreement with you. :-D

I "saw the light" with Steve Oualline's book "C Elements of Style".=20

When I read that I learned that writing code is much more than just=20 hacking out code that only works. Quality comes from communication.

Other books you could ponder: C Style - David Straker and C++ Coding=20 Standards - Sutter.

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 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.)

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...

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

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. ;>