Dec 7, 2008 at 7:30am UTC
Well not just for beginners and let's see if we can find 10 based on the questions
that have been asked in the various forums.
Alwyas use header guards.
2. Do not #include cpp files in other cpp files
(especially when useing IDEs).
Dec 7, 2008 at 12:58pm UTC
Adopt a coding standard, including:
For example, I indent 4 spaces inside each block.
4. naming conventions
I suggest ClassName, _members, ENUMS/CONSTANTS/MACROS. Also make the names meaningful.
5. use whitespace for clarity
I like "func( x, y, z );" and "if( ( asdf == '1' ) || ( asdf == '2' ) )".
Last edited on
Dec 7, 2008 at 1:06pm UTC
Dec 7, 2008 at 5:48pm UTC
6. Always follow The Standard. Never include any header that's not one of these:
* A standard header.
* A header of a library you're using.
* A header of the system API.
Never include compiler-specific headers. Compilers come and go, but the language and the systems stay.
Dec 10, 2008 at 7:04am UTC
8. Don't use magic numbers!
Dec 10, 2008 at 3:05pm UTC
do use numbers. Don't , for example.
#define ONE 1
Dec 10, 2008 at 5:34pm UTC
In a previous job, they were absolutely anal about that. Absolutely no hard-coded constants.
We had a state machine. States were numbered.
#define ONE 1
#define TWO 2
The really funny part was when someone did something like this to fix a bug:
#define FIVE 7
Dec 12, 2008 at 7:46pm UTC
So you had to do stuff like this?
for( int i = FOR_LOOP_INIT_ZERO; i < SOME_CONSTANT_MAX; ++i)
Dec 13, 2008 at 5:48pm UTC
God that (above) looks hideous doesn't it lol.
Dec 13, 2008 at 6:14pm UTC
IIRC 0 was OK to use as the starting for() loop index. but the SOME_CONSTANT_MAX, absolutely. 1 - forget it. Better use a descriptive #define.
These aren't exactly often asked questions, and perhaps aren't even beginner guidelines, but nonetheless IMHO beginners should learn to do the following from the start:
9. Write constructors. Constructors that can take exactly one argument should be explicit, unless it is the copy constructor.
10. Only write a copy constructor if you need to take deep copies or do weird things. In which case also write the assignment operator.
11. If an assignment operator throws, it must leave the "assigned to" object in a known state.
12. Only write a destructor if absolutely necessary (ie, to free owned memory).
12a. Consider using smart pointers or auto_ptrs in place of raw pointers so that memory leaks are less likely (in which case you don't need a destructor).
13. Consider writing operator<< for all value classes, even if just for debugging purposes.
14. Use const correctly.
Dec 13, 2008 at 9:24pm UTC
15. Always ignore that little voice that likes to start sentences with "why would anyone want to..." and "what kind of moron would try to...". Unless the programmer is also the user, there's
always someone who wants to do it, and a moron who tries to do it. It's advisable to obey users and punish morons.
Last edited on
Dec 13, 2008 at 9:26pm UTC
Dec 14, 2008 at 9:42am UTC
Hahaha I like that one helios - More so because it's so true!
Dec 15, 2008 at 12:53am UTC
I think that the scary thing is that often the moron using the program is me.
Dec 15, 2008 at 12:13pm UTC
16. Don't be afraid to ask for help and advice (but DO try to work it out yourself first).
Beginners (and not so beginners) all to often either fall into the habit of either asking for help the instant something isn't obvious, or spending days trying to solve the a minor problem before asking for help.
Dec 15, 2008 at 3:27pm UTC
One thing I've learned in the short time I've been studying/playing with this is:
17) Don't be afraid to stop and walk away for a few when something is kicking you're butt. If you stay, your frustration grows and the answer gets further from your mind (at least it does for me).
Dec 15, 2008 at 4:06pm UTC
17.b. Be sure to keep a video game in or nearby the system where you do your coding so that can relax during these periods. Something not too exciting is preferable. It's also probably better if you don't need to think too much to play it.
Dec 15, 2008 at 11:37pm UTC
When looking through code for errors it's sometimes useful to go backwards. That way you look at each line for what it is rather than what you expect it to be.
Dec 16, 2008 at 8:53am UTC
16A: if you have made
no progress in 30 minutes with your problem, ask for help. If you're making progress, don't.
This is actually company policy in some companies I know of - you're obliged to ask for help and you're obliged to help under the 30-minute rule.