Tips and guidelines for coding program

Commit Messages

Make sure you put a commit message which makes sense. It is true that a good commit message might be difficult to come up with, but please avoid messages like “Fixed bug” or “Rendering”. Which bug did you fix? What is the bug number? What is the bug about? What rendering? What did you do with rendering? Did you fix it? Did you add rendering capability? Did you remove rendering capability?
It is a good practice to add a line of commit message title, followed by a single blank line and then an optional detailed description of the change which might not be obvious. If you made a commit which alters the working or behavior of the component, you might want to explain why you took that decision in the description section of the commit message

Check In Early, Check In Often

Jeff Atwood has an excellent post on this recommendation. My personal motto is to check-in when I am done for the day and pull in the changes when I start working for the day. I have a friend whose motto was “Every morning, you wake up and do ‘svn up’, even if you haven’t brushed your teeth”.

Keep the change-set manageable

Avoid any such scenario where your commit diff is 2000 lines unless you are nuking a component or any special scenarios. If the component you are working on enters the source tree in a single commit with 4000 lines of diff after 5 days, then STOP. THINK. Is this really the correct way? Can you do it in a better way?
If your single diff contains truck load of different features with 25 files affected, then it is a exercise in frustration for anyone who is attempting to review it. Try breaking it down such that you are able to follow“Check In Early, Check In Often”.

Learning to resolve merge conflicts

It isn’t always easy to fix it, but don’t forget that merge conflicts do happen and you will need to deal with it even if you collaborate on a piece of software in a very smart manner.

Get your code reviewed

No one’s code is perfect. At times, we are insecure of our coding abilities and become overly protective of our code quality.
Even if you don’t have a better programmer around, get it reviewed by your peers whom you consider at par with you.
Try reviewing code, that helps too – you learn better ways of implementing features and ideas.
If someone criticizes your code, resist from taking it personally. Usually the person criticizing your code has got nothing against you.

Start Questioning

You don’t need to catch your team lead by the neck and demand the answer for choosing this method. Question yourself! Think over it. Try again!
A spark of inquisitiveness goes a long way.