|
Mr Morden wrote:
I've come to an epiphany lately that documentation should not describe how a class works, but rather what it does and why it exists. What and why does not get out of date as quickly as how.
I agree 100%. Except in cases where the code represents an unfamiliar algorithm, i tend to mistrust "how" documentation even when it exists. "Why" documentation can be vital however, especially after the code has been left to rot for a while...
Mr Morden wrote:
A lot of prototypes have become full blown projects, and the existing, crappy code has been retained.
Sadly, this is true. But one of the primary advantages of a prototype is to prove a concept or test an interface without committing the time to it that the full-blown project will require; not to say you should write *bad* code in this situation, but merely that it isn't the priority. IMHO, this is one of the best arguments in favor of using tools to build the prototype that cannot (or will not) be used to build the final application (i.e., using VB/C#/HTML for prototyping, C++ for the project).
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
That is my sentiment exactly.
I also believe that the context in which the application will perform also makes a difference. The way that a redering loop is formatted in a game or a ray-tracing loop is very important for performance. I am willing to give up a little bit of readablility in order to squeeze out a few extra frames-per-second.
However, if you are dealing with a windows user-interface, speed is not as important. I would much rather have a cleaner formatted code to work with.
Build a man a fire, and he will be warm for a day Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|