Code: Keep It Simple

“Code”, sounds complicated. Now what on earth have possessed me to title article about code, “Keep it Simple”. Well, there is a small story about it. I will you tell you that.

About 10 years ago when I was introduced to programming, It was mainly about theory, of how things work then small programs. Then there came some more details about writing good code use concept of object oriented programming, moving forward we learned a lot about machine, scheduling, networking, hardware optimisation, project management, different kind of code terminology etc. And basics of programing just got burried into too much information. After graduating from college when we came to real world of code, we were all so confused with half cooked knowledge of everything about computer science.

Industry is greate place to learn, we are always on clock, have deadlines. Small firms let you learn so many things and you get to know about some good technology and get a lot of exposure to projects, both of small and big scale so then as a trainee, you have all the guidance, resources and time (best of all resources) at your disposal to learn the nuance of the code and start producing the better code. But how many of us do that?

While training we are mainly building relationships and settling ourselves to the environment. And then we get some serious work, with “Deadline”. Now that deadline never let us to write the clean code, we are mainly focused to complete work on time. Or else this is what we say to ourselves to make us feel good.

As a programmer during starting days of our project development we are mainly focused on being easy our self and creating some structure from where we are suppose to build a great project. During my study days I checked this figure which actually depicts timeline and work done:

As you can check after 50% of time have passed then real work starts which remain on same pace till 80-85% of the time which is active development time. Now since this is the study and programmers are furiously coding the project’s 65% in around 30% of total allotted time, that is why having complex code is obvious.

Now this code complexity cost firms dearly as, (Quoting Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003) “40%–80% of the lifetime cost of a piece of software goes to maintenance”. And as also stated “Hardly any software is maintained for its whole life by the original author”. Even if that was the case still, if you have coded 60% of project in 30% of time, you are unlikely to remember, why and what of your logics. That is why as programmer you must keep your code simple, by all means, which may include:

• Documentation
• Regressive refactoring of code, logic, algorithm
• Commenting, mostly when there is nesting loops or some if else ladder, or if you like it fancy then nested bitwise operators
• Commenting whenever you feel like
• Commenting To describe a class, or a functions, if you think you others will need it
• And most of all, make sure to comment before or inline. Never comment after.

Now that was really basic. So, that does not at all, justify the title of the article. We all know that. We have learned hard way, as after 3 months we mostly forget the flow of our code, then we realize the value of commenting and all. So what is the real deal. To give a hint I am sharing this tweet by Jeff Atwood, one of my favorite blogger, and founding member of stackoverflow.com. 

My point is and always have been about coding complexities. To state this point even more clearly I have another story. Are you ready? Of-course you are not, I will tell that anyway.

After working with objective C for quiet a long time I switched to Swift lately. I started with Swift 3.0 (yeah, I know I am lucky). And this language have a vibe, it make you a better programmer. I know what you Java guys are thinking, “We have this vibe, like from, forever”. Yeah, right! So, after working with swift for about 3-4 months, we were going to start this project. I decided to go “all OOPS” on this one, and created a like a zillion classes, extensions, protocols. There were multiple level of inheritance, so many overridden functions, and no shared variables. Things are happy and Implementation is quick. But any new programmer with little less experience, who tries to understand this code, mostly give up or take a lot of time.

Then there come this question how can we overcome this trouble. We can’t. But good documentation, proper referencing, will help us anyway. As one day, with experience they'll get it. Thus to keep it simple, all you can do is following things:

• Create a class hierarchy architecture document. This should clearly state the your class tree, describing parent, and all their child, mentioning all private and public member and their usage definition. Make sure to keep on updating it with each refractor you perform on your code. This will give programmers a clear idea what they are going to deal with.
• Create model classes for accessing persistence storage, or server data. Not just that but, properly and clearly state the relationship among the data model classes. And give a every small detail about managers that are actually dealing with data models. With object graphs we do that, but even when using relational database keep this in practice.
• Take ownership of your code, Every component (variables, functions, classes) which you don’t want to be tempered, keep them private, or use access moderation keywords to define their scope. Lock the files you think should not be changed later. If under some circumstances that is not possible clearly state, that the one who change this, will be responsible for any trouble caused.
• Use git and Commit Frequently, this is for your own good. And will help others as well. Sometimes when a team is working on your project the frequently you commit the safe you are at all front. In case of any trouble, you are only last commit behind the schedule.
• Group files where they belong, and by doing that you will save at-least an hour a day. Yours as well as a month of others*.
• Have coding conventions and force them into implementation, nobody wanna follow protocols, specially programmer, they are creative creature and after a year of development they start to believe that their way is the best way. So if you can catch them early and train them for it, or if experienced force on them. If they have better suggestions then include it in your conventions and force that on everyone else. Just that simple.
• Have a practice of code review, this will give programmers a sense of responsibility, and sincerity that their code can be reviewed by the girl he have crush on. Which is definitely a motivation to write clean code.

That will be all I guess.

_________________________________________________________

*Conditions applied.