Ten best practices every beginner should use..
Pages: 12
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.
1. Headers
Alwyas use header guards.
2. Do not #include cpp files in other cpp files
(especially when useing IDEs).
Any others?
that have been asked in the various forums.
1. Headers
Alwyas use header guards.
2. Do not #include cpp files in other cpp files
(especially when useing IDEs).
Any others?
Adopt a coding standard, including:
3. indentation
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' ) )".
3. indentation
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
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.
* 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.
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
etc.
The really funny part was when someone did something like this to fix a bug:
#define FIVE 7
We had a state machine. States were numbered.
#define ONE 1
#define TWO 2
etc.
The really funny part was when someone did something like this to fix a bug:
#define FIVE 7
So you had to do stuff like this?
for(int i = FOR_LOOP_INIT_ZERO; i < SOME_CONSTANT_MAX; ++i)
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.
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.
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
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.
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.
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).
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).
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.
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.
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.
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.
Pages: 12