Lets play : Good code / Bad code
If you try to find answer what good/bad code is, you won't find it in this post. I don't try to sell my beliefs and I'm sure you wouldn't like them anyway. To show you that, check this simple pieces of code:
////////////////////////////////////////////////////////////////////////// void CAnimationResource::release( void ) { SAFE_DELETE(m_privateData); }
I use void when function don't use any arguments. I know this useless and do nothing but I just like look of it (Personal preference). Other example:
////////////////////////////////////////////////////////////////////////// CAnimationResource::CAnimationResource( const wrResourceID& a_id, IResourceManager* a_manager ) : CResource(a_id) , m_manager(a_manager) { }
I using prefix a_ for arguments of functions and use this style of organizing initialization in constructors. This is my way of coding. You probably have your own style this is perfectly fine. We shouldn't fight over some conventions details. Everybody is different and everybody code differently. This is sometimes not easy to accept (even for me) but we just need to live with it.
So let's not focus on programming style and move to the main topic:
So let's not focus on programming style and move to the main topic:
Good code
So what good code really mean ? Some time ago I would probably give answer right away. It would be long and boring talk how to write code, what to do and what not to do. But right now I'm doubt I could easily answer this question.
Lets assume that we have piece of code which resolve some issue. Code is really messy with hacks all over it. Because of all this we cannot call it good code, great candidate to refactoring. Sadly without rewriting half of other big system it's hard to create better solution. People with commercial experience know that in production environment you not always can rewrite everything.
Following all this thoughts we can have bad code in which we have bad code which in given situation is the best possible code. So probably we could call it good code which don't make sense at all :| I'm lost in my thoughts.
So is this mean that bad code is good ?
I think it's just like problem mentioned in this presentation. The same gray tiles looks brighter in shadow but in light area they look darker. I think this is accurate description of code. Our way of code perception is affected by code we know. Bad code may look pretty good if you deal with even worse code all the time.
So what bad code mean ?
Everybody recognize bad code when they see it. But defining it is not easy. For me there are few points which make code bad for me (this is my subjective opinion):
- If you spend more than hour to understand small piece of code and still fail to do it.
- Code show no understanding of problem it should resolve.
- Code with weird dependencies which are hard to follow.
- Duplicating of functionality that can be simple achieve by modification other piece of code.
- Overusing allocations.
- Not strict access rights to class members.
Conclusion
So Good and Bad code is hard to define. Some "good" code that I wrote few years ago look for me crappy right not. Sometimes it's really bad piece of code and it's perfectly fine. If I'm saying this then it mean I'm better now and I can see flows in what I done. At some point when I will find time or need I will try to improve this bad code.
If in work somebody telling me that my code is bad. It mean that it's bad no matter how I see it right now. I will ask why he think so, we will discuss this mater and I will try to fix it. There is point in arguing who is right and who is wrong. It's about understanding why other person see my code as bad and dealing of source of problem.
If in work somebody telling me that my code is bad. It mean that it's bad no matter how I see it right now. I will ask why he think so, we will discuss this mater and I will try to fix it. There is point in arguing who is right and who is wrong. It's about understanding why other person see my code as bad and dealing of source of problem.
Of course it's easier to talk about it then do it. We are often stuck in our boxes which are comfortable and don't try look outside. But there is outside world and we cannot forget about this. That's why I learned that I need to experience as much as I can. Different code, different technologies, different languages, different opinions, different approaches. I'm not always succeeding in that but I try and this is what allow me to grow.
What you think about this problem? And how to deal with it?
Greg
Comments
Post a Comment