C++ Code Style Guidelines

Use good OO design. Think carefully about the classes that you are creating before you start writing code. Use the standard library classes and STL as much as possible.
Use streams and stream operators rather than C style I/O functions.
Always write a destructor for a class immediately after you write a constructor; this will help you to correctly implement the destructor code.
Use good, descriptive names for class, method function, data member, and variables.
Pick a capitalization style for class names, method function names, private data and methods, public data and methods, local variable names, constants, etc. and stick with it. There are some conventions for many of these that are given below.
Avoid mixing C-style functions with C++ OO method functions. There are times when using a C-style functions is exactly the right thing to do, but in most cases, functions should be associated with a class.
Avoid using global variables; pass objects by reference instead. In fact, you should avoid imperative style programming constructs like functions, global variables, and #define. Instead, use method functions, static data members, and const as much as possible.
Avoid using multiple inheritance. There are, of course, cases when it should be used, but these cases are rare and you should think carefully about other design options before deciding that this is the right one.
Comment your code! Every .h and .C file should have a high-level comment at the top describing the file's contents, and should include your name(s) and the date. In header files, write comments at top of every class definition describing the class in a general way. Also, comment every method function (except trivial accessor and modifier methods) describing: (1) what function does; (2) what its parameter values are; and (3) what values it returns. In source files, comment functions similarly. Class data members should be commented, unless their names make it obvious what they are (by choosing good names for data members, you can avoid commenting most of them). In addition, any tricky code (in .h or .C files) should contain in-line comments describing what it does.
The general rule for .h vs. .C comments is that .h are for the user of the class (they don't necessarily care how the function is implemented, they just want to be able to call the function; they need to know what it does, what it returns, and what to pass to it). Comments in .C files are for someone reading the implementation of the class (in addition to the .h file comment info, you may add more information about the algorithm used to implement the function). I tend to create the .h file first, add all comments, then copy the .h to the .C (now I have all the function comments for the function implementations that will be in the .C and I only need to add additional comments about implementation).
When commenting stick to a particular style. For example:
```
	// 
	// public method function: getRadius
	//   input: none
	//   returns: the radius of the circle in inches 
	//
	float SemiCircle::getRadius() {
	    return _radius;	
	}

	// 
	// public method function: flipOrRotate 
	//	rotates the semi-circle by the given degree
	//	and/or flips it over its radius 
	//
	//   deg: the number of degrees to rotate the semi-circle
	//	  positve value will rotate clockwise
	//	  negative value will rotate counter-clockwise
	//   flip: if 1, flip the semi-circle over its radius
	//	   before rotating  
	//   returns: no return value
	//
	void SemiCircle::flipOrRotate(float deg, char flip) {
		...
```
Deciding where to put the implementation (the .h file or the .C file): Typically, short methods can (and should) be implemented in the .h file. Methods that are implemented in the .h file can be in-lined by an optimizing compiler, and short methods are good candidates for in-lining. Longer methods typically do not benefit by being in-lined so they should not be implemented in the .h file... you want the .h file to be readable.
Class names should start with a capitalized alphabetic character. Multi-word class names should have each word capitalized. For example:
```
	class SemiCircle : public Shape {

	};
```
Group data members and methods together in a logical way. For example, you can group all public method functions first, followed by all public data members, then group all private functions, followed by all private data members. Another option is to group all functions together (all public ones first followed by all private ones), then group all data members together (again public ones grouped first followed by the private ones).

Public methods and data members should start with a lower-case alphabetic character. For example (note: comments have been removed here):

	class SemiCircle : public Shape {
	    public:
		float  getRadius(); 
		double area(); 
		void   flipOrRotate(float deg, char flip); 
		bool   inRadians; 
	};

Private method functions and data members could start with an underscore character to easily distinguish them from public function and data members. For example:

	class SemiCircle : public Shape {
	    public:
		float  getRadius(); 
		double area(); 
		void   flipOrRotate(float deg, char flip); 
		bool   inRadians; 
	    private:
		void  _convert_to_radians();
		float _radius;
	};

Avoid using public data members. Provide accesser/modifier methods instead (if you implement these methods in the class definition, then any compiler can in-line their code). For example:

	class SemiCircle : public Shape {
	    public:
		float  getRadius(); 
		double area(); 
		bool   isInRadians() { return _in_radians; } // accessor method
		void   setRadians(bool on); { _in_radians = on; } // modifier
	    private:
		void  _convert_to_radians();
		float _radius;
		bool  _in_radians;	// private data member
	};

Any global variables or global functions for the minibase assignments should have the prefix minibase_. Macro definitions should begin with MINIBASE_.