tag:blogger.com,1999:blog-6800934446457898793.post4759922338859758365..comments2010-07-04T08:48:54.994-04:00Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-6800934446457898793.post-20315987375303634972008-03-18T06:18:00.000-04:002008-03-18T06:18:00.000-04:00This is a very interesting fact but I think it is not very helpfull for improved developers. I wrote constants to the right my whole time as a programmer. If I start to watch my fingers not to do so I can also watch my fingers not to forget the second '='. But maybe this idea would be nice in new books for greenhorns. Schoolbooks like "Starting programming in C++" or so. They could start programming this good style.<BR/><BR/>Whatever... this is a point of view I never had and so it is a very interesting post at all. Never the less the fact with the string is usefull! :)knucKleshttp://www.blogger.com/profile/03143400354180065062noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-36257207261273394772008-03-17T10:48:00.000-04:002008-03-17T10:48:00.000-04:00Of course, string.Equals(s1,s2,a3) does not throw a NullPointerException whereas string.Equals(s1, a3) does...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-31222380797459020392008-02-18T12:44:00.000-05:002008-02-18T12:44:00.000-05:00Brian: Good point about NUnit's AreEqual(x,y) order. I never made the connection. <BR/><BR/>I use Visual Studio 2008's built in unit testing and they copied NUnit's precedent (from JUnit probably). It seems that <I>that</I> particular order has now become defacto for assertions. <BR/><BR/>There is some resemblance to the order of the "source" and "destination" variables in the standard C string libraries (where destination comes first). <BR/><BR/>In that case, it doesn't make as much sense to me why the subject (source) comes after the object (destination).Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-59332779291811660482008-02-18T12:23:00.000-05:002008-02-18T12:23:00.000-05:00Beautiful post. Thanks for sharing the history lesson on the Koite-Greek language, I have never heard about it before. <BR/><BR/>In NUnit, whenever you want to assert an expectation, the first parameter is always the "expected" value, then the "actual" value, i.e., Assert.AreEqual(expectedValue, actualValue). I think the same logic should be apply in the boolean conditions (if expectedValue == actualValue)...<BR/><BR/>But even though I say that, I myself prefer to write the if (actualValue == expectedValue) for the only reason that I'm used to it. But that's not a good reason! Even though changing a programming style is hard, it is not impossible. And like you said, it sure minimizes the possiblities of runtime errors or bugs in the long run.Brian Di Crocehttp://blog.briandicroce.comnoreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-192077884482480142008-02-16T19:36:00.000-05:002008-02-16T19:36:00.000-05:00Interesting. I should look at more Python code.Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-83649920767997748752008-02-16T17:40:00.000-05:002008-02-16T17:40:00.000-05:00its seems kinda python to do it that way.<BR/>many of the examples ive studies while learning python the past year have been just like this. for example <BR/>" ".join(someString)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-87743553372646448362008-01-26T07:56:00.000-05:002008-01-26T07:56:00.000-05:00Brian,<BR/><BR/>I wish it was more common practice. I think that if it had been like this from the early days, it would have saved our industry countless hours of grief like you mentioned. <BR/><BR/>Unfortunately, it's almost too entrenched in our way of thinking. At least C# makes it harder to do the first (value = constant) in a place where a boolean is expected. Unfortunately, it offers no help in the string comparison example. Hopefully Spec#'s ideas will creep into C# and help eliminate those.<BR/><BR/>However, you could be a revolutionary and use it in your own code :)Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-55417862493246474252008-01-26T00:00:00.000-05:002008-01-26T00:00:00.000-05:00It really seems that something that is this simple and this right should just be done. I speak English, and I don't have a hard time following the code this way.<BR/><BR/>I also don't know how many times I've debugged the "if (this = 5)" type of code when I meant "if (this == 5)".<BR/><BR/>Although, instead of "5", it would probably be some kind of enum, which I don't think can be assigned to either so it would work the same.Brian Lakstinsnoreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-48359878774964233572008-01-23T18:48:00.000-05:002008-01-23T18:48:00.000-05:00I thought the "constant".Equals(...) trick was clever when I read it. I wonder how weird the approach feels to people who read right to left (e.g. Hebrew natives)Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-85032713278366685592008-01-23T12:32:00.000-05:002008-01-23T12:32:00.000-05:00interesting idea!<BR/><BR/>I wonder if this already falls under the category "too clever".Anonymousnoreply@blogger.com