![]() |
Reducing Repetitive Code
I'm trying to figure out a way to reduce the repetitiveness of this code. I see a couple options: load an array of all the cases from a simplified data file, or declare an array of all the cases.
I could change it to a switch, but I don't feel like having 50 break statements clogging up my source. The code converts an integer that represents the event of an asynchronous key's state, to a string representing the event's signal in human-readable form. Only the relevant signals are being handled, nothing like mouse clicks, F keys, arrows, etc... There is no coreleation between the number and the ASCII value for those characters, only to the extent of how it is defined by the Windows operating system. If only there was a function that could do this conversion for me. Any ideas? :
|
I haven't tested this with a compiler, but this should be enough to get you started.
Basic notion is that you have some ranges that you are mapping, and finding a technique to map anything in that range. :
boolean getShift () { |
Ahh, yes. That's a good idea! I was trying to think of someway to use strings of data. This way looks perfect. I'll take your idea and come up with my own code. Thanks.
|
Quote:
|
Quote:
|
Quote:
|
2Roll4Life7 and Polyphemus_, if you want to play with getting it "neater"
1) Define what you mean by "neatness", and provide some measure by which you determine how neat some code is; 2) Try different approaches. In keeping on topic with this thread, one measure might be related to the amount of repetitive code ...... In practice, I don't tend to like nesting switch/case blocks in if/else blocks (or vice versa) because it takes more time/effort to read and understand, which means it takes more time/effort to maintain. |
There is actually a term for the act of cleaning these kind of things up, it's called "Refactoring. As previously stated, a lot of it is just identifying what code could go into a function. Don't be afraid of having functions with long signatures. A common refactoring process is also creating large arrays with all the necessary information, sometimes even including function names and parameters.
example: if your program looks like this :
function bla:
{:
foreach $i in $array {the string "subrouting:a:b:c" could be parsed with :
/^subroutine:(.*):(.*):(.*)/:
subroutine(a, b, c)now in some languages this is not as easy as in others (PERL is very good at things like this for example). Excuse me for my rant on Refactoring, but it's a good skill to have, and I use it everyday for my job and on my personal projects. Eventually one can get good at it that the code written on the first try does not have to be refactored anymore, but don't be afraid to write it out the long way and look back afterwards. Good Luck, -Dizz |
Dizz! You're back!
|
Well, what I meant was by putting all the numbers into a switch statement and then in the default you can have just a couple of if statments for the ranges. Or alternatively you could have listed all the numbers you wanted for a range with no break statements between them and have your code for that range after that. I'm not too crazy about either of those though. As Grumpy said, it depends on your definition of neat.
Those were just my observations from glancing at the code... If I were faced with this problem myself, I'd probably just do a lookup in a hard coded hash table (this doesn't reduce repetitive code, but I just think it's a better approach [assuming you only want a few selected key codes and not all]). Then again if we are stuck stictly with C, that would require writing your own hash table implementation or finding a decent one by somebody else. Perl could probably do this in 2 lines, lol, and even C++ would give you the option of the STL hash_set. If you wanted to just map all the key codes with characters, you could do it with a large array of strings eg: :
char *keycodes[] = {"VK_LBUTTON", "VK_RBUTTON ", "VK_CANCEL", "VK_MBUTTON ", "VK_XBUTTON1", "VK_XBUTTON2", NULL, "VK_BACK", "VK_TAB", "...etc..."};So both solutions I described don't actually reduce the code, but that doesn't mean they aren't good solutions. Infact, a hardcoded lookup table or an index into an array are both faster than branching into a function that performs calculations. Also, if you plan on maintaining this code, I'd go with whatever way you're more comfortable with. If you'd like me to elaborate more, I won't mind, just ask. * My example line from above was using the keycodes from this list: http://msdn.microsoft.com/library/de...alKeyCodes.asp |
| All times are GMT -5. The time now is 1:26 AM. |
Powered by vBulletin® Version 3.7.0, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2007 DaniWeb® LLC