If you are in this state, I would argue writting java doc comments while developing else no one will be able to make sense of the code written

anand raman

Most of the people I met insisted me, not to concentrate much on the comments. Their motto always “First think about the code, its very important.We can end up, writing comments, once code gets a good nod from clients“.

Even, writing good comments is not an easy work. Any one can write some nasty stuff, in hurry at the end of the day. But writing comments, which is clean, clear and related to the code is a perfectionist task.

Lesson Learnt::
Spare amount of time, in commenting code. When ever you make chages, make changes to comments. And see, if there is a chance to spruce it up all again.

   I’ve come across all the above types of comments and I’m guilty of some of those :-(

    What I’ve seen in some groups is the developer is allowed to check-in with any of these BUT we also have a review for every check-in. So the developer knows someone is going to review the code fairly closely — that keeps most people honest!

BR,
~A

Working code has value in and of itself, even if it isn’t perfect. By committing the code, you allow other people to use it and build on top of it.

Furthermore, not all refactoring exercises work. Sometimes people make mistakes. By committing the code, you get a point to reverse back to without any fear.

Finally: I would argue that you should commit regularly, not just when a block of work is “finished”.

In my experience, mixing refactoring with implementing new features nearly always results in confusion, broken builds, etc. I’d much rather the refactoring excercise was done either before or after the implementation of a new feature.

My 2c, worth,

Simon