|
See the suggestion here[^].
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I first saw this technique in the stl where collections return
std::pair<iterator, bool> from their insert method. The bool indicating if the item was inserted or already existed.
Personally I dislike this, I find the names first and second which identify the pair's elements very misleading and find I'm constantly having to look at doco to see what something is. The worst case I've seen was along the lines of
pair<bool, pair<bool, bool> . How could anyone be expected to remember what result.second.first is?
I prefer to pass in a reference to a variable
eg
iterator map::insert(iterator position, const value_type& x, bool& wasAdded)
This has the disadvantage that the caller has to allocate a bool and pass it in even if they're not interested in the result (this can be overcome by using a pointer with default value of NULL but that's also ugly)
I blame python and its tuples for this outrage. What do others think?
|
|
|
|
|
Well, as long as we're talking about personal preferences.
I think that templates, in general, has uglied up the language by spraying < and > all over the place. I think somebody went nuts with this stuff and talked the language committee into using it. Plus the fact that it's not just the template definition that's affected but the coder has to use that syntax when referencing it had contributed to the unreadability of code.
I mean > is already used in pointer use (->) and in inequality tests (greater than) and then there's the right shift (>>) operator. Then somebody comes along to overload it for "cin" and other stream io. And don't get me started on <
I mean really, try writing code that takes some template result as a pointer to an object that you want to stream data into. Count the >'s. If they were right parens ) instead, it would remind me of early Lisp.
|
|
|
|
|
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!)
|
|
|
|
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)
