Refactoring your own code is, what I guess, something that you do frequently – at least I am. Maybe a better description of the process I went through would be rewriting, but let’s stick with refactoring. Either the routines get too complex, or there’s an extra parameter needed or there’s some new special case to be handled, never mind the reason, refactoring of your own code is what we all do and should do.
I will not go here into explaining various reasons (and solutions) why and how you would want to rewrite your own functions (maybe originally coded years ago). There are plenty of possible scenarios/solutions: extract some piece of code into a separate routine, optimize sections, replace records with objects (or the opposite), introduce new language constructs and so on.
A few days ago I’ve placed my hands over a Delphi application coded years ago. My task was to extend one function with some special processing. The actual function already had some 2000 (two thousand) lines of code. There were a couple of nested subroutines including more nested subroutines. There were some 20 (twenty) input parameters.
As you might imagine: a mess!
But, a task is a task and one has to finish what was started. After a few hours (read: days) I’ve successfully refactored the entire function (introduced function overloads, removed duplicated code, normal optimization stuff…)
However, and to be honest, my first reaction was “heck, I guess the fastest would be to rewrite the entire function in the following, much simpler manner (code below). After all, a boolean function would either return a false or a true value – only 2 possible outcomes of the 2000 lines of code!”
And here’s what my first (virtual) solution was:
function Refactored(const someInputParameters : integer): boolean; const returnValue : array [0..1] of boolean = (false, true); begin result := returnValue[GetTickCount MOD 2]; end;
From the first look, the above implementation of a boolean function is as good as any. After all, it would return either true or false, there’s no 3rd option with booleans 🙂
You? Had a similar moment?
Result := boolean(GetTickCount and $00000001)
It’s funnier… 😉
Fantastic idea… and completely un-testable from a unit test viewpoint, unless of course you re-implement your own GetTickCount which always returns 1. You know a good place for the overriden GetTickCount function would be in some global unit that you use in every project. Yes, the one that has that TKitchenSink class.
Why not go for the obvious solution?
Result := GetTickCount mod 2 = 0;
Oh I hate blog software that swallow angle brackets in comments…
Now I know how you feel 🙁 My suggested solution should be:
Result := GetTickCount mod 2 != 0;
But that changes the entire output of the method. The suggested implementation return true when it is odd and false when even. Your solution reverses those results. The solution should be:
Result := GetTickCount mod 2 0;
Why is almost nobody using the obvious function?
result := Odd(GetTickCount);
Now, this is showing your age Uwe Raabe. Nobody who didn’t start his career before Delphi (probably with Standard Pascal) even knows about the Even and Odd functions. 😉
Result := not Even(GetTickCount);
Pingback: Новости из мира Delphi 8.09 – 14.09 2014 | Delphi 2010 ru