I am working on code that takes as input a ton of ascii text defined by specific protocol. The original author interpreted \"string(1)\" datatypes in the original protocol
My suggestion to find existing errors such as the one described is to use Visual Studio to perform a search across the entire solution (Ctrl+Shift+F) using regular expressions.
I think that this will list all occurrences of a literal number in the source code. You can then glance through the search results to see if any of them require further investigation.
You can further narrow down the search results by focusing on a specific type of problem. For instance, to find the code in the provided example, you could adjust the expression to the following: ==( |\t|\r|\n)*[0-9]+[^0-9]
I can't offer any good suggestion to avoid this problem other than to try to avoid "magic" values in code.
Assuming that this code is being used in some kind of menu selection logic, I feel like perhaps the code should be something like this:
static class MenuSelection
{
public const char Open = '1';
public const char Edit = '2';
public const char Save = '3';
// ...
public const char Close = '7';
}
And then MenuSelection should be used in the if statement as shown below:
char theChar = whatever();
if(theChar == MenuSelection.Close) {...}
This doesn't really address the problem of the implicit conversion from UInt32 to char, but hopefully the person writing the code for the constants in the MenuSelection class will be less likely to forget the quotes.
EDIT: Oh, after giving it a try, it seems like this does kind of address the implicit conversion issue, because public const char Close = 7; produces a compile error.
Unfortunately, it doesn't help your immediate problem: a lot of existing code containing these kinds of bugs.