Good Coding Habits of a Mobile Development Team

When you are working on a project with a big team, it can get very confusing at times. Not only you have to deal with lots of people with different personality traits, but also with different coding styles.

Coding Habits of a Mobile Development Team

When Coding

Some like to put the curly brackets below the function's name. Others like to use short variable names and yet others get artsy with their comments.

If you are an experienced mobile app programmer and have already worked with either small and/or large software development teams, I'm sure you have dealt with this. I'm not here to teach you how to work on your coding skills, but rather to give you some tips on how I like to code and maybe that will change the way you are coding and add value to your software development team.

The Basics - Be Clear and Readable

Don't treat your code as just something you will read. Even if you do treat like a personal software application project, make it easy for yourself when you come back to that project in a year or two.

My advice for this situation is to make your variable and function names as readable and obvious as possible. For example:

// example A
void getSmth(void *x) {
        // ...
}
// example B
void getUserProfile(User *inUser) {
        // ...
}

Even if you pass this code to a non-developer, I'm pretty sure he will know what the code in example B does. Sometimes, you may get lazy and try to abbrv8 (abbreviate) your functions/variables. Please don't! It could be confusing for others and even for yourself. Save yourself the time from decoding what you wrote one month ago and start by naming things as clear as possible.

Trust me, the compiler won't complain or burn your house if you have a very long function name. Also with code completion, who cares about long names {wink - ;-)  }.

Be Structured - Naming Conventions

Suppose that you have the following class description:

class User {
protected:
        int mID;
        String mFirstName;
        String mLastName;
public:
        int getID();
        String getFirstName();
        String getLastName();
        void setFirstAndLastName(String inFirstName, inLastName);
}

A normal use for this class would be something like this:

User *aUser = new User();
int aUserID = aUser->getID();

Some developers like to add the name of the class to the functions inside the class, like: getUserID()

Again, it's much cleaner to just write getID especially since you are already are inside the User class. Even the variable is called aUser, it's clear you're getting the ID from a user, you do not need to make it even more specific.

Notice the function setFirstAndLastName(), the order of the arguments is reflected in the name of the user. When you write functions that require more than 1 argument, make sure the order of the arguments is clear and also what to expect as an argument.

Especially in a language like C, this is very important in developling software as a team. In Objective-C, it's better because the function name already has the variable names inside the function:

- (void)setFirstName:(NSString*)inFirstName lastName:(NSString*)inLastName;

You may have noticed that I like to prefix my class variables with an "m" and my arguments with an "in". There are no rules for this but let me explain why I choose to do so:

- "m" stands for member, meaning that the variable is a member of the class. This allows me to have separate from local variables. I can very well have a variable name FirstName or firstName, but since it does not have an "m" as prefix, I know it's local and temporary

- "in" is used for incoming arguments, i.e. arguments that are required for the function to function well

- "out" is used for incoming arguments that will be processed inside the function but that will change in value and might get used once this function returns

DRY and Generic

DRY (Don't Repeat Yourself) is something that you need to have in mind when you are coding. If you see some piece of code that is repeated throughout your software or mobile app project, stop and rethink about it. Is there a way you can write it once and then call it whenever you need? Chances are yes.

If the code is repeated in one class, then it's easier just take the pieces of code that are repeated and adapt them so you can reuse that same code again.

However, if the code is used across several classes and all those pieces of repeated code contain very few differences, then you might consider moving them into a singleton class and make that function more generic.

Singleton classes aren't bad, they just get abused a lot. Use singleton classes only if you see no other way to solve your problem. Good examples, of when a singleton class is OK, is when you need to have to store some values in memory that will be used on several parts of your application. You may be thinking of saving them to a file, that's fine if performance is not an issue for your software application. However, keep in mind that reading from memory is faster especially if programming a native mobile app. For example, a manager is quite acceptable to be a singleton class.

Making things generic whenever possible is a great way to prevent repeating yourself. When you write a class or function that can handle different types, it becomes very reusable.

In C you can use templates for that, in other languages you may have to think a bit on how to do this. I usually just figure out which types need to be processed in similar ways and come up with an algorithm that takes care of this.

It takes some time to make things generic, but in the end that's time you will save yourself because you won't need to write something specific.

Final Thoughts

Writing a neat and clean code that your entire software development team requires skill, patience and, yes, even some creativity. Refrain yourself from writing cheap/short variable names simply because you can't come up with a good name.

This process can be very creative and fun too! The following example, feasible in any mobile app soldier game, illustrates:

class BoringEnemy {
         int a;
         int l;
         void shoot();
}
class FunEnemy {
        int amountOfBullets;
        int amountOfLives;
        void attackPlayerWithGun(GunType inGunType);
}

Remember, if you are truly a software programmer, then your job should not be something that's annoying. Have fun with your code, be creative with how you name things, have a challenge in finding a way that will help you a lot while working on your software project and extended mobile app development team ... Enjoy!

About the Author

Jesus De Meyer has a Bachelor in Multimedia and Communication Technology from the PIH University in Kortrijk, Belgium with 15 years of experience developing apps for Mac and more than 5 years in iOS development. He currently works at iTexico as an iOS Developer and in his spare time he works on his own mobile apps.

Oscar Salas

Written by Oscar Salas

Oscar Salas is a B2B Digital Marketing Specialist with 5 years of experience, who has helped organizations to grow and expand through strategic brand development and marketing programs. Analytical thinker, cat lover, he enjoys to play the piano and listening to Led Zeppelin He's currently leading the iTexico Demand Gen strategies.

Explore iTexico, The Nearshore + Company 

Explore The Nearshore Services

Test

Recent Posts