One of the signs of a good development team is how quickly a new developer can get up and running. By that we mean; set up their environment and start contributing acceptable code quickly.
One way to achieve this is to simplify and automate - this was touched on in our last post Evolving the Dev Process : Part 1 Why Continuous Integration?.
This next post touches on the second half of that statement; ‘how quickly can a developer start contributing good code quickly?’.
Now, Imagine for a moment you were plonked into a brand new job tomorrow (they offer a good pension and other perks, don't worry). You have a fresh machine and environment set up for you.
What would be the first things you would want to know? Well let's hazard a guess:
It’s a quick win to set code style expectations. It will take a developer probably just a few hours to throw together a good code style guide: brackets, naming conventions, logging etc.
At Brightec we follow the conventions used by the Google Android team, check out their style guide. (The only part we don’t follow is prefixing variable names, it seems a little ugly and unreadable).
Getting developers to adhere to consistent formatting is easy:
Overall styling is largely down to personal taste and readability, but it’s essential to ensure consistency throughout a team and should probably be set by the lead developer.
Here are a few of our guidelines that we use in addition to the Google Android guidelines. These will probably seem familiar to you:
Don't miss the first post in this series: Why Continuous Integration?.
This article was originally written for Brightec by Seren Matthews
Search over 400 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!