Code quality

Being mindful of code quality is a desirable trait of every developer. At Infinum, code quality matters. With that in mind, we have come up with a few general rules that every Android developer should follow.

Lint

Lint is a static code checker and is used to indicate suspicious and potentially harmful lines of code that do not follow certain style guidelines.

Lint should always be enabled on release builds. In other words, every build that is given into the hands of our internal QA team or the client must be run through lint and other static code checkers on CI.

For example, you might be working on an older project with outdated codebase. In that case, if static code checkers haven't already been set up, it's expected of you to set them up and create a baseline if necessary. The entire new codebase that's written in the project should pass static code checkers.

Proguard

Every build that's sent to the QA team or clients must be obfuscated with Proguard. In other words, only release builds which have Proguard enabled in the build.gradle file via minifyEnabled flag set to true should be sent.

The only time you should make an exception to this rule is when the QA team or the client asks specifically for an unobfuscated build, in which case you should comply.

Crashlytics

Every build that's uploaded to Infinum Labs should:

If a member of the QA team wants to see API responses and requests, you are supposed to set up Stetho or Chuck for staging builds.

Prince of Versions

We have developed a library that checks for application updates using a configuration fileā€”it's called the Prince of Versions.

Using this library is required on every project, old or new. If you ever stumble upon a project that doesn't have the Prince of Versions set up, you should contact your team lead or project manager and let them know. They should be able to provide you with a few hours to set up the Prince of Versions.

Test what you develop

If you implement a feature, you are required to test it before you send it to the QA team or clients. Once the build has been deployed, it's expected that the app doesn't crash on startup or have similar issues which would suggest that the developer was lazy.

We don't expect deploys of bugless builds, but using common sense and testing what you've implemented should be a part of your everyday routine.

Architecture planning

If ever in doubt about the architecture you're about to implement, it's always a good idea to ask for someone else's opinion on the matter. Having more than one opinion broadens your views and should teach you a couple of things:

Communication is key

There could be situations where you are not completely certain what to do next, or you find yourself in a bit of a loop. If this happens, keep in mind that you have many colleagues who have been in the same situation you're in. Asking for their advice will save you some time, and will probably result in gathering more information and having a clearer perspective on the issue at hand.