A loose collection of development guidelines that I apply to my day to day work. Will be updated continuously.

Apply code cleanups

Code formatting applied - Code is auto-formatted by using the project's formatter to avoid formatting related changes polluting the changeset. This includes using Eclipse Save Actions such as organizing imports.

Commits include tests

Commits are backed by tests - Every commit includes test cases to verify the change fixing an issue or the code working generally. This ensures we continuously improve the code coverage even if the original codebase is not exhaustively covered by tests.

Commit refs ticktet

Every commit is referencing a ticket - To give a change a broader context every change to the code base refers to a ticket in either JIRA or the GitHub bug tracker. This allows traceability and a quick zoom in or out in terms of high level requirements and low level necessary code changes.

Linear history

Keep version history linear - I am trying to avoid merge commits as much as possible as they usually introduce noise into the code history. I usually merge pull requests using the following pattern:

git checkout -b ${ticketId}
curl ${pullRequestUrl}.patch | git am --ignore-whitespace - Pulls commits into the feature branch
git rebase -i ${base-sha1} - Squash commits into one
Polish commit, apply formatting etc.
git checkout master
git merge ${ticketId}
git push origin master

This assures we stick to the single commit rule and preserve authorship of the original author.

Single commit

Strive for a single commit per ticket - As aticket forms a unit of work I strive for a single commit to fix or implement a ticket. In case I know the ticket is a bigger one I might create a feature-branch for that ticket and sum up commits on that one. Before merging the commits back into the main line I can then squash them into a single commit so that I end up with the rule applied in my main code line.

Consistent commit message

Use a consistent structure for commit comments - I generally use the following pattern:

${ticketId} - ${summary}

${details}

Keeping the ticket id in the summary line allows quickly finding out about the ticket that describes the requirements for the change on a high level. I don't necessarily manually line-break the details section and also prefer completeness of the summary line over sticking with the 80 character limit.