Not so long time ago I was asked if I could write an article on our company blog. My first thoughts were about Inversion of Control (sorry lads, you will have to wait for this :)), especially building own container, but then I heard some people talking about how messy can be projects they are assigned in. Today I am going to analyze why do we sometimes write code that we should be ashamed of and what can be done to improve the quality of our work.

Road to ruin
There are many ways to create successful projects. There are even more possibilities to mess them up. I do believe it is because many of us do not care enough for the code we create. However, we have to take responsibility for our actions. Some time ago, I have read that our job is mostly reading the code, only a small portion of it is writing code and now I can say it is so true for all of us.

Skills
Of course, some of us really care, some of us want to make a difference but they don’t know how. When I started my first work, I could barely write a loop in C#, I had no idea about built-in methods, functionalities, structures, etc. But I was employed anyway. Then the real work started – for my colleagues and me. That’s the point – one cannot go further at the beginning of the career without any help, without guidance, without someone who cares. I was lucky, they helped me to start and even longer since our ways parted I look back to the first dropped database (hopefully that was not the production one :)), long time spent optimizing SQL, solving problems together with the use of the flip chart. So we have the first point:

Good programmer cares not only for the code but also for colleagues.

How can we write nasty code if we have in mind that someone would have to cope with it, lost probably hours to deduce what is going on?

Personally, I reckon that programmer should be “lazy”. We have to write the simplest (and as well most concise code) we can. There is no point in wasting our time on writing tangled, barely readable code, so we go to conclusion number two:

Good programmer follows KISS principle (Keep it simple, stupid).

We also have to be able to listen to other programmers. Don’t think you can write the best code in the universe. A good practice is to review the code of others and let our code to be reviewed.

Good programmer listens to others and learns from others.

Some time ago, we have created Xamarin project with the use of PCL (Portable Class Library). In the meantime, a new version of Xamarin arrived, in which the PCL approach was obsolete. For the sake of other projects we could stick to what we know, but we, as a team decided to follow the trends, to go further.

Good programmer never ever gives up on learning.

I could write more (actually in the company we have so-called Manifesto of Good Programmer), but that’s not a point of this article. I hope you survived this rather lengthy preface, so let’s get to the real work :)

“I have to maintain a stable code. Now what?”
Oh, don’t panic, I will give you a piece of advice how to bear with this unpleasant situation.

1. Make sure you know how to compile and deploy the project. The instruction should be written in the readme file (hopefully). Also, check if the technology isn’t ancient or not supported.

2. Look for any unit tests. Any existence of unit tests can indicate batter condition of core code. You have to check if those tests are actually testing anything.

3. Look for used project patterns. In a good project, there should be any, especially Inversion of Control is the most basic one. In the poorly written code there would be none or plenty of them which can mess things up.

4. How many comments can you see? Optimally, they are only in places that are not obvious. Are they constructive or are you spammed with them? Remember, comments should be written in universal language for developers – English.

5. Another point concerning comments. Do you have in project commented out code? That should never happen (mostly), period!

6. Can you see any naming convention in the project?

7. Can you see any variables and methods naming rules violation?

8. Is the project organized properly into separate layers?

9. Look for the unused code.

10. Check if there are classes containing a high number of lines. Seeing class with over 1000 line should make you cautious.

11. Is project versioned in version control system? It can help you revert destructive changes in the future.

12. Check if the code is encapsulated correctly.

13. Check if there are deeply nested loops and if conditions.

14. Is there repetitive (redundant) code?

Of course, I could write more and more guidelines for project examination. By far we should know if the project is tough to maintain. Now let’s consider if you can do anything about it.

If the mission is refactoring, remove commented out code in first place. Be cautious though as in many situations there are hardcoded endpoints (mark them with another, appropriate comment).

 

And now a critical step. Make a commit to repository! Next you should consider unused code. Carefully find all occurrences and delete them, test often and early, compile early and often, test application every time you can. Commit small portions of code so it can be easily reverted. Now you should have no commented out code, and most of the unused code removed.

It’s the highest time to check and write unit tests. Write as many as it is possible, be precise, test everything. Refactor tests if it is necessary. At the end, you should have most of the code tested. Sometimes the structure of the whole project is so weak that testing everything is not possible. Try to test everything you can.

 

Now, with unit tests, you can refactor application code. Fear not to change variable names, reorganize code, method names, simplify conditions, loops, split code into separate methods. You can do anything as long as you see green color near your unit tests. Try not to touch anything which is untested (well you can refactor variable names, as it does not change application logic). Remember, stick to naming conventions.

 

Next step in our journey is architectural refactoring. Create interfaces, abstract layers, use dependency injection (if it’s not used already). Test everything manually, write more tests, refactor and so on. Now at the end of the day (or month :)) you should see nicer, better, ordered and paradoxically shorter code.

Conclusion
I hope you enjoyed this brief article in which I tried to include general guidelines to identify and fix problems with application. In my next article, I will provide you with more detailed information with code examples in C# concerning concrete code changes which can improve application readability and performance. See you soon! :)

SEE ALSO

Dependency Injection in C# - how to make it?

How to use Bluetooth LE to control robot via smartphone so you can make your own army take over the world.

Uncle Ben In A Nutshell - Clean Code Principles in C#