if(NULL == MyPointer)
-
I have a colleague working with me at the moment and he loves to do this (NULL first) and I hate it. Has anyone actually ever been saved from putting a bug into production because this construct has saved them from missing an '='? Is there any other reason to do it?
I understand the reason people give for doing this, but as far as I'm concerned if you can remember to reverse these conditions then you can also bloody well remember to get the number of '='s right.
David Anton Convert between VB, C#, C++, & Java www.tangiblesoftwaresolutions.com
-
I have a colleague working with me at the moment and he loves to do this (NULL first) and I hate it. Has anyone actually ever been saved from putting a bug into production because this construct has saved them from missing an '='? Is there any other reason to do it?
-
looks like you are new to programming? Not sure, but when I was a fresher I used to hate my colleague writing
if(bCondition)andI purposefully wrote my lines asif(bCondition==TRUE)Then I realized I'm stupid if I followed my "spoken" code way. So, in short it's the correct form to keep the constant on the left. Don't do the other way and don't hate your colleague :-DStarting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
VuNic wrote:
looks like you are new to programming?
No
VuNic wrote:
if(bCondition)
andI purposefully wrote my lines as
if(bCondition==TRUE)Hungarian notation? tisk tisk
VuNic wrote:
So, in short it's the correct form to keep the constant on the left
I disagree, it's a matter of preference and as others have pointed out most compilers will produce a warning if the warning level is set correctly.
-
VuNic wrote:
looks like you are new to programming?
No
VuNic wrote:
if(bCondition)
andI purposefully wrote my lines as
if(bCondition==TRUE)Hungarian notation? tisk tisk
VuNic wrote:
So, in short it's the correct form to keep the constant on the left
I disagree, it's a matter of preference and as others have pointed out most compilers will produce a warning if the warning level is set correctly.
_Josh_ wrote:
Hungarian notation? tisk tisk
. What? Hungarian Notation going out of style? Hey, I'm just getting into it having finally stopped following Fortran II notations of variables starting with I thru N are integers, everything else is floating (aka "real"). :)
-
I have a colleague working with me at the moment and he loves to do this (NULL first) and I hate it. Has anyone actually ever been saved from putting a bug into production because this construct has saved them from missing an '='? Is there any other reason to do it?
Over the past 20+ years, yes, this has saved me a couple dozen times. It's so much faster to just quickly fix a compiler error than hunting down some weird bug that can express itself in all kind of ways, but usually nowhere near the context of the actual source of the problem. And no, there is no other reason that I am aware of. I don't need any.
-
I understand the reason people give for doing this, but as far as I'm concerned if you can remember to reverse these conditions then you can also bloody well remember to get the number of '='s right.
David Anton Convert between VB, C#, C++, & Java www.tangiblesoftwaresolutions.com
In my experience, this is not true. Typing '=' instead of '==' is as often a real typing error as it is a coding oversight. I even go so far as to always put the constants on the left hand side in all comparisons, so I don't forget to do so on equality operators. I never ever had a '='/'==' error since I started using this practice some time around 1990. (I did fix quite a few such errors caused by others though, and I can tell you that kind of work is not pretty!)
-
This has helped me detect the problem, but I cannot say that it would've gone into production code because it would surely be detected during testing. But nevertheless, it was a good trick to detect the typo. However, it was not fool proof because sometimes we would need to compare 2 variables instead of a variable and a constant. In such cases a single equal sign would make the assignment and you would get unexpected results. Having said all this, I don't think it is necessary to write the constant first anymore with the current compilers because it would surely give you a warning. For example, VS 2010 shows the C4706 warning. I'm not sure about other compilers like GCC.
«_Superman_» _I love work. It gives me something to do between weekends.
«_Superman_» wrote:
For example, VS 2010 shows the C4706 warning.
Yes, that is in fact a very good alternative, specifically if you set warnings=errors for production code. At the time I started using the practice there were no such warnings, and thus no such elegant alternative. Also I remember quite a few typical constructs that deliberately used assignments, such as
if ( errorcode = foo() ) {
// error occurred!
// ...
}Fortunately I don't see that kind of code so often anymore, making this warning a perfectly reasonable and useful alternative.
-
looks like you are new to programming? Not sure, but when I was a fresher I used to hate my colleague writing
if(bCondition)andI purposefully wrote my lines asif(bCondition==TRUE)Then I realized I'm stupid if I followed my "spoken" code way. So, in short it's the correct form to keep the constant on the left. Don't do the other way and don't hate your colleague :-DStarting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
I have no problem at all, and in fact prefer the form
if (bcondition)
provided
bconditionis of typebool. I hate it though when the variable in question is, in fact, an int or similar, especially when it can take more than 2 values (e. g. when interpreting error codes, where sometimes 0 indicates failure, and on other occasions 0 indicates success and anything else is an enumerated code...) -
Ha, I have the opposite problem. If the variable is decleared to be
bool(C++) orBOOL(C/Microsoft) then I don't mind theif (bCondition)or evenif (!bCondition). What kills me is if the variable is anintor similar and that short cut is used just because it evaluates to a zero/non-zero test. Damnit, write:if (iVar != 0)
or
if (iVAR == 0)
if that's what you're testing for and don't use the "boolean variable" if notation.
if (!iVar)
to mean "if iVar is equal to zero" just drives me crazy.
Thirded. ;)
-
In my experience, this is not true. Typing '=' instead of '==' is as often a real typing error as it is a coding oversight. I even go so far as to always put the constants on the left hand side in all comparisons, so I don't forget to do so on equality operators. I never ever had a '='/'==' error since I started using this practice some time around 1990. (I did fix quite a few such errors caused by others though, and I can tell you that kind of work is not pretty!)
Yes that's true. I've had some serious problems in algorithms because of this == typo. That killed me for days. I think all these recent compilers take strain to point out this type of typos. But older ones just wait for you to make one and kill you. :) Eversince I got my fingers burnt on this, I put the constants on the left for ever! unless I'm typing something for fun.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
-
Ha, I have the opposite problem. If the variable is decleared to be
bool(C++) orBOOL(C/Microsoft) then I don't mind theif (bCondition)or evenif (!bCondition). What kills me is if the variable is anintor similar and that short cut is used just because it evaluates to a zero/non-zero test. Damnit, write:if (iVar != 0)
or
if (iVAR == 0)
if that's what you're testing for and don't use the "boolean variable" if notation.
if (!iVar)
to mean "if iVar is equal to zero" just drives me crazy.
-
VuNic wrote:
looks like you are new to programming?
No
VuNic wrote:
if(bCondition)
andI purposefully wrote my lines as
if(bCondition==TRUE)Hungarian notation? tisk tisk
VuNic wrote:
So, in short it's the correct form to keep the constant on the left
I disagree, it's a matter of preference and as others have pointed out most compilers will produce a warning if the warning level is set correctly.
_Josh_ wrote:
I disagree, it's a matter of preference and as others have pointed out most compilers will produce a warning if the warning level is set correctly.
Real men work on turbo C++.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.