Re: algorithm, two implementations that act the same, same type etc

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2021-02-15 18:34, Mehdi Saada wrote:
> 
> I would not post code if I wasn't thinking I know of its purpose.


You may know, but we (the newsgroup) don't, and you asked us to read 
your code and try to find your error. The error turned out to be a typo, 
but it could have been a mismatch between what you wanted the code to 
do, and how the code was designed. That is why I asked you to explain 
the purpose. Also, some of the identifiers you used are French-derived, 
and some of us may not French and find the identifiers obscure.

(Perhaps you can take my request as a compliment to you: that I did not 
expect that you would make such a simple typo mistake, or would have 
found such a mistake on your own.)

I find that writing a description, in prose comments, of a subprogram, 
before I start coding the subprogram, forces me to think about it, and 
reduces the chance of design errors in the algorithm. This is especially 
true if there are corner cases like empty inputs, empty results, or 
input checks that can fail.


> I just couldn't spot the one letter wrong I'm sure you must remember
> how as a student lines tended to "blurr"...

Sure.

Among the (language-independent) lessons I have learned from making many 
mistakes of similar triviality are these:

1. Always document (with comments) the purpose (role) of every variable, 
constant, parameter, etc. This is so that (a) you think about it, and 
remember it, and (b) anyone reading the code later will understand the 
intent.

2. Never use a variable for more than one purpose.

In this example, your basic error was trying to reuse the op<x>_calcul 
variables for a different purpose. These variables were designed to hold 
the two operands for an operation, and were so named, but you tried to 
reuse one of them for a different purpose: extracting and passing the 
final result. You should have declared a new variable, result: Integer, 
for that different purpose.

Moreover, I suspect that a part of the error may have been a copy-paste 
of a "Depiler" call without paying attention to editing the pasted copy.

So, more rules I have learned:

3. Treat every copy-paste of code with extreme suspicion. Avoid being 
interrupted by anything before you have finished adjusting the pasted 
copy to its new role. One method is to start by making the pasted copy 
syntactically incorrect, for example by inserting !! before it, and only 
removing the !! after you are sure that the pasted text is now adapted 
for its new use.

In one project for some on-board SW for a satellite instrument that I 
worked on a few decades ago, we found that a large portion -- I believe 
something over one-half -- of the bugs found in unit test were caused by 
such omitted or incomplete editing of copy-pasted code.

The problem is that unedited copy-pasted code often compiles without 
error, and may look nice and ready, but does not work correctly in its 
new context and role.

4. The "blurring" problem is reduced by adding a blank line between 
statements (but not within a statement).

Finally, note that your design change -- to stack the values instead of 
the references to the original reverse-Polish objects -- was valid and 
worked, good for you.

I wish you better luck with your next program.