This link has been bookmarked by 33 people . It was first bookmarked on 20 Aug 2006, by someone privately.
-
16 Nov 07
-
08 Oct 07
-
23 Jul 07
-
02 Jan 07
-
31 Dec 06
-
30 Dec 06
-
-
- Initialize all variables to zeros. If I declare an int I do this (int iValue = 0;) if I allocate a char array I do this (char szTemp[20]; memset(szTemp,0,20);).
- Check the return codes of all function calls.
- Catch all exceptions at an appropriate level and deal with them. One of the bad habits I had earlier in my career was to setup an empty catch block and think I was going to fill it in later.
- When defining function prototypes consider error conditions. This means deciding whether to return a bool or an int (an int can return a set of predefined flags indicating what kind of problem occured. A bool can only indicate success/failute.) If there is additional info that a simple code can supply, consider passing in a string or other variable by reference to hold the extra error information OR consider throwing an exception.
- Never pass objects by value unless ABSOLUTELY necessary. (I can't think of a situation where this has ever been necessary, but there might be.)
- Use GOTOs wisely. The only place I have every used a goto (that I can think of) is in a lexical parser I had to write a few years ago.
- Create more utility classes than program-specific classes.
- Think about how a piece of code might be used in another project and go ahead and develop for that. (Don't take this to an extreme, though.)
- Comment judiciously. When I write code comments I try to comment on the architecture and purpose of a function/class instead of on the lowest level of details.
- The equality operator and the set operator are not the same DAMN@!#$# thing. I can't remember how many times I have done if (x=y). To avoid this I have created inline functions like FPSCompareString, FPSCompareInt, FPSCompareLong, FPSCompareFloat, FPSCompareDate, etc which have virtually eliminated this problem from my code.
Develop Good Coding Habits
Good coding habits are very important to the quality of the code produced as well as to the quality of the final product which uses the code. Nothing earth shattering here, just learned behavior. Some of the most important habits I have learned are:
I'm sure there are hundreds of other rules I could write up but that could take whole books. The bottom line for me is that there is no one to review my code or help me when problems arise. If I can eliminate the most common problems I can spend more of my time working on the more serious problems.
-
-
-
The Standalone Programmer: Tips from the trenches
-
-
15 Nov 06
-
14 Nov 06
-
17 May 06
-
12 May 06
-
08 May 06
-
06 May 06
-
13 Feb 06
-
18 Jan 06
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.