|
Chuck O'Toole wrote:
I think that templates, in general, has uglied up the language by
spraying < and > all over the place.
True, C++ is now almost unreadable due to templates.
==============================
Nothing to say.
|
|
|
|
|
That's c for you though.'&' is similarly overused.
pair<int, pair<int, int>>
confuses most compilers, you need
pair<int, pair<int, int> >
|
|
|
|
|
typedef pair<int, int> IntPair;
typedef pait<int, IntPair> IntIntPair;
Won't this makes your life simpler?
|
|
|
|
|
Yeah, I always thought the same about templates... make everything hard to read.
|
|
|
|
|
_Josh_ wrote: What do others think?
Rich syntax has nothing to do with maintainable code.
"Clever" coding tricks demonstrates that one has mastered a language while at the same time demonstrating that one hasn't mastered software development (which of course includes much more than just producing code.0
|
|
|
|
|
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?
|
|
|
|
|
Yes, it has saved me.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Oh, I'm sure it saved somebody some debugging time. "saved" is a bit of a stretch unless somebody would have released something with insufficient testing. And if they do that, there'd be plenty of other bugs that will bite them due to the lack of testing.
Personally, I hate it too. I tend to read code like English, left to right, and reading it as "if my pointer is null" is more natural for me than the other way around. Speakers of other native languages may find the other order more natural.
In my opinion, if you are writing code that will be maintained by someone else, a support team or other engineers as you move on to bigger projects, then "readability" is more important. Readability include code structure / indents, comments (meaningful), reasonablly neumonic variable and function nammes, and making if statements readable as they convey the "branching logic" of the program.
|
|
|
|
|
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_» 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() ) {
}
Fortunately I don't see that kind of code so often anymore, making this warning a perfectly reasonable and useful alternative.
|
|
|
|
|
Even I love this. 
Putting constant at left hand side surely saves from missing '='. The earlier compilers were not intelligent to raise a warning like the latest ones. That might have forced people like me to cultivate this habit. Otherwise one had to debug code to find such kind of bug (Some great minds might have found these kind of bugs with their open eyes, I won't deny that as well). But surely it wont give u a chance to debug the code to find such bugs. That's my personal opinion.
|
|
|
|
|
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 as
if(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 
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++) or BOOL (C/Microsoft) then I don't mind the if (bCondition) or even if (!bCondition). What kills me is if the variable is an int or 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.
|
|
|
|
|
Chuck O'Toole wrote:
if (!iVar)
to mean "if iVar is equal to zero" just drives me crazy.
I second that.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Thirded. 
|
|
|
|
|
Yup I hate that too!
Starting 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.
|
|
|
|
|
_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"). 
|
|
|
|
|
_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.
|
|
|
|
|
I have no problem at all, and in fact prefer the form
if (bcondition)
provided bcondition is of type bool. 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...)
|
|
|
|
|
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!)
|
|
|
|
|
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.
|
|
|
|
|
_Josh_ wrote: I have a colleague working with me at the moment and he loves to do this (NULL
first) and I hate it.
If I was working somewhere where that was the most significant problem in the code base then I would be ecstatic.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
