Programmers Bad Habits

Emc2 · 2013-01-30T10:52:01+00:00

Reference: Programmers bad habits - Krzysztof Zab?ocki We evolve and change our habits, probably many times every few years. Your code style changes, your approach to writing code in general. Thats usually good but sometimes bad habits are introduced into that process and remain with you for long time. I would like to share my short thought of a few not really that good habits that Ive seen in myself and other people over the years. Some may be not look like bad ones DisclaimerThe wrong habits Im 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. Im all about doing OOP and SRP but as everything it can be abused, remember about KISS principle guys ?. Leaving unused codeWe all sometimes decide to rewrite some part of code because it either doesnt 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. Thats all fine but you should remove it after you are done with new version. If you dont it will keep growing, and at some point its 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, dont be afraid to delete it! Do it now! Over-generalizationMany 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. Ive 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 ? Ive 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 thats 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, its tested in real projects. Object Oriented fixationLet me state this: Im big fan of Object oriented programming and single responsibility principle, I love that approach as its 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 ). Projects shouldnt 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 thats really necessary ? ( Im 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 its 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 its doesnt really make sense? I can write that betterMany 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 thats 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. Ive bad news for you: Almost all code may look like ---- 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 cant potentially know that. Of course there are many cases where the code is really ----, but its obvious when you see something like that (taken from a real project that I was asked to improve by client, ivars name changed ): 12345678910 - (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 thenfigure out that you didnt test good enough. Writing from scratch is mostly beneficial for learning, not for a project that you have to deliver in next 2 weeks ![:)][2] And if you dont believe that you can write bad code, just open some project you did a few years ago, I bet you will think thats it BAD! Afraid of tools and writing less codePeople 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 Ive met think that using Interface Builder is really bad, Ive 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 its 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 its 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. ConclusionThere 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 Ive noticed them quite often working with different people. If someone does any of them I doesnt 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 ![:)][2]

Thread starter Emc2
Start date Jan 30, 2013

Emc2

JamiiForums uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Accept Learn more…

Back

Top Bottom

Forums

New posts

Programmers Bad Habits

Emc2

JF-Expert Member

Our Community

Regional Communities