First off, I'd recommend setting up a CVS (Concurrent Versions System) server.
Concurrent Version System - Wikipedia, the free encyclopedia
As head programmer (which I'm assuming you are), I would setup a set of standard header files. These would be included in the necessary source files, with each header file being completely independent and modular. Say you need to use PID control in a source file, you should just have to include pid.h and it should cover everything you need.
To be honest, I wouldn't worry too much about indent size/function names/etc. Have enough of a standard to make it readable, but not enough to hinder a persons programming time because they have to look up whether it's Function_Name or function_name.
With that being said, I admit to being a perfectionist. This is my current self-standard:
All brackets are placed on next line
Code:
// Good
if(foo == bar)
{
return;
}
// Bad
if(foo == bar){
return;
}
Constants are referred to in capitals, all others in lower case.
Code:
// Good
#define PI 3.14
unsigned int some_variable;
// Bad
#define pi 3.14
unsigned int SOME_vArIABLE;
Variables/Functions use underscores to replace spaces.
Code:
// Good
void Read_Encoder(void)
// Bad
void ReadEncoder(void)
Use short, clear and concise variable/function names.
Code:
// Good
unsigned int left_encoder_clicks = 0;
void Update_Encoder_Count(void)
// Bad
unsigned int amount_of_clicks_back_from_the_encoder = 0;
void Update(void)
Use double slash comments.
Like I said, try to not have super-harsh standards. These are my own, and I realize that they probably are pretty strict... but they are for myself only. If I were to work with a programming team, they would be much more lax.
EDIT: I'd just like to add that I change my standards a lot... just because I'm a perfectionist like that.
The great thing about standards is there are so many to choose from.
-Anonymous