> code should be self-documenting Which is a myth. Try to come back to code five years and three languages later and see how self-documenting it is. It isn't

> code should be self-documenting Which is a myth. Try to come back to code five years and three languages later and see how self-documenting it is. It isn't. I could maybe --possibly-- stretch disbelief and accept that if someone works with one language and one platform for a long time the code will be self documenting to that person or that team. This is not the case for multi-technology projects with generations of people touching the code base. I'll give you a very concrete example. About fifteen years ago we spent three months authoring a tool in Visual Basic for Applications (VBA). This tool was used to automate certain aspects of the EDA (electronics design software) tool we were using at the time. The custom software was needed in order to vastly improve productivity with 1,000+ pin chips. The VBA tool effectively linked Excel with PCAD and reduced a twelve hour task to less than an hour. Well, I have not touched VBA in probably fifteen years. The code is full of comments about the very things I described in my prior post: intent, design, thoughts, ideas, enhancements, problems, etc. After fifteen years of not touching the language or the application I can jump into that code base and be up and running within not much more than an hour. It is hard to place a number on the value this adds to a project. It is nothing less than huge when it comes to supporting, maintaining, migrating and enhancing it. > "x+=5; //add 5 to x" Clearly the domain of morons.