I'm not sure where I first heard the term problem hiding, but it's stuck with me because it's such a common thing. Hell, I do it myself sometimes. Like the worst of practices, it manifests itself in different ways.
Take for example This thread entitled How to create non blocking functions. Essentially the OP wanted to have something call his code back after a certain delay, but while the original code carried on. In his words, 'Sort of like a timer'. I'm sure many of you, like I, thought of a couple of solutions, but then the rest of the sentence comes into play, 'but i dont want to have to create a new thread or create a win32 timer or something'.
Now I haven't coded properly in win32 for years, and I haven't toyed with threading much, but as far as I'm aware (and judging by some of the replies) both of those methods do exactly what he wants. He then replied with:
Quote:
Thanks but the reason i dont want to create another thread with win32 is for some reason after createing a thread, calls to ShowCursor are not working. Nothin happens when i call it
Ah. How interesting. So now, instead of taking the best solution to his problem, he is searching for another. Although there are a couple of ways I could think of to do this without threads or timers, it doesn't seem like such a good idea to ignore a good solution.
So where does problem hiding come in? Problem hiding is just what it says - when you avoid fixing a problem by hiding it. This either means shooting yourself in the foot to avoid using one method, because you can't get that method to work, or the more well-known mistake of assuming that because some hackish code fixes the problem *now*, that the problem really is fixed. Often said code will fix the symptomns but not the root cause.
This is perhaps hard to find examples for. From the above poster's reply I don't know if he's actually having a problem, or just not understanding how threads work. Either way he's avoiding threads for the wrong reasons - because he can't get them to work. The Real solution is to fix what problems he is having with threads, and then use them for his timer problem.
This sort of thing comes up quite often, at least to my eyes. Someone who has never used the STL before writes the following code:
int foo(){ std::string mystr; strcpy(str, "foo"); std::cout << mystr << std::endl;}This promptly breaks when he trashes some memory. He then decides that the STL sucks and goes back to using character pointers to emulate strings, reasoning that "i know char* works" and "std::string is complicated". A slightly contrived example perhaps, but the point remains.
This, again, is problem hiding. This coder knows that the STL does indeed work, and so it must therefore be his problem that the code broke. Instead of figuring out what went wrong, he simply hides the problem by going back to using char*.
Problem solving is the exact opposite. When you encounter a problem, you fix it - as simple as that. If only it was as simple to do as it is to explain.
Of course, I'm speaking in general terms, and often times you can't fix a problem, or don't have the time to figure it out - you just want to get the code working, so you use an alternate method. That's fine, but always be careful of going too far to avoid solving problems - you might end up just creating more for yourself.
