Most of us write code in at least three or four languages which could result in many coding styles to follow. Refactoring code is a way to really learn what counts for readability and what doesn’t. I found myself following couple of rules refactoring both my own and others code, making it more readable. I’d repeatedly do this

1. Group variable declarations at beginning of block
2. One statement / line
3. New line spacing between blocks of code

When reading the code you can then skip the declaration part, usually nothing interesting happens there. The short one line statements and new line separated blocks of code are way easily read and understood.

Don’t forget the +1 rule

Have fun!

• When something changes – see the Timeline
• What changed within file[s] – see the Changeset
• What is the issue – read the Ticket description

So what’s left for the commit message? well this is what I think

“One sentence; describing your action in relation to the Ticket description.”

Let’s break it down

“One sentence” – means that you should keep your changes really small. If you feel the need to write more than one sentence. Split the commit into two.

“describe your action in relation to the Ticket description” – this one is important; only say which part of the described issue you have addressed. Unless the ticket is design or refactoring related one, no reference to code changes should be made. This information is already available in the changeset.