[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Shopsuite-dev] C++ coding rules

From: Davi Leal
Subject: [Shopsuite-dev] C++ coding rules
Date: Mon, 23 Jul 2001 21:03:26 +0100

Tomasz, I will fix all this "typing" sooner or later. You have not to worry
about it if you does not want. I only inform you. What do you think?.

Assigning Names

* No underscore to separate names. User Smalltalk convention of capitalising
the first letter of every word in a name.

* Global variables begin with 'the' (for example, theShopDB).

* Routines which allocate storage or take responsability for its storage have
special names and abide by the following guidelines:
 1.- Routines that make a new object which the caller must delete should start
with "create".
 2.- Routines that copy an existing object, and where the caller must delete
the copy should start with "copy"; in particular, a member function which just
copies an object should be called "copy()".
 3.- Routines that accept an object the caller has allocated and take
responsibility for eventually deleting it should start with "adopt". This
style of programming is error prone and should be avoided if possible.
 4.- Adopting routines that cannot follow the above rule (e.g. constructors)
should start the name of the formal parameters with "adopt".


Use c++ comments //.  Only use c comments /*...*/ as in the example and
similar cases.

 void function(int a, int b, int /* c */ )
  int temp = a;
  a = b;
  b = temp;

The 'c' variable is commented to prevent warning messages ('c' is not used).


Always write the left parenthesis directly after a function name.

void foo ();  // No!!
void foo(); // Better

Pointers and References -- This is my mistake --

The dereference operator '*' and the address-of operator '&' should be
directly connected with the type names in declarations and definitions.

The characters '*' and '&' should be written together with the types of
variables instead of with the names of variables in order to emphasise that
they are part of the type definition. Instead of saying that *i is an int, say
that i is an int*.

 char* userName = 0;
 int sfBook = 42;
 int& anIntRef = sfBook;

Classes. Constructors and Destructors

* Every class must have a destructor
 If destructor have been defined consistently throughout your code, then that
simple mechanism takes care of many routine housekeeping chores, and helps to
prevent memory leaks.

Memory Allocation

* Do not use malloc, realloc or free.
* Use <iostream> instead of <stdio.h>


* Do not use spaces around '.' or '->' nor between unary operators and

* The 'struct' must not be used. Use 'class' instead.

More rules could be added. However, I think that now it is good so. We / (the
project) will see it later.

I attach my current state with some of the rules applied. I have not committed
the patch yet. Do you think that I must commit it?. Do you agree?.

Attachment: shopsuite.tar.bz2
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]