We evolve and change our habits, probably many times every few years. Your code style changes, your approach to writing code in general.
That’s usually good but sometimes bad habits are introduced into that process and remain with you for long time.
Disclaimer
The wrong habits I’m going to mention are all about extreme cases, so take it with a grain of salt. Remember that each project should have a well thought architecture and what works better for some might be hell for others. I’m all about doing OOP and SRP but as everything it can be abused, remember about KISS principle guys ?.
Leaving unused code
We all sometimes decide to rewrite some part of code because it either doesn’t work or we want to improve it a bit, a lot of us are perfectionist after all. You start by commenting current version and write new code in it place. That’s all fine but you should remove it after you are done with new version. If you don’t it will keep growing, and at some point it’s start to really obscure the important and working things.
eg. I got a request from one of my contracting clients, and he asked me to implement some new features into his codebase. So I downloaded the code and I saw more commented out code that actually working one. It really obscures things and make it less readable.
Other common problem is leaving unused functions in your app, they used to be needed before but now the project has evolved and they are never called, try getting someone new on the project and I guarantee that he will waste time reading them.
You have version control for keeping old code, don’t be afraid to delete it! Do it now!
Over-generalization
Many programmers are taught to write code that can handle anything you throw at it at some point, and they begin to think that way in every application they do. I’ve created a lot of components / frameworks and did my own 3D Game engine so I know quite a lot about doing abstract code. But for 90% of apps that should not be the case.
We as programmers tend to think that we will reuse our code later on, so we try to make it as general / abstract as we can think of. You are doing custom component? How about you make sure it handles 10 use cases even if we only need 2 in our current app ?
**I’ve bad news for you, you barely reuse your older code in other projects. **You are wasting your time or your client time (which he is paying for) doing stuff that’s not needed in the project, instead of focusing on the parts that are important. If you have to write second (or better third) project that uses similar custom class, then I would think about exposing it as separate entity. You already know a few use cases that are usually needed, you have experienced and fixed some pitfalls, it’s tested in real projects.
Object Oriented fixation
Let me state this: I’m big fan of Object oriented programming and single responsibility principle, I love that approach as it’s easy to understand, easy to maintain.
But some people tend to go overboard with making everything separate classes ( this is similar to previous point about over-generalization ). Project’s shouldn’t blow out of proportions with as many classes as you can think of. Once you start doing** classes that have only one simple function, you should stop and think if that’s really necessary ? ( I’m not talking about SRP (SRP is good!), but rather making 5 classes that have same responsibility and could easily be 1 class )**
Too much generalization, putting everything in separate classes ( when non necessary ) may have a bad repercussions later on. It will be harder to optimize your code if it’s going between too many classes ( SRP is your friend ), it may actually be hard to add new features when you divide the code too much… Always think about the relations between your classes and their responsibilities, do you really need to move that code into separate class? Maybe it’s doesn’t really make sense?
I can write that better
Many of us have have big egos, we think we can write anything and probably do it better than someone else. Leave your ego at home.
This applies to almost everything we do, when we need to work on a project that was already created by someone else we tend to look at it briefly and then we think ‘that’s really bad code, I could rewrite it wayyyy better‘. When you need to add some custom component to your project, you can look at it and decide ‘I could make it nicer if I wrote it from scratch‘.
**I’ve bad news for you: **Almost all code may look like crap to someone else, we all have different approaches / experiences. The programmer that made this project probably spend months of time doing the structure work and he really understood what need to be taken care of, you just looked at the project and you can’t potentially know that. Of course there are many cases where the code is really crap, but it’s obvious when you see something like that (taken from a real project that I was asked to improve by client, ivars name changed ):
- (void)dealloc {
[A release];
[B release];
[A dealloc];
[B dealloc];
A = nil;
B = nil;
[self release];
[super dealloc];
}
As for writing your own components, you can find quite a lot of good quality components for what you are trying to achieve, and it always better to use something that is already tested by the community, rather than making if from scratch.
Just think how much time it would take to write it, then make sure it all works correctly, and then figure out that you didn’t test good enough. Writing from scratch is mostly beneficial for learning, not for a project that you have to deliver in next 2 weeks ![:)]
**And if you don’t believe that you can write bad code, just open some project you did a few years ago, I bet you will think that’s it BAD! **
Afraid of tools and writing less code
People tend to be afraid of change, we have our habits that we believe are the right ones, it takes some force to go out of your comfort zone and really give a try to something new.
A lot of programmers that I’ve met think that using Interface Builder is really bad, I’ve been writing my UI code manually for 2 years after initially trying IB and not liking the first versions of that , after this period I went outside my comfort zone and gave IB a second try. It improved a lot, now you even have Storyboard that are really nice and will probably evolve to more and more useful tool. I find it really useful to use IB in some cases, and it’s not only for very simple UI, you can make many advanced stuff also in IB.
Be pragmatic and use the best tool for the job, sometimes it’s better to write your custom UI code ( like custom UITableViewCell that needs to render fast! ) but very often IB is absolutely fine!
After all Less code you write means less problems that you will have to debug.
Conclusion
There are many more bad habits that you probably are aware of ( could probably write a book about them ). The one that I mentioned may not be the obvious ones, but I’ve noticed them quite often working with different people. If someone does any of them I doesn’t mean they are bad programmers, probably all of us have some bad habits and the point is to try to eliminate. I dare you to look at code that you wrote 3 years ago and tell me that you like it now !