I was wondering why C# requires me to use break in a switch statement although a fall-through semantics is by definition not allowed. hence, the compiler could generate the break at the end of each case-block and save me the hassle.
However, there is one scenario (which has already been discussed on this site) which I could come up with that might be the reason for the explicit usage of break:
switch (foo) {
case 0:
case 1:
bar();
break;
default:
break;
}
Here, the method bar() is called if foo has either the value 0 or 1.
This option would break in the truest sense of the word if the compiler would generate break statements by itself. Is this it, is this the reason why the break is compulsory or are there any other good reasons?
The question presupposes a falsehood and therefore cannot be answered. The language does NOT require a break at the end of a switch section. The language requires that the statement list of a switch section must have an unreachable end point. "break" is just the most commonly used statement that has this property. It is perfectly legal to end a switch section with "return;", "goto case 2;", "throw new Exception();" or "while (true) {}" (or in some cases, continue, though that's usually a bad idea.)
The reason we require a statement list with an unreachable endpoint is to enforce the "no fall through" rule.
If your question is better stated as "why doesn't the compiler automatically fix my error when I fail to produce a switch section with a statement list with an unreachable end point, by inserting a break statement on my behalf?", then the answer is that C# is not a "make a guess about what the developer probably meant and muddle on through" sort of language. Some languages are -- JScript, for example -- but C# is not.
We believe that C# programmers who make mistakes want to be told about those mistakes so that they can intentionally and deliberately correct them, and that this is a good thing. Our customers tell us that they do not want the compiler to make a guess about what they meant and hope for the best. That's why C# also does not make a guess about where you meant to put that missing semicolon, as JScript does, or silently fail when you attempt to modify a read-only variable, as JScript does, and so on.
I suspect that the reason C# requires the developer to place a break or terminal statement at the end of each case is for clarity.
It avoids newcomers to the language from assuming that switch( ) in C# behaves like switch in C or C++ where fall through behavior occurs. Only in the cases of adjacent empty cases does fall through occur in C# - which is relatively obvious.
EDIT: Actually, in C# fallthrough is always illegal. What is legal, however, is having a single case associated with two or more labels. Eric Lippert writes at length about this behavior and how it differs from C/C++ switch statements.
You may be interested in reading this article on Eric Lipperts blog.
By making break optional, you open yourself up to bugs like this:
switch (thing_result)
{
case GOOD_THING:
IssueReward();
// UH-OH, missing break!
case BAD_THING:
IssuePunishment();
break;
}
The C# language designers have tried to help programmers avoid pitfalls in the languages that came before it, generally by forcing the programmer to be more explicit (e.g. explicit use of the 'override' or 'new' keyword for implementing or shadowing virtual members).
My understanding of the matter is that it was included to match C++ syntax.
If you wouldn't need to append a break, there is a problem
switch (number)
{
case 0:
case 1:
DoSomething();
}
What happens if number == 0? Is this an empty case which does not do anything or will DoSomething() be executed?
Related
Usually, if I use switch for enums in C#, I have to write something like that:
switch (e)
{
case E.Value1:
//...
break;
case E.Value2:
//...
break;
//...
default:
throw new NotImplementedException("...");
}
In C++ (for VS) I could enable warnings C4061 and C4062 for this switch, make them errors and have a compile-time check. In C# I have to move this check to runtime...
Does anyone know how in C# I can have this checked in compile time? Maybe there is a warning, disabled by default, which I missed, or some other way?
No, there isn't be a compile-time check - it's legitimate to have a switch/case which only handles some of the named values. It would have been possible to include it, but there are some issues.
Firstly, it's entirely valid (unfortunately) for an enum value not to have any of the "named" values:
enum Foo
{
Bar = 0,
Baz = 1
}
...
Foo nastyValue = (Foo) 50;
Given that any value is feasible within the switch/case, the compiler can't know that you didn't mean to try to handle an unnamed value.
Secondly, it wouldn't work well with Flags enums - the compiler doesn't really know which values are meant to be convenient combinations. It could infer that, but it would be a bit icky.
Thirdly, it's not always what you want - sometimes you really do only want to respond to a few cases. I wouldn't want to have to suppress warnings on a reasonably regular basis.
You can use Enum.IsDefined to check for this up front, but that's relatively inefficient.
I agree that all of this is a bit of a pain - enums are a bit of a nasty area when it comes to .NET :(
I understand that this is necroposting, but nothing really changed in this area inside of the compiler. So, I made Roslyn analyzer for switch statements.
You can download SwitchAnalyzer package.
This is Roslyn analyzer and it supports
Enums with operations | and & for them. So, you can check flags as well
(but not like single int value)
Interface implementations (pattern matching) in the current data context.
Pattern matching for classes is not implemented in version 0.4 yet (but I hope to implement it soon).
To use it, just add this package to your project, you will get warnings for all uncovered cases if you don't have default branch or if it throws exception. And of course, you can enable "Treat warnings as errors" option for your project for all or specific warnings. Feel free to contact me in case if you will find any bugs.
I did some reading on this, and from questions similar to mine, it looks like what I am about to ask might not be (easily) possible... But I wanted to verify anyway. Maybe all those questions were from an older version of C#/.NET, and the thing has been implemented recently.
Anyway. I have a switch-case statement in one of my classes, whose purpose is essentially to take an int (typeID) and string (value) and check whether the value can be parsed as the data type indicated by typeID. For example, here is part of what I have now:
case 1:
char charret;
return char.TryParse(value, out charret);
case 2:
Regex re = new Regex(Constants.REGEX_ALPHANUMERIC);
return re.IsMatch(value);
case 3:
bool boolret;
return bool.TryParse(value, out boolret);
//And so on...
What I would like to do is to be able to avoid the char/bool instantiation you see in cases 1 & 3. Ideally, I would like to just have the return statement. It's not a big deal (obviously), but it would be nice if I could make this more (even more) compact.
That's inherently impossible.
Variables passed as out parameters must exactly match the parameter type.
There's no way to avoid declaring a variable when you are calling a function with an out parameter.
This post might be helpful as it does a generic TryParse (if it is available):
http://toadcode.blogspot.com/2010/10/generic-object-tryparse.html
I am converting some VB.NET code to C#, as I am more comfortable with it and it helps me in resolving issues faster. However, I came across this code which is NOT an error in VB.NET — but converting it to C# is generating a compiler error.
VB.NET Code
Select Case name
Case "FSTF"
.....
Case "FSTF"
.....
End Select
C# Converted Code
switch(name) {
case "FSTF":
....;
break;
case "FSTF":
....;
break;
}
And the error is:
The Label 'case "FSTF":' already occurs in this switch statement.
What is the solution here — does it mean that in the VB.NET code, the second case statement was just a dummy — or was the first case a dummy?
From the documentation for Select...Case:
If testexpression matches an expressionlist clause in more than one Case clause, only the statements following the first match run.
So here the second case is effectively redundant. Personally I prefer the C# approach of highlighting what was almost certainly an unnoticed programming error rather than the deliberate introduction of a duplicate case...
I assume it was done this way to make VB.NET compatible with the Visual Basic 6.0 and older versions because that is the way they behaved. Had VB.NET reported a compilation error like C# then it would have been more difficult to port older Visual Basic code to VB.NET.
The odd thing about this is that VB.NET does not seem smart enough to eliminate the redundant case in the generated CIL code. This leads to another peculiar difference between C# and VB.NET. That is, VB.NET does not change its strategy from a sequential lookup to a Dictionary lookup when targeting string types like C#. This means VB.NET's Select constructs using string types can be slower to execute than C#'s switch counterpart. The reason for this (credit given to MarkJ) is because C# case statements can only contain constants whereas Visual Basic case statements can contain expressions.
It sounds stupid, but over the years I haven't been able to come up with a use case that would require this. A quick google search didn't reveal anything worthwhile.
From memory there was a use case mentioned by Bjarne Stroustrup but i can't find a reference to it.
So why can't you have this in C languages:
int val = 0;
if val
doSomehing();
else
doSomehinglse();
I can accept the "we couldn't be bothered adding support to lexer" reason, I just want to figure out if this syntax breaks other language constructs. Considering how many whacky syntax features there are in C/C++, i hardly think this would have added much complexity.
If there are no brackets around expressions in if constructs, what would be the meaning of the following statement?
if x * x * b = NULL;
Is it
if (x*x)
(*b) = NULL;
or is it
if (x)
(*x) * b = NULL;
(of course these are silly examples and don't even work for obvious reasons but you get the point)
TLDR: Brackets are required in C to remove even the possibility of any syntactic ambiguity.
Tell me how to interprit the following:
if x ++ b;
Looks silly but...
if( x ) ++b;
or
if( x++ ) b;
or perhaps "x" has an overloaded operator then...
if( x ++ b){;}
Edit:
As Martin York noted "++" has a higher precedence which is why I've had to add the operator overloading tidbit. He's absolutely right when dealing with modern compilers up until you allow for all that overloading goodness which comes with C++.
I think a better question would be "why would we want such a thing?" than "why don't we have it?". It introduces another otherwise unnecessary edge case into the lexer, just so you can avoid typing 4 extra characters; and adds complexity to the spec by allowing exceptions to a simple syntax that already supports all possible cases just fine. Not to mention toes the line of ambiguity, which in a programming language doesn't have much value.
One other possible thing to keep in mind: C was created at a time when tape storage was common, so random seek or going backwards through the current file or even other files was not really feasible (which also explains why you have to put some stuff (i.e. forward declarations) before other stuff (i.e. usage of functions) even though the compiler should be able to figure it out on it's own).
It's simply a means of ending the condition clause of the statement.
Other languages use other means such as a "then" or in Python "if condition :(Followed by a return)"
(The : always get me in python I keep leaving them out and get errors than aren't immediately obvious as a result.)
Computer grammars typically like some unique mechanizism to identify the different parts of a statement or expression. It's no better or worst in this respect than any other language. The dangle else issue with C/C++ is an example of ambiguity from a gramatic standpoint and has to be handled as a special case to insure correct operation. (i.e. It adds extra work for the compiler implementor.)
i would love that syntax too, but to avoid parsing ambiguties, must be of this form:
for multiple statements:
if val
{
doSomething();
doOthers();
}
for one statement:
if val:
doSomething();
unless you want significant white space you need to be able to tell when the condition ends
in some languages it's () around the condition in some it's the keyword then an if like the one given in the answer
if x * x * b = NULL could be one condition always evaluating to false, one assigning null to b in the case of (xx) the compiler has no way of knowing when the condition ends and the following operation begins. So there needs to be an explicit "back marker" for the compiler to know when the condition ends. In C(++), Java, c# and other languages it's () marking the condition in F# it's the keyword 'then' and in still other languages it's a newline/indentation
The fundamental reason is that C and friends don't have a 'then' keyword so they need another way to delimit the condition-expression. Languages that do, like Pascal and PL/1, don't need the parentheses. Same applies to 'while', where Pascal, PL/1, etc have a 'do'.
It is because it helps programmer to make compiler understand in which sequence an expressions( including a sequence of types of operators like arithmetic,logical,assignment,etc) need to be solved in order to get desired output.
I can give at least one example why in C there are paranthesis around conditions,
For example consider the following
while(1) do_something();
The above will call do_something() for ever in an infinite loop
The reason the parenthis are required is because the following would be ambiguous
while 1 ; do_something();
does that mean, evaluate do_something and do nothing in the while loop? or does it mean the same as the code sample above?
I guess that showes one way why in the C syntax parenthis are required around condition evaluations, and by extending the same syntax (for the sake of consitency) it is extended to the if statements.
Discalaimer: I could be completely wrong and the reason behind having the pranthesis could be completely different, but at least I've shown one example of how it can be useful
I think you are confusing "brackets" with "parenthesis"
This is possible in C:
void doSomething(){}
void doSomethingElse(){}
void main() {
int val = 0;
if( val )
doSomething();
else
doSomethingElse();
}
Not all "C" languages force the parethesis usage and and leave braces as optional. Go ( Issue) programming language does exactly the opposite.
The correct way to write that same sentence in Issue9 would be:
if val {
doSomething();
} else {
doSomethingElse();
}
That way the following is not valid:
if x * x * b = NULL;
It should be one of:
if x*x {
*b=NULL;
}
or
if x {
xb=NULL;
}
Here the braces remove the ambiguity created by the lack of parenthesis.
I can't think of any specific cases where omitting the parens would actually cause any ambiguity, but there is probably a corner case somewhere.
It might be related to locally declared variables (as in if (bool b = foo())... where without the parentheses, it'd be harder to determine if bool is a type declaration or the the entire condition. In the latter case, b would then be the first token of the if-statements body, rather than part of the condition.
Because C allows one to do :
if (x) { // As opposed to java where you need to do if (x == something)
// your code
}
As you can see above flexibility gives rise to ambiguity as others have shown.
Some may feel this question is subjective. But, I feel this is among the most important things to be told to a programmer.
Is this a good function name to check for null values.
1. checkNull()
2. notNull()
3. isNull()
What if I write
checkIfNull()
I do not know how many people share the same feeling as I do, I have spent more time in thinking good names for my functions than writing one.
How do people think of good names? Can the naming be consistent across languages (mainly C++ and Java)
Update:
As I go by the number of updates till now, Most people prefer isNull(). How do you decide upon this that isNull() is the perfect name.
checkNotNull() // throw exception if Null
Is this a good name? Does everyone depend upon their intuition for deciding a name?
The question is about choosing a perfect name!!!
isNull might be a bad example, because:
Object foo = null;
if (foo.isNull()) { // Causes a NullPointerException in Java. }
Otherwise, you've got:
Object foo = null;
if (UtilityClass.isNull(foo) { }
Which seems harder and less clear than just doing:
Object foo = null;
if (foo == null) { }
Like the others, I prefer isNull() (or IsNull(), depending on your language/coding conventions).
Why? Beside it is a widely accepted convention, it sounds nice when you read the code:
if (isNull())
// or
if (foo.isInitialized())
and so on. Almost natural English... :-) Compare to the alternatives!
Like iWerner, I would avoid negative form for making identifiers (variables, methods) names.
Another common convention is to start method/function names with a verb. Now, Sun did not follow this convention in the early days of Java (hence the length() and size() methods, for example) but it even deprecates some of these old names in favor of the verb rule.
If the function throws an exception if it's null, it should be called ThrowIfNull to make it clear that it will throw for you.
IsNull() is a good choice, But additionally it should return a bool.
So that you can check its value in if statment without getting any NullReference exception.
Nowadays it is highly recommended to use the javaBeans convention:
isNull() //if the return type is a primitive
getNull() //if the return type is an object (Like Boolean in java)
For non boolean types access members, you should use get.
For static variable members use the camel case style: "myVar".
For class name use camel case style with capitalized first letter: "MyClass".
And for constant members use uppercase letter with underscore as separator: "MY_CONSTANT".
The answer depends on what your method returns.
If it returns a bool indicating whether the object is null, I would name it IsNull(Thing thing), because it is the least ambiguous formulation - what the method does and what it returns is immediately obvious.
If the method is void but throws if the object is null, I would call it GuardAgainstNull(), or something along these lines.
IMO, CheckNull() is somewhat ambiguous - you don't know by looking at the method if it should return a bool or throw, or what the bool indicates exactly.
I prefer IsNull.
To learn good naming style, study the standard libraries (except in PHP). You should follow the style used by the standard libraries in each language.
For C#, study the Framework Design Guidelines.
personally, I would use
IsNull()
I found this article. Felt like sharing with you guys!
If you're doing a lot of null checking in your code, I think having a pair of methods, i.e.:
IsNull()
IsNotNull()
will lead to the most readable code in the long run.
I know !IsNull() is a standard idiom in curly brace languages, but I think it's much less clear than IsNotNull.
It's too easy to overlook that single "!" character, especially if it's buried in a more complex expression.
It can vary depending on the language you are using - and you tagged a couple to this question. It is important to stay consistent with the standards of the language/library you are coding against. Yes, naming conventions are very important! [There's even a wikipedia entry on it: http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29]
For .Net I found this "cheat sheet" on naming conventions:
http://www.irritatedvowel.com/Programming/Standards.aspx
For your example in C# I'd reccommend : IsNull()
If your company does not specify naming conventions in its coding standards I suggest it's time you add them.
Our company's Java coding standards are basedon the official Java Coding Standards which, I believe, specify names like isNull().
From your example, the notNull() is bad, because you may end up with statements like if(!notNull()) or the like.
I would use IsNull(); there is a precedence in .Net which has a static IsNullOrEmpty() method for the String type. "Is" is my preferred prefix for methods that return a bool. I would not have a negative method "notNull", because this too easily results in double negatives. Instead use the negation operation on a positive method, e.g., !IsNull().
However, a method that only checks for a null value may be overly complicating things; what is wrong with
x == null
Which I think is more readable than
IsNull(x)
Most developers seeing IsNull(x) would wonder if there is some fancy null checking in the IsNull method; if there isn't then "x == null" is probably better.