Which may still not be the most effective response to the error...
Yeah! As if it were not difficult enough to avoid errors in the first place, we can now handle them with same ease? After an assert()==programmer_error all your preconceptions are invalidated, there is nothing left to rely in your quest for a more effective response.
Look at it this way - if you're in a fly-by-wire plane and the computer system reports an error, do you:
(a) want to try and continue anyway
or
(b) shut down all the computers and engines:)
assert() is only used during development. By the time it will be embedded in a released fly-by-wire system it was already tested extensively. If not than that is your real problem! Whole point of using asserts is to fail fast during development, so that errors become painfully visible, with a clear message: FIX ME NOW!
parameter name - what is is for and any restrictions on it (i.e., must not be null)
- return value (all possible return values)
Give proper name to function and parameters so that all this becomes evident. assert() paramter precodintions at begining so restrictions will be self documented. Make sure that function has simple semantics so return value is also evident, on rare cases when you cant do this add a comment.
2. Add comments to each file you modify so that over time, the file becomes better documented.
Refactor each file when you modify and found them not obvious: to make them obvious. Commenting will not fix this, you are just introducing pieces of documnetations that can/will get ouit of sync.
4. Use dividing comments like a line of dashes to seperate blocks of code
Separate them in different functions, that you can write tests agains individualy.
8. Tag your bug fixes, code enhancements with a comment followed by a dash, date, and your initials. This is essential for large projects or for anything you will be working on for more than 6 months.
Use facilities provided by your source control management tool. cvs/svn/clearcase/(...) has annotate, blame, praise fuctions: use them instead and you will be able read them even after 6 years.
Format your comments so that multiple line comments line up on the left hand side (increases readability)
Write them on top of commented item, this way they will not go off screen, you be able to print for them more without much fuss.
Don't count on java doc or equivalent as being good enough code documentation.
What pleasure? They will work at a distance of few thousand miles from their families an friends. Without significant protective rights enforced on their employers by any government, full time on a freaking ship. Pleasure cruises lasts a few weeks, do you think that their `employment` will be shorter? How long do you expect them to last on average? A year or maybe two? Where is the cost effectiveness of that?
Repeatedly compiling Linux kernel for about 24h will bring out errors that simple pattern based memory testers might not detect. I've experienced this once.
For detailed explanation see http://www.bitwizard.nl/sig11/
Slashdot Mirror
Yeah! As if it were not difficult enough to avoid errors in the first place, we can now handle them with same ease? After an assert()==programmer_error all your preconceptions are invalidated, there is nothing left to rely in your quest for a more effective response.
assert() is only used during development. By the time it will be embedded in a released fly-by-wire system it was already tested extensively. If not than that is your real problem! Whole point of using asserts is to fail fast during development, so that errors become painfully visible, with a clear message: FIX ME NOW!
Give proper name to function and parameters so that all this becomes evident. assert() paramter precodintions at begining so restrictions will be self documented. Make sure that function has simple semantics so return value is also evident, on rare cases when you cant do this add a comment.
2. Add comments to each file you modify so that over time, the file becomes better documented.Refactor each file when you modify and found them not obvious: to make them obvious. Commenting will not fix this, you are just introducing pieces of documnetations that can/will get ouit of sync.
4. Use dividing comments like a line of dashes to seperate blocks of codeSeparate them in different functions, that you can write tests agains individualy.
8. Tag your bug fixes, code enhancements with a comment followed by a dash, date, and your initials. This is essential for large projects or for anything you will be working on for more than 6 months.Use facilities provided by your source control management tool. cvs/svn/clearcase/(...) has annotate, blame, praise fuctions: use them instead and you will be able read them even after 6 years.
Format your comments so that multiple line comments line up on the left hand side (increases readability)Write them on top of commented item, this way they will not go off screen, you be able to print for them more without much fuss.
Don't count on java doc or equivalent as being good enough code documentation.Extend when you find the need for it.
What pleasure? They will work at a distance of few thousand miles from their families an friends. Without significant protective rights enforced on their employers by any government, full time on a freaking ship. Pleasure cruises lasts a few weeks, do you think that their `employment` will be shorter? How long do you expect them to last on average? A year or maybe two? Where is the cost effectiveness of that?
Repeatedly compiling Linux kernel for about 24h will bring out errors that simple pattern based memory testers might not detect. I've experienced this once. For detailed explanation see http://www.bitwizard.nl/sig11/