Showing posts from June, 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 you

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 fin