What coding standard are you using for C?

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

ROFL, Vladimir, that was good.

Dimiter

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

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.

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

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

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@sdf.lonestar.org

Can do, but excessive indentation levels is often an example over complexity and the need for restructuring or extra function(s).

What a Landscape mode print can do.

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?

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@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

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.

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...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

(etc)

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.

In the days before networks and hard disks were common even in small firms, there was an issue with media - I know that we have programs from our company's early days that are effectively lost because they are on old 5 1/4" floppies. You can also get in trouble if you use tape for your primary archive media. But other than that, media should not be an issue. Printer sizes have not been an issue for something like 20 years at least, since laser printers let you pick different font sizes and thus different numbers of characters per line. And editors that can work happily with files of different sizes, different line widths, different line endings, and different character sets have been around for at least as long.

So unless you are storing your source code files in some locked proprietary file format, any source code file written for the last fifteen years at least is ease to read, edit and print out from virtually any system. I don't know where you picked the "two years average lifespan" from, but it certainly wasn't reality.

When looking at tools, it's a different matter, and there are very real issues with new versions of tools being unable to work with old projects, and old versions of tools being unable to run on modern systems. The situation is far too varied to generalise, but it's definitely something to consider when choosing tools - and also something totally unrelated to coding standards.

Proprietary file formats are another problem, but fortunately for C programmers, they are only an issue for things like project files rather than for the actual source code.

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

The old server has gone done and this hard drive uses an interface and file system no longer supported by new system(s), is more common a problem than most people think. Then they go to backup and the backup for that server was not network but tape (and not compatible with any other drive in the place) or mirred to another drive of same type that is difficult to interface.

I get questions like this often.

Assumptions that all editing is done with GUI, that a suitable font will be available, that the new tools will always be able to deal with line endings and non straight ASCII encodings. That printer or printer driver will not substitute a different font or SIZE.

Even simple Notepad still cannot deal with anything other than Windows style of line endings. Not uncommon for GUI based tools to use the OS method of line ending ONLY.

As soon as you have to pick font, including size, you have to document that probably at the head of each file.

If you do code review MEETINGS do you expect everyone to sit there looking at screens?

Very much so in reality, as mobile phones, MP3 players, components for desktops, Laptop utilities, PC BIOS, consumer products, change model about every 6 months or less. Considering warranty time periods and how long before last unit is sold, the time between LAST release of software for one model and end of support is about 2 years (often less).

Even for a lot of desktop software, it is always buy the new version and if necessary a new OS (and system).

So beyond two years they are not even interested in keeping THAT version of the software. They may have a lot of the modules reused/reversioned for later models.

So for an AVERAGE lifespan of code that is a reality, some code is much longer, but the majority of C code is not. ...

Proprietary file formats even covers the file system, and if straight ASCII has been used to store the file.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

I think that's a point. I do the same thing, mostly because I still have and use Microsoft's M (or ME) which supports writing your own C code that can be linked into the editor to extend its features. I've done that. However, the fact that I can also do a lot of editing with Windows' editors (IDE or otherwise) means that it isn't quite as much of an issue for me as it would have been when I was only using that editor alone.

The printing issue is more important to me partly because straggling lines that display into the left side margins distract my eye. It's just enough that I have to _consciously_ ignore them. And that can be just enough of an annoyance in constructing mental models from reading that I can be slowed down for a moment. Why have the trouble, at all?

It's also about worrying about others who may read or need to print, too. Or have their own reasons for preferring an 80 column limit. (Very few have problems working with 80 or under.) It's not just for me.

A few days back:

Tabs are a great questi>Just don't write assembly code in capital letters and do fill tabs

My own preference is to do space-fill and to use 4 spaces per. With fixed-pitch fonts, 3 is okay. 2 is too small for my eyes to quickly recognize in the face of all fonts and characters. So I like at least

1. More than 4 or 5 and it eats up the 80 columns too fast. Which brackets me, tightly. And using spaces ensures that others see about what I want them to see -- there is a consistent appearance I can plan for this way.

Not every program allows for viewing or printing with arbitrarily set tab stops ... some insist on columns 9, 17, etc. and brook no changes to that. Use of tabs would wreck some havoc in these cases.

However, there is an argument _for_ tabs when I take into account others who may also want to read or print my code. Tabs provide the easy ability for different people to select different preferred alignments and they work even in the face of proportional fonts, which some may also prefer for reasons of their own. If I enforce my own indent requirements by using spaces, I make it more difficult for them if they really want something other than my own choice.

What nails down the answer to these questions starts with this: I need and want creative control over the appearance of what I write. There are times when I need to generate ASCII pictures to help communicate issues related to the code. I do this often enough that it is very important. Here's an example of what I mean, which includes a coroutine diagram, some tables, and examples in order to discuss the methods I used in writing a fast 8051 float division routine:

In these cases, and others, using tabs becomes far too much of a liability in communicating to others. I need to have a lowest common denominator I can rely upon for communication. Limiting as it is, this means spaces, not tabs; 80 columns, not more; and fixed-pitch fonts, not proportional.

Jon

I like to stick to just under 80 columns (i.e., sometimes, the

80th is needed for a newline indication).

The ~80 column limit is advisory, just like other "guidelines". But, breaking it should only be done "for good reason".

You also have to consider how other people viewing your code will be affected. Do they use 80x25 xterm(1)'s? "DOS consoles"?

If they *are* working in a GUI envrionment, do they have enough desktop space to "waste" on overly wide source lines? E.g., a GUI debugger usually prepends stuff to each line (break point indicators, etc.). A scrollbar adds to the actual width of the window, along with other window decorations.

And, I suspect most folks would like to have other windows visible on the desktop alongside the "source" window so the wider you make your source, the greater the impact on those other windows. (e.g., I like having a schematic open when I am writing drivers).

My primary work desktop is 3200x1200. So, if I *wanted* to have

130 character lines, that's not a problem. Why stop at 130? Why not *200*?? :>

My primary desktop is 4960x1600(*) but my editor is only 120 columns. If I maximize it across all three monitors, it's 700 columns (358 if I juse use the main one). I don't use the whole 120 colums usually, I like to have some whitespace to the right of the text so I can easily see when lines (like program outputs) wrap.

My xterms are 115x58, which is a weird geometry but it allows four of them to tile in the remaining space without overlapping.

(*) one big monitor landscape, two small portrait ones to each side. The two portrait ones are great for PDFs, web browsers, IRC... Try rotating your two monitors someday, for a 2400x1600 display. Might be more useful than 3200x1200.