Re: C++ Coding Standards

Michael Mair a écrit :
ct-86@xxxxxxx schrieb:
<snip: cn-URL advertising a translated version of "C++ Coding Standards"
and an excerpt of the list of rules>

While Herb and Andrei have done excellent work and the book
can serve as company C++ coding guideline or standard or
provide a good base for one, this has to do nothing whatsoever
with C. In fact, some of the more detailled rules do not make
sense or may even be harmful when applied to C.

Cheers
Michael

Most of those rules apply to C too. The ones that are C++ specific are:
38 (initialization dependencies).
This is for C++ constructors stuff. Mostly irrelevant in C.
30 (Avoid macros).
In standard C is not possible to replace
#define MAX_SIZE 512
with
const int MAX_SIZE=512;
Lcc-win32 will accept the C++ semantics when you write
static const int MAX_SIZE=512;
In a C context I need the static to ensure the variable is
not accessed anywhere else. In this particular case lcc-win32
will just replace all occurrences of MAX_SIZE with 512
as it was a macro.
28 Use const proactively.
C++ "const" stuff is obscure and can be ignored in C. I
think this simplifies the language, at least it produces
less headaches to me :-)
21 (Ensure resources are owned by objects).
C is not object oriented, so this makes no sense, since
no destructors exists.

The other rules are quite sensible
Organizational and Policy Issues
1
0. Don't sweat the small stuff. (Or: Know what not to standardize.)
2
1. Compile cleanly at high warning levels.
4
2. Use an automated build system.
7
3. Use a version control system.
8
4. Invest in code reviews.
9

All of those rules make sense in C, Python, Ada, Visual Basic...
They are just common sense.

Design Style
11
5. Give one entity one cohesive responsibility

I am not sure what this means in C, probably that you have one function
that organizes the software module calling the others, managing the
shared data, etc.

This is too abstract to be of any use.

12
6. Correctness, simplicity, and clarity come first
13
7. Know when and how to code for scalability.
14
8. Don't optimize prematurely.
16
9. Don't pessimize prematurely.
18
10. Minimize global and shared data.
19
11. Hide information.
20
12. Know when and how to code for concurrency.

Ditto, they are just common sense.

Coding Style
27
14. Prefer compile- and link-time errors to run-time errors.

Who would discuss this? The whole problem is that sometimes it is
just not possible to do!
32
17. Avoid magic numbers.
34
18. Declare variables as locally as possible.

C99 allows you to define variables just besides their intended
usage so this applies to C too.

35
19. Always initialize variables.
36
20. Avoid long functions. Avoid deep nesting.
40
23. Make header files self-sufficient.
42
24. Always write internal #include guards. Never write external
#include guards.


Internal guards (if I understood correctly) would be this:

File win.h

#ifndef __win_h__
#define __win_h__
/* The rest of the win.h comes here */
#endif

External guards would be:
#ifndef __win_h__
#define __win_h__
#include <win.h>
#endif

This is OK, and I would agree with the rule, but I use sometimes

#ifndef __win_h__
#include <win.h>
#endif

This spares the preprocessor to open a file, and parse the whole
file...
I use more often the

#pragma once

that lcc-win32 provides to avoid all this guards stuff, and that
should be standardized as common practice. Microsoft uses the
same construct.

All in all an interesting message in this group. At last, a message
that tells something substantive

.

Relevant Pages

  • Re: C++ Coding Standards
    ... In standard C is not possible to replace ... Compile cleanly at high warning levels. ... Always write internal #include guards. ...
    (comp.lang.c)
  • Re: I want to learn forth but...
    ... A bunch of nested returns for no particular reason except that it ... was too hard to avoid them. ... I think that is used in many Forths at this point. ... standard code isn't supposed to do that. ...
    (comp.lang.forth)
  • Re: Office 2003 Standard and Access 97 on same computer
    ... Everything okay with this scenario? ... Avoid using IE to open docs from. ... office have purchased MVL editions of Office 2003 standard. ...
    (microsoft.public.office.misc)
  • Re: C needs a BOOST
    ... If, as Paul believes, there are awful things wrong with C++ standard containers, then it is important to avoid repeating those mistakes when extending C, and entirely on-topic to discuss what those mistakes were. ... I'd like to do some C++ programming professionally, but it seems not to be the language of choice in my chosen specialty, scientific computer programming. ... jacob at jacob point remcomp point fr ...
    (comp.std.c)
  • Re: Why 64bit Delphi compiler from Borland may be meaningless!
    ... Kostya wrote: ... > since the standard one provided by MS for the rest of us can not ... > even avoid things like a thread starvation and that is totally ...
    (borland.public.delphi.non-technical)
Loading