Bad habits of programmers

* The other day I came across an interesting note about the bad habits of programmers. Maybe for some it is obvious things, but often you do not pay attention to them.

Our habits are constantly evolving and changing. Changing coding style, the approach to writing code in general. This is usually good, but sometimes this process bypasses some bad habits and they stay with us for a long time. I would like to share some thoughts about some of the “not so good” habits that I have observed in myself and in other people over the years. Some may not even look like bad ones ...

Throw unused code

Sometimes we decide to rewrite some part of the non-working code, or simply want to improve it a bit (many of us strive for perfectionism). Old code is commented and a new one is written instead. This is great, but after the work is finished, the old code must be deleted! If this is not done, the number of such commented out sites will begin to increase, and over time they will become distracting attention from other important parts.
')
For example, once I was approached by one of the clients with a request to add some new features in his existing project. I downloaded the code and found that there are more commented out sections in it than the actual code. It is terribly distracting and makes the code less readable.

Unused functions in your application code are another common problem. Once there was a need for them, but with the development of the project they ceased to be called. Attracting a new developer to the project be sure that he will spend time analyzing them.

You also have a version control system for storing the old code, do not be afraid to delete it! Do it right now!

Overly generalize

Many programmers try to write code that will be able to process everything you feed it, and begin to apply this approach in every project. I created a lot of components, frameworks, my game 3D-engine, in order to understand enough to write abstract code. For 90% of applications, this approach is not necessary.

We think that we will use our code in the future, so we are trying to make it as generalized and abstract as possible. Are you developing your component? How about making sure that it handles 10 situations, even if we only need 2 in the current application?

I have bad news for you. Hardly you will use your code in other projects. You spend your time or the time of your client (for which he pays), creating unnecessary things in the project instead of focusing on what really matters. If you use your class in the second (or even the third) project, then you probably should allocate it as a separate entity. You surely saw this for real projects.

We focus on OOP

I want to note: I am a big fan of OOP, I love this approach , as it is easy to understand and maintain.

But some people tend to create problems for themselves, being too carried away by decomposition (this is similar to the previous point about over-generalization). The project should not increase in proportion to the number of classes you can think of. If you started writing a class that consists of one single function, stop and think - is it really necessary?

Excessive generalization and division into classes can have very bad consequences in the future. Code broken into several classes will be harder to optimize. There may be difficulties with adding new functions ... Always think about the connections between your classes, is there really a need to put this code into a separate class? Maybe it does not make much sense?

“I can do it better”

Each of us has a huge ego. We think that we can write anything and certainly better than anyone else. So, leave your ego at home!

This applies to almost everything we do. If there is a need to work on someone else's project, a quick glance at the code is enough to think “it's terrible! I can do it better! ” Analyzing some component for integration, you can decide "it will be much better if I write it from scratch . "

And again, I have bad news for you: almost any code can look like complete nonsense for someone else, because everyone has different approaches and experiences . The developer, who has been systematically working on the project for months, really knows what deserves attention. Potentially, you can’t estimate it just by taking a quick glance at its code. In fact, there are many examples when the code is really crappy, but it becomes obvious right away (the code from the real project that I was asked to improve, the variable names are changed):

- (void)dealloc { [A release]; [B release]; [A dealloc]; [B dealloc]; A = nil; B = nil; [self release]; [super dealloc]; } 

Almost always you can find good components that allow you to solve tasks, instead of writing your own. And it is always better to use what the community has already tested, instead of creating it from scratch.

Just think for it: how long it will take to write the code, then make sure that everything works as it was intended, and after all realize that you haven't tested something well enough . Development from scratch is useful only for training purposes, but not in a project that needs to be completed in 2 weeks.

And if you do not believe that you can write bad code, just open a project that you wrote a couple of years ago. I am sure that this code will seem to you BAD.

We are afraid of auxiliary tools (write less code)

People resist change. We have habits that we think are right and some effort is needed to get out of the comfort zone and try something new.

Many programmers whom I met, consider that it is bad to use Interface Builder. After the first acquaintance with IB, which I frankly didn’t like, I created UI elements via code for 2 years. But then I overcame my comfort zone and gave him a second chance. During this time, Interface Builder was significantly improved, pleasant things like Storyboard appeared, and it began to turn into an increasingly useful tool. As a result, IB turned out to be useful for me in certain cases and not only for simple interfaces - with its help you can do quite advanced things.

Be pragmatic and choose the most appropriate tool for your work . Sometimes it is better to implement the interface through code (for example, your UITableViewCell for quick drawing), but in most cases Interface Builder perfectly solves the tasks.

Well, in the end, the less code you write, the fewer bugs you will have to catch .

Conclusion

Surely there are still many bad habits that you know about (you can even write a book about it). The examples given here may not be the most obvious, but I came across them quite often when working with different people. And most importantly, if someone makes mistakes, then this does not mean that he is a bad programmer, because each of us has bad habits and the main task is to get rid of them. Look at the code you wrote 3 years ago and say that you like it now.