General Discussion  - 
Brief commentary on this line from software documentation:

"The code was simplified in 2003 and is harder to understand."
Solomon Eraut's profile photo
Write the easiest to understand thing that obviously does what it's supposed to do. If you write a tricky version of a function, because the easy one goes too slow or consumes too much memory when used at full scale, keep the one that you know works in the code too. Then you can switch between versions of the function or use them at the same time, to test whether it's really an improvement and whether it really does the same thing.

Only if you change the intended result of a function from what the easiest version produces should you delete it, and even then it might be better to update the easiest version instead, because it can also be a kind of documentation for instruction of maintainers (including your future self) and a double check for correctness (by using it in testing, and by the ideas that come up when looking at different ways of doing the same thing.)

For instance, I took a routine that was calculating the sine function repeatedly for a waveform and wrote an optimized version that just calculates one sample step then produces the rest by complex multiplication. Testing them running at the same time and subtracting the results from each other produced a sound that represented the inaccuracy of the optimization. Without that testing, I wouldn't have got the optimization right. Then after correcting the optimization, I multiplied the result of the subtraction by 10 trillion times and heard an interesting sound which was the inaccuracy of double precision floating point complex multiplication.
+Erik Poupaert  So that's what unit testing means? I have to break whole programs down into modular pieces, using "interface" in Java for example, then write test modules that simulate the other parts calling the part to be tested, in each of its versions, with realistic data and sometimes extreme data? It seems like there's a point where programs are small and simple enough, less than 200 lines or so, where the program should contain enough assertions or checks or redundant functions to test itself while running normally without needing a whole "test bench" of simulation modules, which would make the program more complicated. Despite it seeming like that, I'm thinking of some errors I've seen where writing a unit test for a function of less than 20 lines would have proved it had blunders in it, such as a function for summing up some test scores and determining whether the score is over the minimum percentage for passing to the next level in a game. If some programmers can't even get that right, then how are they supposed to write unit tests that are correct?
Add a comment...