 |
|
| Computers Forum Index » Computer Architecture - Embedded » What coding standard are you using for C?... |
|
Page 1 of 3 Goto page 1, 2, 3 Next |
|
| Author |
Message |
| Geek... |
 Posted: Thu Nov 05, 2009 3:10 am |
|
|
|
Guest
|
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(); |
|
|
| Back to top |
|
|
|
| larwe... |
| Posted: Thu Nov 05, 2009 3:10 am |
|
|
|
Guest
|
On Nov 4, 6:10 pm, D Yuniskis <not.going.to... at (no spam) seen.com> wrote:
Quote: 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... |
|
|
| Back to top |
|
|
|
| D Yuniskis... |
| Posted: Thu Nov 05, 2009 4:10 am |
|
|
|
Guest
|
Geek wrote:
Quote: 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();
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... |
|
|
| Back to top |
|
|
|
| Rube Bumpkin... |
| Posted: Thu Nov 05, 2009 6:15 am |
|
|
|
Guest
|
Geek wrote:
Quote: 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?) 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.
RB |
|
|
| Back to top |
|
|
|
| Leo Havmøller... |
| Posted: Thu Nov 05, 2009 6:15 am |
|
|
|
Guest
|
"Geek" <gik at (no spam) gik.ze> wrote in message
news:4af1fbe1$0$275$14726298 at (no spam) news.sunsite.dk...
Quote: What coding standard are you using for C (if any)?
Like naming variables, functions, constants, globals, locals, types etc.?
Here's a few:
http://www.sourceformat.com/coding-standard.htm
Leo Havmøller. |
|
|
| Back to top |
|
|
|
| Didi... |
| Posted: Thu Nov 05, 2009 10:23 pm |
|
|
|
Guest
|
On Nov 5, 11:47 pm, Vladimir Vassilevsky <nos... at (no spam) nowhere.com> wrote:
Quote: .....
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 |
|
|
| Back to top |
|
|
|
| D Yuniskis... |
| Posted: Thu Nov 05, 2009 10:48 pm |
|
|
|
Guest
|
Uniden wrote:
Quote: 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... |
|
|
| Back to top |
|
|
|
| ChrisQ... |
| Posted: Thu Nov 05, 2009 11:02 pm |
|
|
|
Guest
|
Geek wrote:
Quote: 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 |
|
|
| Back to top |
|
|
|
| Paul E Bennett... |
| Posted: Fri Nov 06, 2009 2:03 am |
|
|
|
Guest
|
Geek wrote:
Quote: 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.Bennett at (no spam) 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..
******************************************************************** |
|
|
| Back to top |
|
|
|
| David Brown... |
| Posted: Fri Nov 06, 2009 2:29 am |
|
|
|
Guest
|
Geek wrote:
Quote: 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();
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. |
|
|
| Back to top |
|
|
|
| Vladimir Vassilevsky... |
| Posted: Fri Nov 06, 2009 2:47 am |
|
|
|
Guest
|
Geek wrote:
Quote: 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();
Just don't write assembly code in capital letters and do fill tabs with
spaces. Then you will be fine.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com |
|
|
| Back to top |
|
|
|
| Marco... |
| Posted: Fri Nov 06, 2009 8:13 pm |
|
|
|
Guest
|
On Nov 5, 9:37 am, Uniden <uni... at (no spam) nospam.net> wrote:
Quote: In article <4692a7d1-0a5e-469f-8731-15147acefc79
at (no spam) m1g2000vbi.googlegroups.com>, zwsdot... at (no spam) gmail.com says...
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 "saw the light" with Steve Oualline's book "C Elements of Style".
http://www.e-booksdirectory.com/details.php?ebook=1602
Quote: When I read that I learned that writing code is much more than just
hacking out code that only works. Quality comes from communication.
Other books you could ponder: C Style - David Straker and C++ Coding
Standards - Sutter.
good naming convention except that module static and function local
variables don't need the prefix ( the prefix provides a namespace
solution for C code) - the listed books are good and some of those are
available online by their author or web published coding standards
reference them |
|
|
| Back to top |
|
|
|
| Andrew Smallshaw... |
| Posted: Fri Nov 06, 2009 11:00 pm |
|
|
|
Guest
|
On 2009-11-05, Paul Carpenter <paul at (no spam) pcserviceselectronics.co.uk> wrote:
Quote:
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.
I keep getting criticism for ignoring an imagined 80 column limit.
Yes, I'll keep it under 132 columns but not 80 - it just gets too
restrictive and demands either less indentation of cyptically short
variable names which are a much bigger problem. 132 (sometimes
136) is of course how long a line can be printed on a wide carriage
printer, so it is largely historical now, although is does approximate
what enscript -r can fit on a sheet of A4 with default settings.
With modern text editors under GUIs you are typically not limited
to anythign like 80 column views so I see no practical reason to
stick to such a narrow limit.
--
Andrew Smallshaw
andrews at (no spam) sdf.lonestar.org |
|
|
| Back to top |
|
|
|
| Paul Carpenter... |
| Posted: Sat Nov 07, 2009 5:37 am |
|
|
|
Guest
|
In article <slrnhf9ajs.4uj.andrews at (no spam) sdf.lonestar.org>,
andrews at (no spam) sdf.lonestar.org says...
Quote: On 2009-11-05, Paul Carpenter <paul at (no spam) pcserviceselectronics.co.uk> wrote:
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.
I keep getting criticism for ignoring an imagined 80 column limit.
Yes, I'll keep it under 132 columns but not 80 - it just gets too
restrictive and demands either less indentation of cyptically short
variable names which are a much bigger problem.
Can do, but excessive indentation levels is often an example over
complexity and the need for restructuring or extra function(s).
Quote: 132 (sometimes
136) is of course how long a line can be printed on a wide carriage
printer, so it is largely historical now, although is does approximate
What a Landscape mode print can do.
Quote: what enscript -r can fit on a sheet of A4 with default settings.
Never assume anything other than a simple text file print is possible
relying on specific software or printers, is the standard assumption
that you will be the only person ever wanting to print out any part.
Just like 'lock-in' IDE's that use encrypted project files.
Some types of work will require printouts, as paper is still a VERY
good archive method as it can be read for many more years, than most
media. How many systems still have 3.5" floppy drives?
Quote: With modern text editors under GUIs you are typically not limited
to anythign like 80 column views so I see no practical reason to
stick to such a narrow limit.
Hopefully you are dealing with standard text files, as paper
printout can be read where even some text files using strange
character encodings can be a pain.
Can you guarantee that any software written will only need to be
supported for about two years after release? That is about the
average timespan before some change means it can be difficult
to read some files due to things like
OS change
Tools version change
Tools (including editor change)
Media no longer available
printers or other changes (wide carriage no longer available)
Vanishingly few people actually go through their archive of projects
and all current releases to ensure that all files can be read/edited
and rebuilt, when they have one of the above changes. Generally it
suddenly becomes a problem because someone has to examine some
old code.
Coding standards are about maintainability as well as current
tasks.
--
Paul Carpenter | paul at (no spam) pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate |
|
|
| Back to top |
|
|
|
| Jon Kirwan... |
| Posted: Sat Nov 07, 2009 6:06 am |
|
|
|
Guest
|
On Fri, 6 Nov 2009 23:00:15 +0000 (UTC), Andrew Smallshaw
<andrews at (no spam) sdf.lonestar.org> wrote:
Quote: On 2009-11-05, Paul Carpenter <paul at (no spam) pcserviceselectronics.co.uk> wrote:
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.
I keep getting criticism for ignoring an imagined 80 column limit.
Yes, I'll keep it under 132 columns but not 80 - it just gets too
restrictive and demands either less indentation of cyptically short
variable names which are a much bigger problem. 132 (sometimes
136) is of course how long a line can be printed on a wide carriage
printer, so it is largely historical now, although is does approximate
what enscript -r can fit on a sheet of A4 with default settings.
With modern text editors under GUIs you are typically not limited
to anythign like 80 column views so I see no practical reason to
stick to such a narrow limit.
I stay with a strict 79 column limit. It turns out that I also print
my listings on the laser printer in portrait mode and that with the
use of commonly available fixed-pitch fonts like Courier or Prestige
Elite I get just about the right font size for readability, as well.
I couldn't possibly consider 132 columns as acceptable anymore. I
still have the boxes of printer paper designed for that, but long
since lost printers with the sprockets to feed the paper. Use it for
scratch paper, now. And printing landscape, while acceptably printing
at 132 columns fixed-pitch, puts too few lines on the page. Readable
code requires that the basic idea is presented (as well as possible)
on a single page (or perhaps two.) The few lines that I wind up
wrapping do NOT add anywhere near enough extra vertical lines to cause
a problem. While printing landscape would lose way too many lines and
would definitely become a readability problem for me.
I guess different people come to different, strongly held conclusions.
Jon |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Fri Nov 27, 2009 8:21 pm
|
|