Design pattern

To write clean code you should always choose a best practice design pattern, so if you are creating a website you could / should use MVC (Model, View, Controller) and if you are creating a mobile app you could / should use MVVM (Model, View, View Model). If you use a design pattern it will help you to write clean code, because it will force you to structure your software in a certain way. So let us take a look at how you use MVC and MVVM.


The ide behind MVC is to keep, the UI separate from the business logic, you have your model where all your classes will live, the model is the lowest level, the only thing that can interact with the model level is the controller and this is where most of your code will live, and on the top layer you have the view which is the user interface, the ide behind this pattern is that you can easily change the user interface without needing to know the code behind since there should not be any code whatsoever on the view level (although we all know that this is not always possible)


The ide behind MVVM is the same as MVC, to keep the business logic away from the user interface, the big difference is that you no longer have a controller however you have a View Model, you will have a View Model for every View. If we take a look at Xamarin, then the View is even coded in a different language than the rest of the app, the reason for this is that the language used for views in Xamarin which is called XAML; is a very lightweight language which people who has never programmed in their lives, can easily use XAML so you can actually have designers make the user interface without having to know any programming. Making it easy to divided the work load, during app development.



Naming variables and functions / Methods

Name your variables and functions / methods so that they make sense and using camelCase, for example if you create a method to add days to a date, instead of calling it for example add() you could call it addDaysToDate() the same goes for variables, for example if you want a variable to hold someone’s age in days, you could call your variable ageInDays, another thing, you should NEVER write the type in front of the name of a variable, so even though you might think that intAgeInDays is more saying than ageInDays, it makes your code more cluttered and all new IDE’s using a code completion will tell you what type the variable is.

Keep code encapsulated

NEVER EVER use global / public methods and variables unless you really have to. You should always keep your classes / objects self-contained and only accessible through an interface making sure that, anyone using your code will only use it the way that it was intended. And even within the same class you should not use public variables, but instead pass the variables as parameters to the methods that needs to use them. Making your classes self-contained will make it easy to enable and disable your code without risking it breaking the whole program plus it makes it easy to use your class in a future program with ease.


Make your code testable

When writing software you should always write unit test to test you code, I will not go into how to write units and integration tests in this post, that will be a topic for another time, but you should write your methods so they are easy to test, to do this you should keep your methods simple, so that a method only has one clear job with a clear result, what this means is that you should not make generic methods that does a lot of things. For example if you are writing a program for a car, instead of creating one big method called drive() you could write a lot of small methods like turnKey(), putInGear() and so on, writing you methods like this you can easily test the different methods separately, and if all the unit test pass, you can write an integration test to test all of them together.



Do not use comments

Now this one can be hard to take, but writing comments in your code will only add even more lines to your code, so instead of writing a comment you should consider if you code is not written cleanly enough, code should be self-documenting, of course there might be times when there is no way around writing comments, however try to keep it to a minimum, and only use it as a last resort.

Leave a Reply