Most important for a programmer is to know how to test your code.... AND DO IT!
Any monkey can make code. Making code that works is the mark of a good coder. This doesn't come with time or experience. Even the most experienced coder makes coding errors (and lots of them), but what distinguishes the good coders from the bad is that the good ones FIND their mistakes before releasing their code!
So, test continuously, test often, test everything, test every single module/function in isolation, test the modules/functions working together, then test everything again! Make automatic test programs that you can run at a moments notice (or even better have a test machine checking out your code frequently and run them). Run them at least once a day (no, I'm not kidding). Remember, the sooner you catch an error, the less 'cost' it carries. Use a code coverage tool to ensure you've tested all your code. Test methodically, not haphazardly 'poking' the code and calling that 'testing'.
I've been coding professionally for 15 years now. It still amazes me to see how many 'old' coders think they're coding gods just because they know every in and out of a dozen languages, and yet their code still fails frequently because they don't bother to test it (they don't need to, "because they know their shit" *roll*).
Learn to test your code well, and you're well on the way even if you don't know the language you're coding in as well as others.
Knowing what you talk about.....
on
Tech Vs. Business?
·
· Score: 3, Insightful
It is very rare to find 'business' people who understand technical issues, and yet they quite often tries to control deadlines, features etc. for technical projects, quite often against the recommendations of the technical people.
This more often than not leads to delays (sometimes years!) which the business person then tries to blame the technical people.
Essentially, most business people tries to put limits on all of these in projects: Resources, Features, Time, Quality
Where technical people knows you can only limit 3 of the 4.
So, in general the reason for the animosity from us techies is pretty simple. Most business people don't know what they're talking about, but pretend to know our area better than us (when they don't).
And I can't stand seeing them separated as it hurts the readability of the code:-)
For me, wasting 3 lines of my viewing space for a simple 'else' is close a crime.
This is actually not a good example of stuff to put in a set of coding guidelines. Any decent editor or beautification tool can correct the indentation or other visual issues automatically if you so wishes.
I also don't think there are many programmers who would be confused and make mistakes because of braces/else put separately or on each their lines. If there are, they shouldn't be let near code:-p
Also, this is one of the 'religious' coding issues where you're bound to run into other people's opinion. Making guidelines for unimportant stuff as this really is makes it much harder to setup guidelines for the important stuff.
For how things 'look', it is often enough to specify that code should easily readable with blocks properly indented, no tabs (another religious issue, but by now mostly won by the no-tabs believers), consistency throughout a file, separation of functional blocks by empty lines, and braces around all blocks (even oneline if's).
What is much more important in coding guidelines is to define coding behavior you don't want in your codebase. The obvious example being goto's/jumps.
Another one I always like to have in for C/C++ is a section about how we do memory allocation. As pointers are the cause of at least 50% (imho) of all problems you encounter in C/C++, restricting how people use malloc/free and their resulting pieces of memory is very worthwhile.
Also important is to limit your coding guidelines to what you are willing to enforce!
Enforcing coding guidelines takes time, and sometimes your management will force you to skip reviews to ship in time. If you are not given time to revisit the code afterwards to enforce the guidelines, your code will start to have non-enforced parts in them, and this confuses people and worse, makes them use their own style and not the guidelines.
In these cases, it is quite often better to have a smaller set of core guidelines aimed at eliminating dangerous coding practices than a big all-encompassing perfect set.
Slashdot Mirror
Most important for a programmer is to know how to test your code.... AND DO IT!
Any monkey can make code. Making code that works is the mark of a good coder.
This doesn't come with time or experience. Even the most experienced coder makes coding errors (and lots of them), but what distinguishes the good coders from the bad is that the good ones FIND their mistakes before releasing their code!
So, test continuously, test often, test everything, test every single module/function in isolation, test the modules/functions working together, then test everything again!
Make automatic test programs that you can run at a moments notice (or even better have a test machine checking out your code frequently and run them). Run them at least once a day (no, I'm not kidding). Remember, the sooner you catch an error, the less 'cost' it carries.
Use a code coverage tool to ensure you've tested all your code. Test methodically, not haphazardly 'poking' the code and calling that 'testing'.
I've been coding professionally for 15 years now. It still amazes me to see how many 'old' coders think they're coding gods just because they know every in and out of a dozen languages, and yet their code still fails frequently because they don't bother to test it (they don't need to, "because they know their shit" *roll*).
Learn to test your code well, and you're well on the way even if you don't know the language you're coding in as well as others.
It is very rare to find 'business' people who understand technical issues, and yet they quite often tries to control deadlines, features etc. for technical projects, quite often against the recommendations of the technical people.
This more often than not leads to delays (sometimes years!) which the business person then tries to blame the technical people.
Essentially, most business people tries to put limits on all of these in projects: Resources, Features, Time, Quality Where technical people knows you can only limit 3 of the 4.
So, in general the reason for the animosity from us techies is pretty simple. Most business people don't know what they're talking about, but pretend to know our area better than us (when they don't).
And I can't stand seeing them separated as it hurts the readability of the code :-)
For me, wasting 3 lines of my viewing space for a simple 'else' is close a crime.
This is actually not a good example of stuff to put in a set of coding guidelines. Any decent editor or beautification tool can correct the indentation or other visual issues automatically if you so wishes. :-p
I also don't think there are many programmers who would be confused and make mistakes because of braces/else put separately or on each their lines. If there are, they shouldn't be let near code
Also, this is one of the 'religious' coding issues where you're bound to run into other people's opinion. Making guidelines for unimportant stuff as this really is makes it much harder to setup guidelines for the important stuff.
For how things 'look', it is often enough to specify that code should easily readable with blocks properly indented, no tabs (another religious issue, but by now mostly won by the no-tabs believers), consistency throughout a file, separation of functional blocks by empty lines, and braces around all blocks (even oneline if's).
What is much more important in coding guidelines is to define coding behavior you don't want in your codebase. The obvious example being goto's/jumps.
Another one I always like to have in for C/C++ is a section about how we do memory allocation. As pointers are the cause of at least 50% (imho) of all problems you encounter in C/C++, restricting how people use malloc/free and their resulting pieces of memory is very worthwhile.
Also important is to limit your coding guidelines to what you are willing to enforce!
Enforcing coding guidelines takes time, and sometimes your management will force you to skip reviews to ship in time. If you are not given time to revisit the code afterwards to enforce the guidelines, your code will start to have non-enforced parts in them, and this confuses people and worse, makes them use their own style and not the guidelines.
In these cases, it is quite often better to have a smaller set of core guidelines aimed at eliminating dangerous coding practices than a big all-encompassing perfect set.