Commenting is a bug bear of mine as I suppose it is with every developer that does comment their code but has to trail through other’s code to work out what’s going on/wrong.
Funnily enough the statistics tend to be that those who comment write ‘better’ (whatever better is) code. My personal belief is that this has very little to do with the skill of the developer but if the code you are writing is coherant enough that consise and to the point comments can be ADDED IN AS YOU GO ALONG! as apposed to code being so complex that you need to write code to explain your code and you take this approach as a coding guideline then you can look at somthing and think… “that just doesnt make sense” and you can re-write it, if you cant comment somthing in one or two lines of comments then perhaps it needs breaking up into explainable chunks. Also if your not commenting at all then what about somone who perhaps isnt at ou level coming along.. are they going to understand your code.
Alot of developers go with the saying “well It’s self explanitory” and while that might be true for the developer writing it for another developer to come along and look at the code out of context and just as a bug to be fixed… well its painful.
As well as it being painful its not helpful.. good fully commented code is a valuable learning resource, you can explain why you did somthing and this will help more junior coders in there journey… ofcourse if you cant explain what your doing then you shouldn’t be doing it.
Coding, Unit testing, code coverage and metrics are topics that get over looked way to often, development in general but especially web development has become less about writing good code and more about writing somthing that works.. for me this isnt acceptable. And whats more, its costly for the agency/company/software house you work for in the long run. If you encourage developers to write untested and below their par code then you can expect nothing less then for it to fail at some point down the line.
Systems change and since the 80′s people have been coming up with design patterns and coding standards to make the transitions easier and less risky.. its time that your bosses understood this. Change requests/tickets/bug fixes are costly for everyone involved but they can be reduced/minimised and in some cases eradicated.
