 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / September 2004Is it (null == something) or (something == null)?
I frequently see .NET coders, especially C# coders, use the following syntax: if (null == something){DoSomething();} instead of the much more intuitive if (something == null) {DoSomething();} Is this an example of anally-retentive programming held over from some bygone C era, or are there actual benefits to using this syntax in the .NET world? I would have thought a modern compiler would not care about syntax order, as it would optimize such a statement to produce the best execution speeds. Can anyone enlighten me? Thanks, Stano. > I frequently see .NET coders, especially C# coders, use the following syntax: > [quoted text clipped - 7 lines] > some bygone C era, or are there actual benefits to using this syntax > in the .NET world? The former, I believe. > I would have thought a modern compiler would not care about syntax > order, as it would optimize such a statement to produce the best > execution speeds. Can anyone enlighten me? Everyone I've asked about it has basically said it's a habit from C/C++ days, where they wanted to avoid the typo of if (something = null) Some didn't know that in C# that's not legal code, and others just preferred to stick to their existing habits.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Ah, it all becomes clear now. Cool. One less thing to wonder/worry about. Thanks for the clarification. > > I frequently see .NET coders, especially C# coders, use the following syntax: > > [quoted text clipped - 21 lines] > Some didn't know that in C# that's not legal code, and others just > preferred to stick to their existing habits. Suppose you ever go back to write a C program, the habit of writing (null == something) would save you some trouble. Besides, it's not incorrect in C#. And IMHO, it suggests that the programmer gives a thought to how a construct would work in some other language. Regards, Trilok. > Ah, it all becomes clear now. Cool. One less thing to wonder/worry about. Thanks for the clarification. > [quoted text clipped - 23 lines] > > Some didn't know that in C# that's not legal code, and others just > > preferred to stick to their existing habits. > Besides, it's not incorrect in C#. And IMHO, it suggests that the > programmer > gives a thought to how a construct would work in some other language. why do you think it is not correct? The compiler accepts it as valid code. I haven't seen a recommendation against its use and frankly i wouldn't support one because the code is clear and unambiguous inspite of the fact that it comes from another language. SignatureRegards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27cok > Suppose you ever go back to write a C program, the habit of writing (null > == [quoted text clipped - 35 lines] >> > Some didn't know that in C# that's not legal code, and others just >> > preferred to stick to their existing habits. He said it's not INcorrect Alvin. :) > > Besides, it's not incorrect in C#. And IMHO, it suggests that the > > programmer [quoted text clipped - 5 lines] > against its use and frankly i wouldn't support one because the code is clear > and unambiguous inspite of the fact that it comes from another language. Oops. that's what i get for half glancing a response. thanks for jumping me on that SignatureRegards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27cok > He said it's not INcorrect Alvin. :) > [quoted text clipped - 8 lines] > clear >> and unambiguous inspite of the fact that it comes from another language. Hello Alvin Bruney [MVP]" vapor at steaming post office, He never stated that it was incorrect... He said that it was *not* incorrect, meaning correct. :=) Read in context, it seems as he actually supports the idea.. -- Matt Berther http://www.mattberther.com >> Besides, it's not incorrect in C#. And IMHO, it suggests that the >> programmer [quoted text clipped - 5 lines] > clear and unambiguous inspite of the fact that it comes from another > language. > Suppose you ever go back to write a C program, the habit of writing (null == > something) would save you some trouble. If I change language, I precisely *don't* want my code to look as if it's in the previous language - otherwise I'm likely to adopt the same idioms and "think" in the previous language, which is a very bad idea. Some of the worst Java I've seen was written by people who were trying to make it C++, and I'm sure the same would be true if I tried to write C as if it were C#. > Besides, it's not incorrect in C#. And IMHO, it suggests that the > programmer gives a thought to how a construct would work in some > other language. Whereas IME, it suggests that the programmer *hasn't* given a thought as to whether an idiom which is usually regarded as sacrificing some readability for typo-safety is still necessary in the new language. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Jon, you have to admit that no harm is done in this construct. It doesn't hurt readability, it certainly isn't contrary to any recommended practice. It is probably only a matter of programmer taste. SignatureRegards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27cok >> Suppose you ever go back to write a C program, the habit of writing (null >> == [quoted text clipped - 14 lines] > as to whether an idiom which is usually regarded as sacrificing some > readability for typo-safety is still necessary in the new language. > you have to admit that no harm is done in this construct. I admit that no *semantic* harm is done. > It doesn't hurt readability, it certainly isn't contrary to any > recommended practice. It is probably only a matter of programmer > taste. No, I believe it *does* hurt readability. I believe it's an unintuitive way of writing the code (as did the OP, btw) which people only ever did in C/C++ to avoid typos. Tell me, do you think anyone would have done it if there *hadn't* been the potential for syntactically correct but semantically disastrous errors in C/C++? I don't. Writing code in the most natural way is a good thing. This *isn't* writing code in the most natural way - it's writing code in a way which was developed to avoid a problem in a different language. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too well, i come from the c++ world and it is normal to me. > Writing code in the most natural way is a good thing. This *isn't* > writing code in the most natural way - it's writing code in a way which > was developed to avoid a problem in a different language. It isn't natural to you because you aren't from the c++ world, but still you make a valid point. SignatureRegards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27cok >> you have to admit that no harm is done in this construct. > [quoted text clipped - 13 lines] > writing code in the most natural way - it's writing code in a way which > was developed to avoid a problem in a different language. > well, i come from the c++ world and it is normal to me. But only because the idiom is common there to avoid typos - not because it's a fundamentally readable style. > > Writing code in the most natural way is a good thing. This *isn't* > > writing code in the most natural way - it's writing code in a way which > > was developed to avoid a problem in a different language. > > It isn't natural to you because you aren't from the c++ world, but still you > make a valid point. I think the clincher is to ask yourself how you'd read the meaning of the line of code out loud to a colleague in an informal way. Suppose you were tracing some code to work out what should happen, how would you read out: if (5==x) { DoSomething(); } else { DoSomethingElse(); } I'd read that out as "If x is 5, we call DoSomething, otherwise we call DoSomethingElse". The idea of reading it as "If 5 is x, we call DoSomething, otherwise we call DoSomethingElse" is very strange to me - not in code terms, but in *English* terms. I don't know if there are other natural spoken languages where it would be a natural way of saying it - and if there are such languages, then native speakers of those languages have much more reason to use the idiom. Otherwise, I think it should be avoided in languages where it's not necessary for safety's sake. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too ya, when you put it like that it is hard to argue against. SignatureRegards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27cok >> well, i come from the c++ world and it is normal to me. > [quoted text clipped - 32 lines] > think it should be avoided in languages where it's not necessary for > safety's sake. First, my opinion: I don't care what language you are from, it isn't natural in terms of how we, as people, process logic. Either way is correct synatically, but I've seen this screw up too many simple conditions. For example -- and this is purely example, no real usage for this. Look at this for no more than 5 seconds and tell me what it does: do{ //some logic, perhaps generating a random sentence. MyString += GetARandomCharacter(); } while (0>MyString.IndexOf(".")); Maybe you got it, maybe you didn't. But wouldn't it make sense to say something like: do{ MyString += GetARandomCharacter(); } while (MyString.IndexOf(".") == -1); I know it's hard to quantify a bogus code sample. I've read a lot of coding books and I understand best practices; and in my opinion (no more valid than anyone else's, of course) I just think the paramount concern should be readability. I try to think, "OK, what's the next guy who looks at this code going to think when reading it for the first time?" OK, I'm done! Tom ***blah*** > I think the clincher is to ask yourself how you'd read the meaning of > the line of code out loud to a colleague in an informal way. Suppose [quoted text clipped - 19 lines] > think it should be avoided in languages where it's not necessary for > safety's sake. ***blah*** If you are using the terminology "x is 5," you would be incorrect in any case. It would be proper to say "x is equal to 5," which equivocates to "5 is equal to x" very well. Then again, the code would be much more legible if it were: if (5 == x) DoSomething(); else DoSomethingElse(); All those line breaks between braces really cause a stutter in the flow of the program (not to mention that braces are completely unnecessary in this case). --Just to give ya a hard time. > If you are using the terminology "x is 5," you would be incorrect in any > case. It would be proper to say "x is equal to 5," which equivocates to > "5 is equal to x" very well. If you're going to get picky, you should be talking about the *value* of x. x itself is variable - its *value* is what we're talking about. However, when reading code to myself in English, I would ignore the distinction between the variable and its value, and assume the equality. That's how English works for me. Even with your expanded version, however, "x is equal to 5" is much more natural for me than "5 is equal to x". English idiom just doesn't compare constants that way - you don't say, "If Wednesday is today", you say "If today is Wednesday". > Then again, the code would be much more legible if it were: > [quoted text clipped - 5 lines] > All those line breaks between braces really cause a stutter in the flow > of the program Not to my eyes, which can much more easily ignore symbols than reorder things. > (not to mention that braces are completely unnecessary in > this case). They're unnecessary, but they're a bit like the "safety" version of comparisons in C - they avoid mistakes. They mean that: 1) It's obvious that the line is the "thing to do" if the comparison matches. Often if you have a multi-line condition, it's not obvious where the condition ends and the "thing to do" starts, without braces. 2) It makes it hard to make a mistake where you mean something to be in the same code block, but it doesn't appear in the code block. There are plenty of code convention documents around suggesting the uniform use of braces, regardless of whether they're strictly necessary - it's not just my idea... SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Remember that the original reason for using the form if (5 == x) { y = 6; } was to avoid the coding error in C/C++ that reports no errors: if (x = 5) { y = 6; } The later construct contains an assignment inside the 'if', and the assignment results in a non-zero value, which is treated as true, and so the assignment to the 'y' variable always takes place. The convention of placing the constant on the left side of expressions inside 'if' statements was to avoid this side-effect. While many compilers would report this as a warning, most developers were forced not to use the compiler setting that would report this, especially in the MS world since MFC reported so many warnings and errors. So this was a convention that resulted from the state of the language, the compilers and the development environments. In a UNIX project, for example, we used a compiler that enable this specific situation to be reported as an error, and so the convention of placing the constant on left of the expression was not required. With VB and C# this convention is not required -- it only applies to C and C++ where the language itself permits assignment within the 'if' statement expression. -ken > > If you are using the terminology "x is 5," you would be incorrect in any > > case. It would be proper to say "x is equal to 5," which equivocates to [quoted text clipped - 39 lines] > uniform use of braces, regardless of whether they're strictly necessary > - it's not just my idea... > > If you are using the terminology "x is 5," you would be incorrect in any > > case. It would be proper to say "x is equal to 5," which equivocates to [quoted text clipped - 9 lines] > you don't say, "If Wednesday is today", you say "If today is > Wednesday". Nicely and convincingly put John. I agree that 'constant == variable' is less 'natural' though it is as 'readable'. However, One can read 'constant == variable' and interpret it as 'variable is constant'. Everytime I see a line of code with 'constant == variable', it shocks me for a second while glancing over, and then I tell myself 'This style that appears less natural was followed as a safety mesure.' and proceed to the next line. If one does not program in C, C++, I agree that it's a good idea to use the more 'natural' syntax. Regards, Trilok. > Nicely and convincingly put John. I agree that 'constant == variable' is > less 'natural' though it is as 'readable'. > However, One can read 'constant == variable' and interpret it as 'variable > is constant'. Ah, but that takes extra effort. > Everytime I see a line of code with 'constant == variable', it shocks me for > a second while glancing over, Indeed - and that mental jolt means it's harder to read, IMO. Not *much* harder to read, but it makes a sufficient difference to make it worth avoiding where it's unnecessary. > and then I tell myself 'This style that appears less natural was followed as > a safety mesure.' and proceed to the next line. > > If one does not program in C, C++, I agree that it's a good idea to use the > more 'natural' syntax. Goodo :) SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too I'd have to say that it's fine that you think that way. Then again, you are not the wise one who gets to define what readability is, or what the most *natural* way of writing code is. Just think about this: How is written C# code natural anyway? It's man-made, and therefore whatever *works* for someone *is* most natural. This whole argument is relatively stupid. It's like complaining about those who use the incorrect brace style, since there is only One True Brace Style. >>you have to admit that no harm is done in this construct. > [quoted text clipped - 13 lines] > writing code in the most natural way - it's writing code in a way which > was developed to avoid a problem in a different language. >This whole argument is relatively stupid. it's not. see how many responses came for what you considered stupid. It means that different people see things differently. These differences lead to ambiguous code which results in misbehaved programs. SignatureRegards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27cok > I'd have to say that it's fine that you think that way. Then again, you > are not the wise one who gets to define what readability is, or what the [quoted text clipped - 23 lines] >> writing code in the most natural way - it's writing code in a way which >> was developed to avoid a problem in a different language. > I'd have to say that it's fine that you think that way. Then again, you > are not the wise one who gets to define what readability is, or what the > most *natural* way of writing code is. Just think about this: How is > written C# code natural anyway? It's man-made, and therefore whatever > *works* for someone *is* most natural. But it's not just about one person - it's about what works for whoever's reading the code. I've talked to lots of people who agree that the if (constant == variable) way of writing things is less naturally readable than the other way round, but they do it anyway for safety (in C/C++). That's fine. On the other hand, I have yet to meet anyone who believes that it's actually *more* readable - the *only* reason people use that convention is for safety, in my experience. That means that in a language where the safety isn't required (or rather, is obtained in other ways) the convention is counter-productive. > This whole argument is relatively stupid. It's like complaining about > those who use the incorrect brace style, since there is only One True > Brace Style. I agree that the bracing style argument is relatively stupid - but only because people can't agree on which is more naturally readable, and there don't seem to have been objective studies done. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too The real reason I saw from other's coding practices is to eliminate the following possible error : bool a = false; if ( a = true ) Console.WriteLine( "allo" ); You just assigned true to a and the if statement passes. But if you wrote if ( true = a ) Console.WriteLine( "allo" ); You get a compilation error -- cannot assign to a constant expression. So in the same vein writing if ( null == something ) is just in keeping with the idea that you write the constant expression on the left and make sure the compiler catches such possible mistake. Chris. > Suppose you ever go back to write a C program, the habit of writing (null == > something) would save you some trouble. [quoted text clipped - 33 lines] > > > Some didn't know that in C# that's not legal code, and others just > > > preferred to stick to their existing habits. > The real reason I saw from other's coding practices is to eliminate the > following possible error : > > bool a = false; > if ( a = true ) Console.WriteLine( "allo" ); So write it as the (more natural, IMO) if (a) { Console.WriteLine("allo"); } > You just assigned true to a and the if statement passes. Yup. And I can't remember the last time I wrote a conditional comparing the value of a variable with a boolean constant in that way. > But if you wrote > [quoted text clipped - 4 lines] > with the idea that you write the constant expression on the left and make > sure the compiler catches such possible mistake. Except the compiler catches is for every type other than boolean already: if (something=null) won't compile in C#. The equivalent would in C/C++, which is where the practice comes from - but aside from the incredibly rare occasions where you're comparing the value of a boolean variable with a constant, it's pointless and reduces readability. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too I'm not saying that's what I write... It's absolutly ugly.... That's just what I saw as guidelines from other 3rd party developers... It feels weird and unatural to me, but I did see this as a guideline in more than one place and that was the reason that was given. Yuck... Chris. > > The real reason I saw from other's coding practices is to eliminate the > > following possible error : [quoted text clipped - 32 lines] > where you're comparing the value of a boolean variable with a constant, > it's pointless and reduces readability. > I'm not saying that's what I write... > It's absolutly ugly.... > That's just what I saw as guidelines from other 3rd party developers... > It feels weird and unatural to me, but I did see this as a guideline in more > than one place and that was the reason that was given. It's a reasonable guideline in C/C++, although normally you can encourage the compiler to warn you if it looks like you've done it accidentally. In C#, however, it's an abomination. > Yuck... Exactly. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.