A rule of thumb I follow is that code is twice as hard to read as it is to write so comments may of course help but in the other case comments that have to over

A rule of thumb I follow is that code is twice as hard to read as it is to write so comments may of course help but in the other case comments that have to overly explain what the code is doing or why it's doing it also indicate that the code ought to be revised My process of writing code is to of course code a proof of concept in order to get a feel for the problem domain this could be considered a spike in agile parlance Then the primary and alternate flows can be coded against a basic test suite followed by a refactor and then a comments pass Depending on what comments arise perhaps another refactor may be in order I typically try to follow the spirit of TRUE software