Friday, June 19, 2015

Understanding of problem

This topic came to my mind in meantime of resolving linking problem on Linux. When I build dynamic library my app missed some of the symbols. 

And no I didn't forget to compile *.cpp file which contain it. If it was so easy I wouldn't spend hours on resolving it. But this won't be topic of this post. The topic is about understanding of problem that we try resolve. I talking especially about this weird situations when something happening and we don't know why.

I know different schools how to deal with this hard problems :] 

Conclusion 1: It's for sure not in my code. 

And this issue wasn't in my code :]  I didn't believed that this code was wrong from start. It was my fault for sure. Question only where. 

Of course I'm not always was this way. In my younger days very often after hour of searching I were deciding it's for sure not my fault. Of course in 99% of time I was finding out later that I was wrong. Well privilege of being young.

Conclusion 2: Let's shuffle code and it will work.

Not literally but point of this is to do some change which we think will fix issue but we don't understand why. After this we run application if it work we are happy. To give example we have crash in application because of NULL value so we add check if it is null.

Sadly this way of resolving problems is one of the worse I can imagine. There is nothing worse than changing randomly code because we try to resolve some issue. This is just bad idea because very often this "fix" hide real problem. With time passing finding steps to reproduce it became harder and harder.

Conclusion 3: Let's understand what happening.

I think is the best solution but have one bottleneck: it consume time. But I will add from my experience: that very often it save time later. Issue is resolved properly, we understand what we done to make it work and finally if it will reported again most of the time it's some other problem.

Conclusion 4: I understand what happening but don't know why.

This is my current situation where I know that my issue is because of linking of static libraries (*.a) inside dynamic (*.so). Static library missing virtual table symbols because one of virtual function is not in the same *.cpp. So I know why this issue happen I expect that there are some missing flags of linking to resolve it. I just need to find which one :]


Of course all this sound easy :] but its not. There are situation where you need to do null check because there is no time. You need to ship something in hour and there is no choice. Of course good approach is to look into the problem deeper after sending build to find real issue.

Other thing is that life showing that sometimes problem is really in some external library or not your code. This happening but still safer is to assume that you done something wrong. And if you really don't know what you could do wrong prepare some solid test case and contact person responsible for this piece of code.

Finally, approach to understand problem is not something we are born with (in most cases). This is for sure not the easiest way of dealing with problem and we need to put a lot of effort into it. But with time it start to being natural approach which bring only benefits.


Saturday, June 6, 2015

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::releasevoid )

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::CAnimationResourceconst wrResourceIDa_idIResourceManagera_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:

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):
  1. If you spend more than hour to understand small piece of code and still fail to do it.
  2. Code show no understanding of problem it should resolve.
  3. Code with weird dependencies which are hard to follow.
  4. Duplicating of functionality that can be simple achieve by modification other piece of code.
  5. Overusing allocations.
  6. Not strict access rights to class members.
There is probably hundred more points which I missed. But this are the one that came to my mind right now.


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.

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?