>>>>>>I agree completely with Rick in this regard. Those backdoor tricks only increase technical debt and will for sure bite you back at one time.
>>>>>>
>>>>>>Even better try to upgrade the affected data with non-ambigous values if possible.
>>>>>>
>>>>>>"Always code for the maintener:
>>>>>>Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live."
>>>>>
>>>>>... and of course there is that possibility that YOU might be the poor soul that needs to maintain that bit of code.
>>>>
>>>>And then he has the benefit of knowing which moron wrote it, and where he lives...
>>>
>>>In fact yes to the first, but no to the second, because this person has passed away a few years ago and and that had put the company he worked for in a very dire situation.
>>>
>>>Now I have to assess the debt we are in. Based on past mistakes the company is loosing several hundreds of Euros, at times thousands, on a daily basis. A routine customization which should take maximum one day of work (average speed programmer) takes at least one full week, but mostly much longer.
>>>
>>>The previous developers have constantly focused on doing something quickly. Now we are focusing on building good design. As the first strategy seems to give you quick results, it very soon becomes clear that you are loosing more and more time, the bigger the application gets. The more thought-through approach seems to be more time consuming in the beginning, but later rewards you with a complete system that will pay you off instead of increasing debt. Overtime has stopped and we are more productive then every before.
>>>
>>>Also the previous code had to do many late hours and overtime constantly to
>>
>>
>>There is nothing to say against this.
>>
>>A quick'n'dirty solution like the my_dow function (and the even quicker #DEFINE) are a pain in the end.
>>But until then, they earn money. Don't forget, how ever creepy it looks now - there was profit. If the guy would have worked by the book, possibly the whole project might be dead for a decade. I guess some manager was happy about high productivity at those days.
>
>but then again, you never know when it comes flying back at you. If you're lucky there will be a lot of time before that happens. If you're unlucky it comes flying back at you not long after launch -- and you're now "under the gun" to fix the bug in a *live* system.
>
>as for #DEFINE hacks, I avoid them if possible -- had seen enough of the horrors of #DEFINE abuse. Ever tried to read the code typical in the International Obfuscated C Code Contest? I'd also heard of the horror stories when some "clever" programmer had re-defined a number of manifest constants to correct for some flaws in his own code (as written, his code would work in some environments and not in others -- for example when assigning a char value to an int, is the value handled as signed or unsigned value). Some of the #define constants were re-defined within several different header files. It "fixed" the bug in his own code, but broke everyone else's.

Look around how many people use this to replace MESSAGEBOX or GETFILE to a more modern style. O.k: it's different because it is transparent -- same input, same return only changing visual aspects.

Code obfuscation is cool. I'm uncool. ;) The hack here might be usefull to put it throug the door asap, but I would plan a rework. To much magic in a prog is hell. Eventbinding is magic enough.