Code Style expectations

Last Updated: 17 Aug 2023

How quickly can a developer start contributing good code?

Signs of a good development team

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?’.

Your new job

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:

What kind of code style are they expecting?
What kind of code standard are they expecting? (We’ll outline this further in the next post - 'Evolving the Dev Process: Part 3 Code Standards’).
Which branch do I use? (Wait for part 4 of the series for us to unpack this question further)

Code Style expectations

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:

You can enforce android formatting in eclipse and intellij/ android studio using these formatting settings. (To install in eclipse, Preferences -> Java -> Code style -> Formatter)
Set the android import order using these prefs

There is a style check plugin available for Jenkins which can use a pre-commit hook to ensure styling mistakes do not enter the codebase.

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.

Some additional guidelines

Here are a few of our guidelines that we use in addition to the Google Android guidelines. These will probably seem familiar to you:

Log.d should not be committed into master branch
Document everything that is public in a class
Java doc’s should be written in third person
One declaration per line
No space between method name and parentheses
Class names are nowns
Interfaces start with I, IParser

Don't miss the first post in this series: Why Continuous Integration?.

This article was originally written for Brightec by Seren Matthews

Code Style expectations

Signs of a good development team

Your new job

Code Style expectations

Some additional guidelines

Looking for something else?

Want to hear more?

Code Style expectations

Signs of a good development team

Your new job

Code Style expectations

Some additional guidelines

Looking for something else?

Want to hear more?

Or, pick a topic: