Quote:
Originally Posted by user_none
So you're saying write the code twice. Instead of reading pseudo code just read the code. All you're doing by writing pseudo code (other than writing the same thing twice) is writing code for someone who doesn't understand C++.
|
You really respond as a programmer (no pun intended): I've seen these kinds of reactions many times. The thing is: pseudo code should be context / implementation free and just grasp the intention of program, in other words: what must it do. It should be left to the developer how to practically realize that and also select a certain language which is best suited for that job.
Many applications (and believe me also many commercial apps you do not want to know) just "grow" organically without ever have established some kind of "vision" document to explain why it is as it is and how things are originally where supposed to work together.
Regarding ADA: the language was not bad, but most important DoD also gave us an accompanying documentation standard (Mil-2167A, now Mil-498) to be completed and approved mandatory before being allowed to start to program. There is/was a reason for this. Think many employees, many subco's, many third parties, many requirements changes, maintainability over many years, and you get the picture.
Further developers where and are just afraid for documenting: hé, I think with my keyboard, my programs are self-descripting, yeah, right, keep on dreaming.
What can we learn from this? It always pays to document at least the main features. Documents do not have to be that big: 1 sheet often fills the bill as long as it is to the point and up-dated to reflect the current status. Skipping docs is penny wise/pound foolish as many managers will find over and over again, but then: that problem is for their successors. Time to move on.
Just my 2cts.