We Are Mobile First
Here at Mobile First, we pride ourselves on our healthy coding practices. Whilst we encourage experimentation, we also recognise that sometimes it's best to follow our very own tried-and-tested guidelines in order to achieve the best results.
In order to stay platform independent, we look for universal rules to follow and don't allow ourselves to be bogged down with specifics like tab indentation or language features.
We are happy coders and, for us, that means...
When you copy lines of code, you could be copying a mistake (bug), a non-optimal approach, or an external dependency. If the offending code is spread throughout your app, you won't be able to make improvements easily. Reviewing highly repetitive code is also going to give you serious déjà vu!
Always functionize code and inject dependencies/parameters.
Doing too much in one chunk isn’t manageable or maintainable when creating, understanding, testing and bug fixing code. That’s why we use the single responsibility principle. This translates to all levels, from functions to objects, and even to entire apps - such as Facebook Messenger.
Always break down tasks into smaller simpler components, which only have access to the information that they need.
Don't let people get their grubby mitts on your implementation internals! Only expose things that are designed, and have been tested, to be changed. Make sure your implementation has been tested for these changes via unit tests.
View your objects from an outside perspective, does its protocol make sense?
Always use access-level protection, make everything private, and upgrade if needed. Look to define clear protocols.
Global files (named ‘constants’, ‘helpers’ or ‘utils’), with global scoped variables and functions, tend to link unrelated parts of a system - making it difficult to reuse code. Singletons have the same issue. Heavy use of singletons makes it difficult to understand object dependencies - since you will have to inspect the implementation to see how they are used. Unit testing is then difficult as singleton dependencies are hard to mock.
Always favour dependency injection over global scope and singletons. Constants should be held within the scope of the class that they belong to. This makes it clearer as to what objects need to function and, thus, makes the code easier to unit test. Think about the lifetime of your objects, don't have objects hanging around when they don't need to.
Magic numbers and literals make it harder to understand what influence they have on the code. They are non-descriptive and, more often than not, the same value is needed in more than one place so, when you want to adjust the value, there are multiple places it needs to be adjusted...and one is always forgotten!
Parameterize constants / literals and give elements meaningful names.
All of our code is written with the awareness that it will be peer-reviewed.
Clearly lay out code to make it easy to read and understand and use descriptive names so your colleagues can decipher everything. While you’re there, review your own pull requests before adding your peers.
Not following a procedure when using source control can lead to submitting untested code. It can also lead to lost commits and can, in turn, break the build for your peers. Check out our post on how to use the full power of source control and Agile release procedures for more advice!
Follow git Flow: use feature branches, rebase and use pull requests. Create release branches, only allowing for bug fixes, and disallow merges from the dev branch.
Doing the same code over and over gets old fast so we look for helpful patterns in our code. If someone has noticed a pattern before us, why re-invent the wheel?!
Split common code into reusable testable frameworks. Look for existing frameworks, review and contribute to them.
There's often a better way of doing something in hindsight and we embrace this. We believe that re-doing sections of componentized code should be common practice.
Recognise when it's time to refactor. If a piece of code is straying from its original intent, it's better to refactor than to beat it into submission! It may just be a case of renaming it appropriately, but if there's a better way of doing something you should flag it for refactoring. Refactoring is good and it's how the world works. The coding equivalent of the circle of life!
...And that's why we consider ourselves to be happy coders. We encourage you to give it a go and create your own set of guidelines. By implementing similar codes of practice, you could find yourself freeing up a lot more time and energy on future projects.