What coding standard are you using for C?

Vladimir Vassilevsky 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();
>
> 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
>
Unless the stupid assembler requires tabs...



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4579 (20091106) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Geek wrote:
> What coding standard are you using for C (if any)?
>

<SNIP>

No matter which standard you choose add the following to the end:

"All C/C++ code must be linted prior to release!"

If that doesn't mean anything to you, look up PC-Lint on Google.

Write no code without it.

--
Scott
Validated Software
Lafayette, CO



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4579 (20091106) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

On Nov 5, 9:37*am, Uniden <uni...@nospam.net> wrote:
> In article <4692a7d1-0a5e-469f-8731-15147acefc79
> @m1g2000vbi.googlegroups.com>, zwsdot...@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

> 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

On 2009-11-05, Paul Carpenter <> 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.

--
Andrew Smallshaw

In article <>,
says...
> On 2009-11-05, Paul Carpenter <> 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).

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

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

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

On Fri, 6 Nov 2009 23:00:15 +0000 (UTC), Andrew Smallshaw
<> wrote:

>On 2009-11-05, Paul Carpenter <> 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

Jon Kirwan wrote:
> On Fri, 6 Nov 2009 23:00:15 +0000 (UTC), Andrew Smallshaw
> <> wrote:
>
>> On 2009-11-05, Paul Carpenter <> 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

Its pointless to print out code today due to lack
of tractor feed printers. What happened to them?
To me, a stack of non-contiguous
sheets has very little value.

Andrew Smallshaw wrote:

> On 2009-11-05, Paul Carpenter <> 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.
>

You would hate working to my standard then.

* There is a 64 character limit to the width
* There is a limit on how deep a structure can be
* There is a request that each sub-routine is kept within
16 lines but absolutely no longer than one page.
* It is also demanded that each subroutine has a description
of its function, the required input parameters and what the
expected output parameters.

Less important is the indent style but I do like a very clear layout that
highlights the structural integrity of the subroutines.

* Clear phrasing is expected.

Then, I code in Forth and by adopting my standard I am assured that I can
easily work through reviews and tests easily to fully certify the codes
correctness.

--
************************************************** ******************
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 7, 3:47*am, Paul E Bennett <Paul_E.Benn...@topmail.co.uk>
wrote:

> * * There is a 64 character limit to the width

(etc)

> Then, I code in Forth and by adopting my standard I am assured that I can

Your rules might be the bee's knees for Forth, but check the subject
line. It's not as easy to keep C subroutines so short; 16 lines of C
is a trivial piece of code. One case statement could easily be more
than that just for the cases alone. And this is not stylistically
"wrong".

I guess the bottom line is that you don't use the English version of
MS-Word to grammar-check Russian.

On Nov 6, 6:00*pm, Andrew Smallshaw <andr...@sdf.lonestar.org> wrote:
> I keep getting criticism for ignoring an imagined 80 column limit.

As others have posted, I find the 80 column limit to be a good
one.

However, in my case, that doesn't come from printer limitations
and it doesn't come from my imagination either. It comes from
80 characters being the width of a non-GUI console.

Sometimes I use a GUI and sometimes I don't.

Regards,
Steve