Is This Good Coding Practice?
Author
A lecturer at uni mentioned something about it being good practice to validate any incoming and outgoing variable at both the start and end of a function. Surely this is overkill for functions that arnt always being manually called by the programmer.
ace
My friend, there is NO SUCH THING as "overkill" when it comes to documentation. When your program involves thousands upon thousands of lines of code, it is far better to have three remarks per little expression than it is to leave even one line remarkless...because though you *think* you'll remember what it does, you may and probably will not.
And that SUCKS.
Spam your code with remarks, man. That's why IDEs allow you to color code them...so you can skim thru and ignore them, but if you need to read them, they are there!
And that SUCKS.
Spam your code with remarks, man. That's why IDEs allow you to color code them...so you can skim thru and ignore them, but if you need to read them, they are there!
It's a very good idea. The nastiest bugs you'll ever run into will be the ones where the source of the bug is non-obvious. Testing the validity of every input and output helps to ensure that your program crashes near the source of the error.
assert statements are perfect for this, as they are not executed in release builds.
assert statements are perfect for this, as they are not executed in release builds.
Quote:Original post by the Speed Bump
assert statements are perfect for this, as they are not executed in release builds.
This does not have enough emphisis. Let me put it more clearly:
USE ASSERT WHEREVER YOU CAN
USE ASSERT WHEREVER YOU CAN
USE ASSERT WHEREVER YOU CAN
USE ASSERT WHEREVER YOU CAN
USE ASSERT WHEREVER YOU CAN
USE ASSERT WHEREVER YOU CAN
USE ASSERT WHEREVER YOU CAN
USE ASSERT WHEREVER YOU CAN
USE ASSERT WHEREVER YOU CAN
Don't make me start doing ASCII art letters.
----- ----- ---------- ----------| | | | | | | || | | | | ----- | ------| \ / | | | | || --- | ----- | | ------\ / | | | | ----------- ---------- ----------It.
How does one unit-test something that's spattered with assertions. Does one replace the assert handler?
I would think so, whether that means brute-force #define or using your own Assert functions that throw in the presence of unit tests.
I was thinking about this the other day. It is trivial to evaluate function preconditions, but not quite as trivial to evaluate post conditions. If you only have one exit point, it is easy. However, if you have multiple exit points, you may have troubles with maintenance.
It is in these situations that I begin to see the value of preferring private virtual functions with public nonvirtual functions to call them. The virtual call can be wrapped with pre and post condition checks easily.
I was thinking about this the other day. It is trivial to evaluate function preconditions, but not quite as trivial to evaluate post conditions. If you only have one exit point, it is easy. However, if you have multiple exit points, you may have troubles with maintenance.
It is in these situations that I begin to see the value of preferring private virtual functions with public nonvirtual functions to call them. The virtual call can be wrapped with pre and post condition checks easily.
The way I understand it, Unit Testing and Asserts address different problem domains. Asserts are for more fine grained tests (i.e: variable values and invariants), where as Unit Testing tests the validity of an entire logical concept (i.e: The function/class does what it's supposed to).
Quote:Original post by daerid
The way I understand it, Unit Testing and Asserts address different problem domains. Asserts are for more fine grained tests (i.e: variable values and invariants), where as Unit Testing tests the validity of an entire logical concept (i.e: The function/class does what it's supposed to).
Yes, I understand that. But the point is: The default behavior for an assert on Windows is to put up a modal dialog box. That doesn't play too well if you want to execute a large number of unit tests, possibly automated.
Putting in validation can really save you some time by taking you to the immediate place your problem stems from, rather than having to back-track through tons of debug. So yes its good practise.
unfortunately on functions that need to be very efficient (functions in games, or on servers dealing with very high trasaction-rates for example) you have to miss it out.
you can write special validators that can be compiled in or out of your program depending on what you feel like, so when you hit a problem you can recompile with them in and once you've fixed the bugs compile them out for speed.
i.e. the code you put in for validation can be turned off so theres no speed-loss and then activated when you hit a problem.
try looking up the 'assert' command for C++
unfortunately on functions that need to be very efficient (functions in games, or on servers dealing with very high trasaction-rates for example) you have to miss it out.
you can write special validators that can be compiled in or out of your program depending on what you feel like, so when you hit a problem you can recompile with them in and once you've fixed the bugs compile them out for speed.
i.e. the code you put in for validation can be turned off so theres no speed-loss and then activated when you hit a problem.
try looking up the 'assert' command for C++
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
