Assert Parameters

Is it a good programming practice to list assertions for all the parameters? Or bad practice to not do so?

For example,It seems like it would help with debugging, but at the same time it seems to bloat the code, especially for functions that would otherwise be just a single line. Should this responsibility be left to the user? Where the documentation might read, for example, If list does not point to a valid LinkedList structure the behaviour is undefined.

Assertions ARE debugging features. When you generate release code they will go away.

Hi,

Speaking as a newbie,

My opinion,
ASSERTS are eXtremely important when programming.
Every function has it's set of preconditions and postconditions
which you should state for yourself.
The good thing about this practice is that it changes your way of
thinking when programming the code. Because you have to rigorously
state what can be accepted and what not you are more focused as to
what can go wrong than what can go right about your code.
Just imagine yourself being a teacher who has to correct the
examinations of a 1000 students. Because of the amount of work to be
done, the most likely approach that you will do in correcting these
examinations is to look directly to the solution, skipping the student's
reasoning. Of course, you are not assured to be correcting 100%
correctly but it gets the job done within reasonable parameters.
So what the teacher actually did was just to check the postcondition
of every answer, with the mentality that when then answer is correct,
the reasoning must also be correct. (Again not a 100% correct
assumption)

An example, from my practical experience :
We had to implement a priorityqueue based on a heap.
We were allowed to use a STL container(like vector) to implement it.
So I have a



I am almost obsessed with setting pre and postconditions, upto the
point I do like this :

element_added simple checks the contents of the 2 containers
and returns true if all the elements are identical except for in_el.
After I tested the class CHEAP, I decided to make an interface class
CPriorityQueue . Everything was working, but somehow, believe it or
not, but due to some stupid mistake (2) FAILED despite (1) being set.
This was contradictory to all logic, and wouldn't it have been for
that assert, I would had to spend hours in trying to find the relevant
bug.(because the bug is contradictory to logic...)

I realized very quickly that I did not call the methods of CHeap correctly
in CPriorityQueue. The compiler didn't give an error, which I think is
strange due to what I had done...

Whenever I make a program, I first make a design stating all pre and postconditions. Then I only implement the headings of this design.
I use vim to edit, and when I press F4 I get something like this
:MakeComment
I can input a parameter
:MakeComment +Foo(in_bar) : bool out_gnam {query}
When I press enter I get :



If you look on the web, Software Engineering Xtreme ASSERT you will probably find more information regarding this topic.

Regards.

If you know Oberon,
Turbo Pascal --> Modula --> Modula 2 --> Oberon,
By Nicklaus Wirth, you will certainly agree with me that it has
a nice feature regarding setting of pre- and postconditions.
Into your code you put in something like this
assert(condition, number)
with 100-->110 reserved for preconditions, 110-->120 invariants,
120 --> 130 for postconditions.

Now the interesting thing is that when you use the tool Watson
it lets you give an overlook of your implementation headings.
(so the function bodies are all skipped, only the function heading is visible)
When you have specified pre- and/or postconditions they become visible as well, permitting the user to get a quick overvieuw of
what to expect from the code.
--------> like this
Function heading
precondition 101 : ................
precondition 102 : ................

All the others(< 100, 110 < 120 and > 120), do not become visible.

Jeff Mott said something like this,


To my newbie knowledge, I would say no, this responsibility should
not be left to the user with a manual like that. Because he/she will most likely abuse it willingly/unwillingly.

Also, as a user I don't trust the word of the implementer regarding
what to expect from the code. Simply because bugs can't be avoided.
But if you put in ASSERTS into your code, and I use a tool like WATSON
then I at least have something to build upon, some axioms regarding the use of the code.

Regarding the bloating of the code, that depends.
You are right that some conditions are not very easy to state,
especially because everything that is being used in those condtions
should be publically visible, but this shouldn't prevent you using them.

As I stated before, I am a newbie, don't know much, so

I hope someone more experienced can explain in more detail and
point out my stupid remarks, so I can improve in this topic.


Regards.

assert() is great for debugging, because it stops the code right where the problem occurs, rather than let the code proceed and fail later on down the line. Sometimes, debugging code is a real pain in the neck, because the cause of the error is far away from where the error occurs (say, the result of using a null pointer causes a function four levels up the call stack to fail occasionally). When you're using assert(), you're putting in some sanity checking to make sure that your data is within an expected range at certain stages in your program.

Quite a few (if not all) C++ compilers will compile out the assert() statements in release mode, so the extra assert() code never makes it out to the final executable, if you compile it with the necessary optimization switches.

You don't need optimizations; just #define NDEBUG, or compile in release mode (if your compiler has such a switch, which generally defines this macro).