Writing clean code and following the standards

What does "writing clean code" and "following the standards" mean?

You might wonder what does "writing clean code" mean, well it means that as a programmer you write code that can be easy to read, understand, modify and test. Also what I mean by "following the standards" is that we should learn and apply the rules and conventions of a programming language, team and community.

For example Oracle offers the coding conventions for Java or Microsoft offers the coding conventions for C#. Another example would be that if you would like to contribute for developing a framework like Symfony2 you must also follow its conding standards.

Why should we write clean code and follow the standards?

In our days most of the real world applications need continuous development and even small programs require to be changed or improved after a while. Sometimes we often share pieces of code or entire applications to help others. Also from time to time we need to update or fix code we wrote a long time ago. As a result of all this we often spend our time reading code, understand what does it do and we will be required to modify it. That is why writing clean code will help us to deliver quality code which others can understand and can update it to their needs, we will be able to fix bugs and add new features or update the code faster.

Examples of why it's important to write clean code

Nowadays applications get bigger and are used by a lot of users everyday, many of them offer a lot of features and rarely you are the only programmer working on an application, often you will work in a team or even sometimes several teams work on an application, each working at one of its module. You will often need to read and fix a piece of code wrote by one of the other team members which is in vacation, imagine how hard it would be if the code would have been written in chaotically? Maybe you would think that it would have been faster to rewrite the whole thing again? But no investor is willing to pay you to rewrite a piece of functionality again, maybe you would not write it better than the previous team member. Now imagine how easy it would be for you to change the code if it was written clean and easy to understand, even more it was written by following the coding style and standards on which the team agreed at the beginning of the project? It would be a lot easier and you would not need to suffer just because you need to do a bug fix.

Another example of why we should write clean code and follow the standards which I've experienced was that I was assigned a job to update a relative small PHP script designed for interacting with twitter, even if I am experienced with PHP I was unable to understand what did the code do because the code was written chaotically, half of its naming was in the native language of the previous programmer, it was not in English which is the common language used for naming variables, methods, classes, folders etc. The files had between five hundred and one thousand lines of code, variables were not suggestive(at least ones which were named in English). It would have been easy for me to update the script if it was written clean, had meaningful names, if it had been divided logically into modules.

Resources

There are a lot of resources out there which will help you start writing clean code, one of my favorites is a book called Clean Code: A Handbook of Agile Software Craftsmanship written by Robert C. Martin in who is a promoter of writing clean code. 

For following the standards of a programming language in which you write code you should consult the official coding conventions, also if you use a framework you should check out what is the standard coding style on top of which it was built, in general it should be the same of it's related programming language. Besides that a framework often has a standard way to organize classes and other resources, this is one of the many advantages of using a framework, that other programmers can understand the code easier.

Important rules when writing tests for your application

Today I want to share some of the most important rules I follow when writing tests for an application. These are some rules I found useful to follow so that tests remain a part of my job which improves on the long term the quality of the code I deliver and makes my life easier. In my opinion same rules apply whether you are doing test driven development or just writing tests after you completed a feature, of course that its preferable to do test driven development as it brings more value to your code quality and your application.

1. Tests should be small! What does this mean? Well tests should be easy to read, easy to understand and the test should not have hundreds of lines of code. When writing tests you should follow the same rules as you do when writing clean code. Often after several days, weeks, months or even a year you will need to update a feature, which means the tests should be updated, but how will you update the test if it was written such that you cant understand it?
2. As you might know there are functional tests and unit tests, the purpose of a test should be to verify that a single functionality works in case of functional tests and in case of unit tests the purpose should be to verify that a method has the expected behavior which can be to return a result or to modify the state of an object.
3. Tests should be independent from each other! One or more tests should not fail because one other test fails. If a test failed it should be because the feature or the method has some issues in its implementation. Also the order of running the tests should not matter, running the tests should output the same result. An example of dependent tests is when first test creates a user and tests if it was saved in the database and then the second tests uses that saved user from database to test the login functionality.
4. Tests should be independent of the existing data in your database. What I mean by that is that as long as the database schema is the same every time you run your tests the same output should appear. For example you cant suppose when you test a login feature that the same username and password will exist in your database. In your test you should always either use mock objects or insert a user in the database, test login and then remove the user from database. Of course that most of the time its preferable to use mock objects instead of using the database. Same applies for resources used by the application, resources like log files or just simple files in which you store information. Usually when you have a really small application its not worth to use a database and you can use a text file to store information, so when writing a test make sure that in that test you also create a mock text file and delete it after your asserts finished.
5. Its very important how fast your tests are. It's a waste of time to wait dozens of minutes to run all tests for your application each time you finished a feature, sometimes you will need to run tests after each couple of minutes of writing code. I have seen very big applications(put in production but continuously improved during several years) for which running tests takes even few hours on a a high performance machine. In general to make your tests faster you can decouple your application from the database and use mock objects in your tests and you can not test the GUI of an application each time but that would mean that the "view" part of your application has very small amount of logic, which is a good practice. See how testing an application helps us to write better code? 

There a lot of other rules I might have missed, but consider this just a starting point!

Maintainability of the code by constant refactoring and unit testing

How often, as a programmer, you delivered new features in the beginning of the project so fast that clients could not believe it, but later, when the project got bigger, the number of lines of code grew and the number of features became larger, you started delivering features very slow? Often that was because the bad architecture of the application but mostly it was because the ugly code you were writing!

What did you do next? Well I suppose that you tried to refactor the code but you might have not succeeded because you were scared that you would introduce bugs. But keeping the code as it is wouldnt be a solution because as you know code rots as time passes, the code becomes uglier and uglier with every new feature or small change if you do not clean it. The solution would be to have unit tests, right?
If there would be tests and you would not be scared to do the refactoring of the code. But then you would need to convince your clients to spend money on refactoring working code. Most of them will not understand that refactoring will mean less money and less time spent on the long run.

I think that the best solution to this situation would be that whenever you work on a new feature or change an existing one because requirements change you should always leave the code cleaner that it was before. When see a piece of ugly written code apply one of the appropriate refactoring pattern without being scared that you might break the behaviour of the application because you are backed up by your unit tests.

Following this rule "leaving code cleaner that it was before you started working on it" and having unit tests will help you have a constant delivering time of new features, no delays because of the complexity of existing code, no bugs introduced by small changes and it will make you happier while working because you know you are delivering high quality software.

Top 3 Web Design Teaching Tips

Top 3 Web Design Teaching Tips

Thanks Stefan Mischook!