Charles Yeomans wrote: > I agree that having to expend time to figure out what each line of > code does is a waste. My approach, however, is to write code > whose intent is clear. Adding comment that explains what the code > does is, in my opinion, unnecessary duplication. Such comments > require one to keep comments and code in sync. I suppose this > means that I'm one of those people that does not comment code.
Code is for compilers, comments are for humans. Code is optimized for the compiler to consume and produce object code. Comments and readability are for humans to understand what is going on. Therefore it is a fallacy that you can write code whose intent is so clear that other people can easily understand it. The reason you lean on this logic is because it seems clear to you and you assume everybody thinks like you and therefore you blind yourself with this logic. Code and comments serve two different purposes, so it is impossible for it to be an unnecessary duplication. Norman Palardy wrote: > But, having done a lot of maintenance work for the first 6 years > of my programming life, the code IS the design and comments can > often be misleading as can poorly named routines and variables. > Never rely on comments as a definitive statement about anything to > do with code. This is invalid logic. Poorly maintained code is a hassle to read, but code that has been properly maintained is a joy to read. The sentiment here is not if you can trust the code comments, but that programmers should properly maintain all aspects of their code so that you can trust it. See the difference? If your a manager of a software development team and your developers are producing code that is unmaintainable, whose fault is that? You just bought a one way ticket to the code from hell. It will come back and bite you. Another thing people tend to confuse is code and design. Code is not design, but code is the result/implementation of the design. The design can be formal as a written document or just an overall thought in your head, but code flows from the design and not the other way around. What I am seeing in general here is typical self justification for lack attention to detail. The reason programmers don't want comment there code or put DIM statements in one place or whatever else to make it more readable for the next person who comes along is because they are self centered. They have invested mental effort into their position and don't care to change because they simply don't see how it affects others down the road. If you don't care about the next person who uses your code, then what's the point in changing your ways? Any wonder why the software development industry is such mess in terms of maintainability. Programmers and managers need to take responsibility for what they produce and hold themselves to a much higher standard, otherwise it will cost you money. In all my years of development I have never heard anyone give unsolicited praise to someone else for how well they didn't comment their code and how unreadable it was. I have on the other hand have received unsolicited praise for how readable and professional what I had written was on several occasions. So based on results, I must be doing something right and you should consider that. Just because everyone else writes crappy unmaintainable code doesn't mean you have to. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
