|
Code is written for people, not computers.
|
|
|
|
|
May I just point out that C++ is a different language? Why would a C++ veteran be given a pass on something like this? If I started doing things in C# because that's the way we had to do them in VB6 or JavaScript, I would get laughed out of this forum.
I don't care if the compiler optimizes this away, it's the fact that it's there to begin with that is the problem.
|
|
|
|
|
I have seen such stuff many, many times. They always claim that such approach makes it "easier to read". But the question arises: "For whom?" Don't want to answer, because it will be abusive for some. But writing such sort of a code is the same (yes, it is) as putting the caption "car" on a car (you can make up more examples if you wish). Thanks, I noticed 
|
|
|
|
|
This particular redundancy is a bit crude, but I've seen others that, while technically just as redundant, struck me as quite forgivable. The dividing line for me is whether the redundancy aids legibility or maintainability. If it contributes to either of those virtues, I'm inclined to shrug.
Of course, "cut-and-paste" redundancies, which replicate code merely to avoid having to think about generality and modularization, are not forgivable, as they degrade maintainability. But that's grammar-school stuff; a programmer who doesn't grasp it should consider hanging it up and going to work in a coal mine.
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
Redundancy in code redundancy
modified 20-Oct-19 21:02pm.
|
|
|
|
|
The value of true may change.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
That way, ternary operator sucks a bit less. 
|
|
|
|
|
This could have been written because there is an annoying compiler warning with Visual Studio about coercing an integer to a boolean type.
Quite a lot of useless code has been written to silence compiler warnings.
|
|
|
|
|
It wouldn't have to coerce an integer to a boolean...
|
|
|
|
|
At least it wasn't:
popToSelectedButton.IsEnabled = !(historyListBox.SelectedItems.Count > 0) ? false : true;
That kind of thing doesn't not happen all the time!
- Life in the fast lane is only fun if you live in a country with no speed limits.
- Of all the things I have lost, it is my mind that I miss the most.
- I vaguely remember having a good memory...
|
|
|
|
|
Forogar wrote: That kind of thing doesn't not happen all the time!
So true! I don't often see the use of double negatives used "properly" in English, so I automatically corrected it in my head to what you "really" meant. That didn't make sense. Ah, you intentionally mangled the English to get an expression as valid as your code example.
Your mangled code is superior to the one I came up with. ...== 0) ? false : true;
|
|
|
|
|
5 stars... that made me laugh.
|
|
|
|
|
I do this when converting bool to BOOL or back, for two reasons.
1. Code clarity.
2. Eliminate warnings.
And as someone else pointed out, conditional expressions didn't always return a bool type. They used to return integers. So this could just be habit.
|
|
|
|
|
Not in C#, I hope!
(This is from MSDN's WinPhone SDK, so obviously not C/C++)
|
|
|
|
|
Obvious to folks developing in that arena I'm sure.
|
|
|
|
|
Rob Grainger wrote: OK, its harmless enough..
True, but its obfuscating redundancy, and its begging to be abused or typoed into something like:
popToSelectedButton.IsEnabled = (historyListBox.SelectedItems.Count > 0) ? false : true;
and that would be harmful.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
It seems to be a characteristic of Microsoft programmers, that they want to prove they are clever by producing less readable code.
At times, the attempts at "clever" also makes the code a bug. It took me a week to convince the manager this was a bug:
if ((CurrentThreadCount - StepThreadCount) <= MaxThreadCount) getMoreThreads();
And that was clear-cut code, not even close to "clever". Three to five seconds after I first read it, I saw the bug correction needed:
if ((CurrentThreadCount + StepThreadCount) <= MaxThreadCount) getMoreThreads();
(It did take me about 40 seconds to verify in my mind my first thought for a correction was correct and about 15 minutes to go through the code and verify the names and method did what was suggested.)
What I did like about it was that the variable and method names were so clearly doing what the names suggested was being done.
|
|
|
|
|
Filed under [Clock Cycle Fetish]
|
|
|
|
|
It might not be so bad depending on the context. If this code was ported into C then it might avoid a problem in interpreting what true and false actually are. Then again might have been C code originally and simply copied into place ...
|
|
|
|
|
If you're writing code in which the meaning of true and false are in question, this would be the least of your problems at a guess. I've never experienced such issues, and I code widely in C, C#, C++, JavaScript, occassionally D and Java. I'm assured no such issues are common moving to PHP either by my learned friend.
|
|
|
|
|
I was speaking in the context of C and where some systems have macros defined for TRUE and FALSE. Sometimes I've seen those macros setup as (1==0) and (1==1) or simply 0 and 1 or 0 and -1. On several systems I've worked on GOOD and BAD have been used for an error flag and many programmers might assume GOOD and BAD are true and false and they are not.
As ever with C, if in doubt be as explicit as you can be to avoid the compiler making choices for you. Most of the times you get away with those choices. Sometimes, for example when porting to another platform and compiler, you don't.
Another common problem with porting C code is the difference between short, int, long and long64 (or whatever). What an int could actually be can cause all sorts of problems in porting scenarios.
|
|
|
|
|
OK, by Hall Of Shame standards, this isn't too bad. Still worth sharing...
KeyValuePair<DateTime, string> lastItem;
if (lastItem.Value != null && lastItem.Value.ToString().Trim() != "")
{
Three things jump out at me:
1. Use of empty string literal instead of String.Empty
2. Seperate testing of null and empty string instead of String.IsNullOrEmpty()
3. Calling ToString() on something that is already a string.
#1 and #2 isn't too serious, especially if you consider that you also want to trim the string, so you need to check for null before trying to trim anyway. #3, on the other hand, confuses me. Why would you want to call ToString() on a string?
|
|
|
|
|
Maybe it wasn't always a string?
|
|
|
|
|
I think a coder is stringing you along.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
If the codebase originated from a dotNet1.1 codebase, then the statement makes complete sense because string.IsNullOrEmpty did not exist at that time.
Something that would definitely get updated in a code review: yes,
Horror: close, but not quite.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
