Coding Habits, What is on my mind while compiles are happening...
« previous entry | next entry »
Oct. 23rd, 2007 | 01:22 pm
I've been thinking a lot lately on coding habits that I have been picked up in recent years. Reasons I write in the way that I do:
Code defensively. Other people will break stuff (and sometimes the other people happens to be me...).
Think about merges. Code I write will go into a code repository of some sort. Either I or someone else will need to do a merge at some point. Make merges happen without issue.
Types! Types! Think thoroughly about problems of size.
Never use globals unless they are completely static (aka think thread safe from the beginning)
So something I do not do:
I do this:
Why? Because if I delete one of the lines, I then don't have to worry about a bad merge. Any of the revision systems I use can merge this stuff without a problem.
Other things? assert(). I make more use of assert() now then what I once did. I use them now though for two reasons:
1) To remind me of where I haven't finished coding (aka this is a branch that I have not finished).
2) I put them in places where I know if I break the internal API this will cause immediate problems in the test cases (and I write more test cases today then I do actual code). For every if, every function call, you need a test case.
I have been parting ways with #define. I use it still to give me constants, but I no longer use it for lists of items. So for instance I will use it for flags, item types... everything it works well for. I write enums so that order doesn't matter and I use for() loops and switch/case with them now.
For error codes I try to never use -1, 0, 1. I use enum, and I write strerror() type functions with string output to remind me what the error was. By putting them in a switch/case I will get a warning if I forget to update the strerror() like function.
typedef all structures. Keep them in bite sized "this is what this means". It is candy for reading code. Most of my C looks pretty OOPish anyway.
Write accessor functions to structures. Do not let your users near your structures (and this goes double for C++). If you must have speed, aka save the function call, use a macro.
MySQL has a coding habit of doing assigns like this:
Why? Assign when you need to assign. Don't get sloppy by using default values (hides valgrind warnings... for that matter do not memset() unless you need to). Why put the = next to the variable?
Because it is easy then to search the code for all assigns.
Always use spaces, never use tabs. Tabs just show bad alignment based on the tool (ok... I've done this one for years... but it is worth repeating).
Write functions, do not copy and paste code (no duh...). There are dozens of projects I see that have not learned this lesson.
What am I undecided on? I still use int and long long. Whenever I am dealing with strings I use size_t. I am beginning to think that I should be using uint32_t and such. C99 has been around for a while
and I like being explicit. I am beginning to royally hate coding libraries where people feel the need to define their own uint types.
Why? Because I want to know exactly what is being fed to the compiler. This type defining is just a pain, and frankly it is ancient thinking.
Enough compilers still don't understand //, so I avoid using them in C. I find that when I need to do /* */ I tend to be more verbose anyway.
I am starting to think about coding more with {} to show off code bodies. Yes, I wrote LISP years ago. Scope when I don't really need too, just so I can see logical parts of code.
When I was at the PHP conference I got into a conversation on revision control. I was appalled at how many developers don't use revision control.
So something I do not do:
int foo, bar;
I do this:
int foo; int bar;
Why? Because if I delete one of the lines, I then don't have to worry about a bad merge. Any of the revision systems I use can merge this stuff without a problem.
Other things? assert(). I make more use of assert() now then what I once did. I use them now though for two reasons:
1) To remind me of where I haven't finished coding (aka this is a branch that I have not finished).
2) I put them in places where I know if I break the internal API this will cause immediate problems in the test cases (and I write more test cases today then I do actual code). For every if, every function call, you need a test case.
I have been parting ways with #define. I use it still to give me constants, but I no longer use it for lists of items. So for instance I will use it for flags, item types... everything it works well for. I write enums so that order doesn't matter and I use for() loops and switch/case with them now.
For error codes I try to never use -1, 0, 1. I use enum, and I write strerror() type functions with string output to remind me what the error was. By putting them in a switch/case I will get a warning if I forget to update the strerror() like function.
typedef all structures. Keep them in bite sized "this is what this means". It is candy for reading code. Most of my C looks pretty OOPish anyway.
Write accessor functions to structures. Do not let your users near your structures (and this goes double for C++). If you must have speed, aka save the function call, use a macro.
MySQL has a coding habit of doing assigns like this:
int foo; foo= 3;
Why? Assign when you need to assign. Don't get sloppy by using default values (hides valgrind warnings... for that matter do not memset() unless you need to). Why put the = next to the variable?
Because it is easy then to search the code for all assigns.
Always use spaces, never use tabs. Tabs just show bad alignment based on the tool (ok... I've done this one for years... but it is worth repeating).
Write functions, do not copy and paste code (no duh...). There are dozens of projects I see that have not learned this lesson.
What am I undecided on? I still use int and long long. Whenever I am dealing with strings I use size_t. I am beginning to think that I should be using uint32_t and such. C99 has been around for a while
and I like being explicit. I am beginning to royally hate coding libraries where people feel the need to define their own uint types.
Why? Because I want to know exactly what is being fed to the compiler. This type defining is just a pain, and frankly it is ancient thinking.
Enough compilers still don't understand //, so I avoid using them in C. I find that when I need to do /* */ I tend to be more verbose anyway.
I am starting to think about coding more with {} to show off code bodies. Yes, I wrote LISP years ago. Scope when I don't really need too, just so I can see logical parts of code.
When I was at the PHP conference I got into a conversation on revision control. I was appalled at how many developers don't use revision control.
(no subject)
from:
dblume
date: Oct. 23rd, 2007 09:49 pm (UTC)
Link
Reply | Thread
(no subject)
from:
dormando
date: Oct. 23rd, 2007 10:48 pm (UTC)
Link
Reply | Thread