Keep your workspace tidy and sorted to work fast (Photo by Barn Images on Unsplash)

7 reasons this Android Code Style improves your productivity

At grandcentrix we use the same code style in all Android projects and we love it! We open sourced it so you can use it, too.

We’ve started with the AOSP Java Code Style and tuned it depending on our needs over the last years. Due to official support of Kotlin we knew we have to create a major update. We’ve took the chance and went even further by questioning old decisions in an internal survey and adding long awaited features. The result is a code style 20+ Android developers at grandcentrix agree on. By publishing it to the public you and your team can benefit from it, too!

grandcentrix/AndroidCodeStyle

Why you should definitely try this code style? Let me explain:

1. You finally have a code style

You might ask yourself why you need a code style. When you are used working alone on your apps you don’t have problems with your personal manual code formatting. Discussions start when multiple developers, with multiple opinions, multiple operating systems and multiple screen sizes work on the same code base. If you don’t let a tool format your code, discussions about the formatting may arise or worse, different formatting and sorting increases diffs and can causes completely unnecessary merge conflicts. This will slow down development for no reason.

Discuss problems, not formatting.

Even when working alone it’s unprofessional not to have a common formatting throughout your project. It means your project is not ready to scale to two or more developers.

It’s a good start if you use Android Studios default code formatting. But that’s unsafe! The default settings have changed in the past and will change in the future. Your team should use a code style independent from the IntelliJ version one is working on.

2. Awesome features

What makes this code style different? Here’s a short list of key features we’ve added or kept compared to the AOSP code style. Detailed information about each feature can be found in our Android Code Style repository on GitHub.

• Kept: Hungarian notation in Java (change it if you don’t like it ¯\_(ツ)_/¯)
• Kept: No star imports in Java and Kotlin except for often used testing libs such as Junit, Mockito and AssertJ
• Improved: alphabetical method/field sorting
  - group by visibility
  - public static methods (newInstance()) before constructor
  - lifecycle methods in correct order after constructor
• Added: Keep Getters/Setters together
• Changed: Characters per line increased to 118 (was 100)
• Fix: XML attribute sorting, move android:id to the top

3. Conservative style and updates

Photo by Isabella Jusková on Unsplash

Over the time our Android team requested new rules for the code style. Instead of adding every request we collected them and created a survey about each feature of this code style; existing rules as well as new requests. If most devs agree on we tried to add it. If rules are to specific for a project/framework/library they won’t be added.

This democratic principle makes sure all of our 20+ developers are happy with the code style. Not everyone may agree with all rules, but most developers in our team agree with most rules. Chances are good most members of your team also agree on our code style. Try it!

4. Not Square

From our internal Android Developer Survey

We could have chosen an already existing code style such as Squares Java code style which you might know from various open source projects. This style is different and has some rules we don’t like such as annotations in the same line as the method definition or reducing the indents to 2 spaces.

Those radical style changes compared to the “normal Java style” we are used to did not receive much love by our developers. It’s completely subjective but one of the reasons why we wanted to publish our own code style, reflecting our own opinions.

If you are searching for a code style for your open source library and you don’t like Square ones, here is a possible alternative.

5. No additional tool required

When we talk about code style we have to mention checkstyle. If you’re using it, fine. For us, the Android Studio formatter is enough. Everybody is using Android Studio and it works on all platforms. No additional tool is required which can break and requires maintenance.

6. Easy to install

Even though we’re not using Squares code style we copied their script to copy the code style to all IntelliJ/Android Studio IDEs you have installed by running ./install.sh. Thanks Square Engineering for open sourcing it.

Get started:

• git clone git@github.com:grandcentrix/AndroidCodeStyle.git
• cd AndroidCodeStyle
• ./install.sh
• Restart Android Studio
• Select the code style scheme via Preferences --> Editor --> Code Style

7. Reformat on save

With 3 simple steps you can reorder and reformat your code automatically with ⌘ + S. That shortcut you are used to press constantly although you know Android Studio automatically saves all files for you . Give ⌘ + S a different meaning:

1. Make sure a Java source file has focus (or you can’t record all steps)
2. - Select Edit > Macros > Start Macro Recording
- Select Code > Optimize Imports
- Select Code > Reformat Code
- Select Code > Rearrange Code
- Select File > Save All
- Select Edit > Macros > Stop Macro Recording and give it a name (mine is OptimizeImportsReformatRearrangeSave)
3. Go to Preferences > Keymap
- Find the Macro section
   - Add ⌘ + S shortcut for the new macro

Alternatively you can reformat code with ⌥+⌘+L . When you select parts of your code, only those get reformatted. This doesn’t reorder your code or changes imports. I use it when touching code which doesn’t have a code style.

Try it!

We’d like to know what you think about our code style. Tweet us your honest feedback or open issues in our repository.

grandcentrix/AndroidCodeStyle

Hit me on Twitter for feedback, tips and additional questions!

Pascal Welsch (@passsy) | Twitter