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...
On Nov 4, 6:10 pm, D Yuniskis <not.going.to...@seen.com> wrote:
> You will get as many *different* answers as respondents! :>
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 (www.ganssle.com). For example http://www.ganssle.com/fsm.pdf has a whole lot of ideas about this.
What ever you choose, keep it throughout the project.
>for example:
>MyFunction(); >myFunction();
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<<5 And in the code: mask &= ~VALUE; Guess what happened ? :-)
Global functions get a module-prefix separated by "_" Opening braces are in the line of if/while/for/do/switch, indention 2 spaces. Code should be readable, so no if(i==1||i==4) but if ( (i == 1) || (i == 4) ) Use spaces, good code should not look like prose rather like poetry.
But of course, writing code for customers forces other styles. -- 42Bastian Do not email to bastia...@yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
Op Thu, 05 Nov 2009 08:40:44 +0100 schreef <ArarghMail911NOS...@not.at.arargh.com>:
> On Thu, 05 Nov 2009 06:20:01 GMT, bastia...@yahoo.com (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 () ?
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.
> What ever you choose, keep it throughout the project.
> >for example:
> >MyFunction(); > >myFunction();
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.
> I myself prefer: .... > Opening braces are in the line of if/while/for/do/switch, indention 2 > spaces.
More importantly indent with spces the block of code by the same amount. Tabs can be different on systems/IDE/editors
> Code should be readable, so no > if(i==1||i==4) > but > if ( (i == 1) || (i == 4) )
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.
> 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.
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.
> But of course, writing code for customers forces other styles.
><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 bastia...@yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
>><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 () ?
> 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.
>> 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!
42Bastian Schick wrote: > On Wed, 4 Nov 2009 23:10:37 +0100, "Geek" <g...@gik.ze> 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! :>
In article <4692a7d1-0a5e-469f-8731-15147acefc79 @m1g2000vbi.googlegroups.com>, zwsdot...@gmail.com says...
> On Nov 4, 6:10 pm, D Yuniskis <not.going.to...@seen.com> wrote:
> > You will get as many *different* answers as respondents! :>
> 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...
I'm in near-violent agreement with you. :-D
I "saw the light" with Steve Oualline's book "C Elements of Style".
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...
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 :-)...
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://Paul_E.Benn...@topmail.co.uk> Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Before fixing on a particular style, you have to decide *why* you are doing so. Sometimes you have specific requirements (if your customer specifies MISRA, you use MISRA). And sometimes you are working on existing code, in which case fitting with the existing style is often the best choice. But mostly you or your company pick a style to make your code easy to read, easy to understand, easy to maintain, and to lower the risks of mistakes. Those are the goals to keep in mind when picking the style. You also have to take into consideration who is writing the code, and what kind of code you are writing. One style does not fit all.
Personally, I think that rigid naming patterns are unnecessary, and can often be ugly. A great many people are convinced that pre-processor macros should always be in all caps. I think that convention should have died out 25 years ago when computers got "caps lock" keys. Some people like to use Hungarian notation (stuff like "ucLength" for an unsigned char variable). I don't - it discourages use of appropriate types. The exact size of a variable should be either clear, or irrelevant, and you see it from the declaration of the variable, not from its name. But that's for /my/ programming - the style you want should suit /your/ programming.
One thing that I think is particularly important is code spacing, indenting and layout. I'm not nearly as permissive there - blocks must always be indented consistently. I also insist on braces with multi-line if's - if something takes more than one line, it's a block and should have braces and indents.
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.
> 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 :-(...
|
