And Another One
-
Horror 1 :
if (strRet[0] == '0' && strRet[1] == '1' &&
strRet[2] == 'F' && strRet[3] == 'F' &&
strRet[4] == '2' && strRet[5] == '4')A piece of code I just looked at had the preceding logic sprinkled through it around twenty times to examine the response from a piece of equipment with comparisons of varying lengths. Apparently this individual has never heard of strncmp or its TCHAR variant _tcsncmp. Horror 2 : They wrote their own function essentially equivalent to strtoul. I won't subject you all to it - you'll have to trust me when I say that it is a horror. Horror 3 : The function described in Horror 2 is called ConvertHEXASC(). Here's how it is used to convert the data from the equipment :
int iTmp = 0; iTmp += ConvertHEXASC( strRet\[7\] ) \* 1; // 16^0 iTmp += ConvertHEXASC( strRet\[6\] ) \* 16; // 16^1 iTmp += ConvertHEXASC( strRet\[5\] ) \* 256; // 16^2 iTmp += ConvertHEXASC( strRet\[4\] ) \* 4096; // 16^3Now imagine a similar sequence of code used a few dozen times with strings of varying lengths and positions. :omg: Horror 4 : There were sixteen buttons used to select a property for the equipment and, naturally, there were sixteen different functions made to handle the clicks of the buttons. ON_COMMAND_RANGE anyone ? :wtf: The word horror barely scratches the surface for these and the rest of the things I saw there. It was staggering. Simply staggering.
-
Horror 1 :
if (strRet[0] == '0' && strRet[1] == '1' &&
strRet[2] == 'F' && strRet[3] == 'F' &&
strRet[4] == '2' && strRet[5] == '4')A piece of code I just looked at had the preceding logic sprinkled through it around twenty times to examine the response from a piece of equipment with comparisons of varying lengths. Apparently this individual has never heard of strncmp or its TCHAR variant _tcsncmp. Horror 2 : They wrote their own function essentially equivalent to strtoul. I won't subject you all to it - you'll have to trust me when I say that it is a horror. Horror 3 : The function described in Horror 2 is called ConvertHEXASC(). Here's how it is used to convert the data from the equipment :
int iTmp = 0; iTmp += ConvertHEXASC( strRet\[7\] ) \* 1; // 16^0 iTmp += ConvertHEXASC( strRet\[6\] ) \* 16; // 16^1 iTmp += ConvertHEXASC( strRet\[5\] ) \* 256; // 16^2 iTmp += ConvertHEXASC( strRet\[4\] ) \* 4096; // 16^3Now imagine a similar sequence of code used a few dozen times with strings of varying lengths and positions. :omg: Horror 4 : There were sixteen buttons used to select a property for the equipment and, naturally, there were sixteen different functions made to handle the clicks of the buttons. ON_COMMAND_RANGE anyone ? :wtf: The word horror barely scratches the surface for these and the rest of the things I saw there. It was staggering. Simply staggering.
What's the background of such champion-of-code-development? Just curious. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Horror 1 :
if (strRet[0] == '0' && strRet[1] == '1' &&
strRet[2] == 'F' && strRet[3] == 'F' &&
strRet[4] == '2' && strRet[5] == '4')A piece of code I just looked at had the preceding logic sprinkled through it around twenty times to examine the response from a piece of equipment with comparisons of varying lengths. Apparently this individual has never heard of strncmp or its TCHAR variant _tcsncmp. Horror 2 : They wrote their own function essentially equivalent to strtoul. I won't subject you all to it - you'll have to trust me when I say that it is a horror. Horror 3 : The function described in Horror 2 is called ConvertHEXASC(). Here's how it is used to convert the data from the equipment :
int iTmp = 0; iTmp += ConvertHEXASC( strRet\[7\] ) \* 1; // 16^0 iTmp += ConvertHEXASC( strRet\[6\] ) \* 16; // 16^1 iTmp += ConvertHEXASC( strRet\[5\] ) \* 256; // 16^2 iTmp += ConvertHEXASC( strRet\[4\] ) \* 4096; // 16^3Now imagine a similar sequence of code used a few dozen times with strings of varying lengths and positions. :omg: Horror 4 : There were sixteen buttons used to select a property for the equipment and, naturally, there were sixteen different functions made to handle the clicks of the buttons. ON_COMMAND_RANGE anyone ? :wtf: The word horror barely scratches the surface for these and the rest of the things I saw there. It was staggering. Simply staggering.
There were sixteen buttons used to select a property for the equipment and, naturally, there were sixteen different functions made to handle the clicks of the buttons. ON_COMMAND_RANGE anyone ? And when you add another button, and the seventeenth ID is already used for something else, you have a whole heap of work to do.
-
There were sixteen buttons used to select a property for the equipment and, naturally, there were sixteen different functions made to handle the clicks of the buttons. ON_COMMAND_RANGE anyone ? And when you add another button, and the seventeenth ID is already used for something else, you have a whole heap of work to do.
Graham Bradshaw wrote:
And when you add another button, and the seventeenth ID is already used for something else, you have a whole heap of work to do.
There's no problem pointing multiple
ON_COMMAND_RANGEmacros to the same function."Multithreading is just one damn thing after, before, or simultaneous with another." - Andrei Alexandrescu
-
There were sixteen buttons used to select a property for the equipment and, naturally, there were sixteen different functions made to handle the clicks of the buttons. ON_COMMAND_RANGE anyone ? And when you add another button, and the seventeenth ID is already used for something else, you have a whole heap of work to do.
I do not consider renumbering the values in Resource.h to be a whole heap of work. Besides, I always leave gaps around arrays of control identifiers just in case I have to add more so this is very rarely an issue for me and when it arises it is easy to deal with.
