Coding principles, designs, and styles

Overarching Principles

  • Care about quality. Care about code quality, design quality, and user experience. Strive for excellence.
  • Lets build something that we can be truly proud of. A product that gives us a great reputation.
  • Readability and maintainability are of primary importance. Don’t be clever, instead be clear. Don’t be sloppy.
  • Use source-level comments generously to document the design. Comment each class, method, and “logical steps” within methods. What you are striving to document is the “Why?” and “How?” questions.
  • Test early, test often.
  • Thou shall not make hard to use classes/modules. Pull complexity into a class, rather than pushing it onto the user of the class. Make interfaces brain-dead simple to understand and use.

Bread and Butter

  • Strive to make code naturally readable via class, method, and variable names. This is in addition to good commenting.
  • Use a consistent code style within the app. Use the dominant style within a file.
  • Write production quality code. Don’t assume you’ll have time sometime later to clean it up.
  • Don’t check in code that has warnings. Resolve them.
  • Make changes in small incremental steps. When a step is stable/complete, check it in your local git clone. Push the local checkins to the repo when they are production quality — strive for daily pushes. The goal here is to keep everyone in sync, but without breaking things.
  • Add “TODO:” comments to document work that has been temporarily skipped.
  • Don’t duplicate code. If you ever find yourself copying a chunk of code, pasting it and then making a few minor changes. Stop, refactor, and parameterise the differences.
  • Methods should be small. Use this as a general principle, don’t abuse it. It’s fine for a method to be large, if it should be.
  • Never put domain-specific logic within a general purpose class. E.g. you shouldn’t have a general dialog class do something like, “if (fromActivity instanceOf BooActivity) {}”.
  • Strive to use the “Locality Principle” — group related code (classes, methods, blocks within methods, and variables) together. This also applies to delegate/call-back interfaces. It is better to use anonymous classes (declared at the point of use) rather than declaring the interface in the class definition — don’t do this: public class FooActivity extends BaseActivity implements VerticalPager.OnScrollListener.

This or That, But Let’s Do It This Way

  • Use 4 spaces rather than tabs.
  • Use whitespace and comments to make “logical steps” stand out. In the same vain, put scope brackets “{“, “}” on their own lines. Vertical whitespace is not your enemy.
  • use camelCase for variable and method names. “Upper camelCase” for Class names. Lowercase for package names.
  • Start member variables with an “m” — mMemberVariable.
  • Start static variables with an “s” — sStaticVariable.
  • Use scope brackets even for single line ifs, for-loops, while-loops, etc. Its just too easy to mess up the scoping of these statements. The brackets also make the blocks stand out better.




Founder @FrontierWallet, Smart Contract Developer, Full Stack Mobile Developer, Speaker, Open source junkie

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ravindra Kumar

Ravindra Kumar

Founder @FrontierWallet, Smart Contract Developer, Full Stack Mobile Developer, Speaker, Open source junkie

More from Medium

4 Reasons Why You Need to Build Universal Android Apps

A tablet, foldable device, and a phone sitting on a desk.

Google code scanner API — scanning codes without camera permission

Demystifying the Associate Android Developer Certification

Meet Microsoft Snippet — an Android Library for Measuring Code Execution Time