I have a code:
protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
switch (keyData)
{
case Keys.Alt|Ke
You use return in both conditions. So break could be easily removed.
But I prefer to leave it there in case you will change your code sometime.
There is a certain misunderstanding that all case
blocks in a C# switch
must end with a break
. In fact they must end with a jump statement in all code paths; this can be break
, return
, goto
or even continue
(or throw
, of course). Since the compiler will raise an error if there is a code path with no jump statement, there is absolutely no reason for the final break
in the example. The compiler will not let you change your code to a version where the final break
would be reached, and this would be the moment to add it.
Bitter experience has taught me to always include break statements unless you really mean to fallthrough to the next statement and even then, comment it. Otherwise a function could behave wildly differently because another developer changed something late on a Friday afternoon and didn't see the missing break.
If the function - however large - conforms to the same if...return...else....return structure throughout, you could define a return code variable at the start of the function. Then assign it in your case statement and return it at the end, whatever value it turns out to be.
As well as removing the break;
lines from there, you could also remove the else statements too. It's unneeded since you are returning from the first if
.
So your code might look like this instead:
protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
switch (keyData)
{
case Keys.Alt|Keys.D1:
if (this._condition1)
return true;
return base.ProcessCmdKey(ref msg, keyData);
case Keys.Control |Keys.U:
if (this._condition2)
return true;
return base.ProcessCmdKey(ref msg, keyData);
default:
return base.ProcessCmdKey(ref msg, keyData);
}
return true;
}
You can slim it down even more by removing your return true;
lines and inverting your if statements, because you return true and the end of the method anyway:
protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
switch (keyData)
{
case Keys.Alt|Keys.D1:
if (!this._condition1)
return base.ProcessCmdKey(ref msg, keyData);
break;
case Keys.Control |Keys.U:
if (!this._condition2)
return base.ProcessCmdKey(ref msg, keyData);
break;
default:
return base.ProcessCmdKey(ref msg, keyData);
}
return true;
}
EDIT: I forgot that you can't fall through using C# so you'd need a break; in each case. Which kind of ruins the nice readability of that block.
You could rewrite your code to be a lot shorter and less repatative:
bool ret = false;
switch(keyDate){
case Keys.Alt | Keys.D1:
ret = this._condition1;
break;
case Keys.Control |Keys.U:
ret = this._condition2;
break;
default: break;
}
return ret || base.ProcessCmdKey(ref msg, keyData);
There are three unreachable statements in your code, first two are the break statements and the last one int he last line "return true" is also unreachable, I dont know whether C# compiler detects that or not, but logically there is no way last return statement will also be reached.
There are multiple ways to solve this issue,
Better Design Way
If you return values within switch cases, it may be difficult to analyze your code later on by you or someone else, usually it is better to keep a return value temp variable and return it at end of function, that becomes easier to debug and understand the code for new coder.
Switch can be complicated, and more returns within switch may not have better control, if you want to implement logging, debugging, returns from cases could be complicated. And it becomes way to difficult browsing the logic flow graphs.
So it is better to avoid return altogather from case, but still it depends on situtations as well, one needs to make an intelligent decision here.