do any of you others have little coding mantras that save your behind?
-
One of mine is - when dealing with
IComparablein .NET "Greater than is less than" What it means is Convertingif(10>5);
to
IComparableit readsif(0<10.CompareTo(5));
Note '>' vs '<'
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Another reason to avoid "Yoda conditionals":
if (10 > 5)
if (10.CompareTo(5) > 0):)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
One of mine is - when dealing with
IComparablein .NET "Greater than is less than" What it means is Convertingif(10>5);
to
IComparableit readsif(0<10.CompareTo(5));
Note '>' vs '<'
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
My mantra is "Dammit! Dammit! Dammit!". Way back when learning C, to help me remember to add the extra equal sign when writing a conditional statement as opposed to an assignment I would say "Equals to" and press the equal sign == for each word and to say "Equals" and only hit the equal = sign once for assigning a value.
It was broke, so I fixed it.
-
One of mine is - when dealing with
IComparablein .NET "Greater than is less than" What it means is Convertingif(10>5);
to
IComparableit readsif(0<10.CompareTo(5));
Note '>' vs '<'
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
"Developers may come and go, but bugs will stay forever"
-
Something similar: Never compare floats for equality. It may bite sooner than later.
Yep. Been there, done that, got the scars on my back from self-flagellation for trying it.
Software Zen:
delete this; -
Think twice, write once.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
One of mine is - when dealing with
IComparablein .NET "Greater than is less than" What it means is Convertingif(10>5);
to
IComparableit readsif(0<10.CompareTo(5));
Note '>' vs '<'
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Mine applies to date comparisons. "Later is greater"
Steady Eddie (for those that never saw "The Hustler")
-
One of mine is - when dealing with
IComparablein .NET "Greater than is less than" What it means is Convertingif(10>5);
to
IComparableit readsif(0<10.CompareTo(5));
Note '>' vs '<'
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
"Check the plugs." Plugs being any of the following: - connection strings - method parameters - app settings "F5 and pray" Let-er rip and see what happens. Don't be afraid. 😁 I usually say a short prayer as my coffee is compiling / starting up.
-
One of mine is - when dealing with
IComparablein .NET "Greater than is less than" What it means is Convertingif(10>5);
to
IComparableit readsif(0<10.CompareTo(5));
Note '>' vs '<'
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Don't solve problems which don't actually exist. Like anything, this must be used in moderation. If there's a good, easy-to-understand abstraction you can implement which isn't required today , but you can see an obvious business case for it coming, go ahead. At the same time, be careful of overengineering just because you thought of some possible, but unlikely, abstraction. Design your code in such a way that can be implemented when the problem actually becomes something to solve.
-
Something similar: Never compare floats for equality. It may bite sooner than later.
That is also one of the mantras I preached when teaching programming. But even though we had been teaching the kids about limited precision, it was very difficut for the to understand that "if ((1/3)*3 == 1)" could fail. (Except that if you really used constants, or compile-time-evaluated expressions, an optimizing compiler might remove the entire "if".) Students often have a vague understanding of terms like "integer" and "float" (or "real"). So I preferred to refer to them as "counts" and "measurements". That made it a lot easier for them to understand how both integers and floats behave in the computer. One of the great details of the APL language is the environment variable quadFUZZ (if my memory of the name is correct): When comparing floats, if the difference is less than quadFUZZ, the values are treated as equal. (I belive that the fuzz was actually scaled by the actual float value, so it was a realative, not absolute tolerance, but I am not sure - APL is too long ago!)
-
My mantra is "Dammit! Dammit! Dammit!". Way back when learning C, to help me remember to add the extra equal sign when writing a conditional statement as opposed to an assignment I would say "Equals to" and press the equal sign == for each word and to say "Equals" and only hit the equal = sign once for assigning a value.
It was broke, so I fixed it.
-
Another reason to avoid "Yoda conditionals":
if (10 > 5)
if (10.CompareTo(5) > 0):)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
one of those looks like a bug.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
That is also one of the mantras I preached when teaching programming. But even though we had been teaching the kids about limited precision, it was very difficut for the to understand that "if ((1/3)*3 == 1)" could fail. (Except that if you really used constants, or compile-time-evaluated expressions, an optimizing compiler might remove the entire "if".) Students often have a vague understanding of terms like "integer" and "float" (or "real"). So I preferred to refer to them as "counts" and "measurements". That made it a lot easier for them to understand how both integers and floats behave in the computer. One of the great details of the APL language is the environment variable quadFUZZ (if my memory of the name is correct): When comparing floats, if the difference is less than quadFUZZ, the values are treated as equal. (I belive that the fuzz was actually scaled by the actual float value, so it was a realative, not absolute tolerance, but I am not sure - APL is too long ago!)
Oddly enough, I can't remember any problems you're talking about from my own experience. And I am not even a programmer by trade, I've studied physics and programming was a side-gig at first. To me, integer numbers are exact and floats are, as it's impossible to represent arbitrary numbers with discrete values, approximations. They may be good enough for daily use, but they may fail and when they do, they fail. Maybe that's why I didn't have any problems, the concept of approximations is deeply nested in a physicist's mind. Well, that and I've recently built a system which used integer for it's measurement values (mostly because the sensor returns integers by the value of 0,01°C). So your vocabulary would have spectacularily failed me :D
-
Something similar: Never compare floats for equality. It may bite sooner than later.
Don't compare datetimes for equality, either, particularly if they don't all come from the same 'source'.
-
Don't compare datetimes for equality, either, particularly if they don't all come from the same 'source'.
That, on the other hand, may work just fine. Depends on the language/runtime library and the source of the dates, but when I want to know if some date is today, equality works. Again, assuming the runtime library helps and you know what you're doing. There's a reason why TheDailyWTF has a couple stories on mishandling time stamps. I suppose, we could amend "Don't run home-built date/time handling" to the list of useful mantras. There's heap tons of ways to get them wrong and even if you test all you can, it may fail when a leap year occurs.
-
One of mine is - when dealing with
IComparablein .NET "Greater than is less than" What it means is Convertingif(10>5);
to
IComparableit readsif(0<10.CompareTo(5));
Note '>' vs '<'
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Well, I more or less always knew that my greatest weakness was my tendency to want certain sections of my code to be bug free. That kind of code-blindness causes extra work when debugging. Through the years I have advanced to the point where I can realize now that I write loads of lines of bugs encapsulating some small bits of perfectly functional code. I'm actually a decent debugger now, I'm still working on the programming part.
-
Well, I more or less always knew that my greatest weakness was my tendency to want certain sections of my code to be bug free. That kind of code-blindness causes extra work when debugging. Through the years I have advanced to the point where I can realize now that I write loads of lines of bugs encapsulating some small bits of perfectly functional code. I'm actually a decent debugger now, I'm still working on the programming part.
AnotherKen wrote:
I'm actually a decent debugger now, I'm still working on the programming part.
Ha! relatable content :-D
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
One of mine is - when dealing with
IComparablein .NET "Greater than is less than" What it means is Convertingif(10>5);
to
IComparableit readsif(0<10.CompareTo(5));
Note '>' vs '<'
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
The REALLY big mistake is that the C# designers carried forward the old C way of reporting something non-numeric as if it were a numeric. IT IS NOT! The value of comparing A with B is either "A is less", "They are equal", or "B is less", NOT -1, 0 or 1. C# did abandon pointers as integers - "if (pointer)" is not valid; you must test "if (pointer != null)". They should have completed the job! Every now and then I get so frustrated over this that I write a thin skin for the comparisons, casting those inappropriate integers into an enum. But C# doesn't really treat enums as a proper type, more as synonyms for integers, so it really doesn't do it; it just reduces my frustration to a managable level.
-
The REALLY big mistake is that the C# designers carried forward the old C way of reporting something non-numeric as if it were a numeric. IT IS NOT! The value of comparing A with B is either "A is less", "They are equal", or "B is less", NOT -1, 0 or 1. C# did abandon pointers as integers - "if (pointer)" is not valid; you must test "if (pointer != null)". They should have completed the job! Every now and then I get so frustrated over this that I write a thin skin for the comparisons, casting those inappropriate integers into an enum. But C# doesn't really treat enums as a proper type, more as synonyms for integers, so it really doesn't do it; it just reduces my frustration to a managable level.
The problem with that is they may not be 1, 0 or -1. Any positive value and 1 are going to have to be treated the same, and the same goes for the negative values - they're all -1, basically. But other than that, yeah. Although hate enums, because .NET made them slow. I still use them, but they make me frustrated. So usually in my classes where I don't want to burn extra clocks like my pull parsers I use an int to keep state, and cast it to an enum before the user of my code touches is.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
That, on the other hand, may work just fine. Depends on the language/runtime library and the source of the dates, but when I want to know if some date is today, equality works. Again, assuming the runtime library helps and you know what you're doing. There's a reason why TheDailyWTF has a couple stories on mishandling time stamps. I suppose, we could amend "Don't run home-built date/time handling" to the list of useful mantras. There's heap tons of ways to get them wrong and even if you test all you can, it may fail when a leap year occurs.
Pure dates are generally not a problem, as long as you (or the coder from whose output you are getting the date) don't/didn't do something very stupid. Even here, however, timezone issues can cause problems. I once had an issue which resulted from the author of the firmware of a device I was getting data from recording what should have been a pure (midnight) datestamp as the corresponding local datetime. Since I am in the GMT-5 timezone, midnight on April 4 became 7 pm on April 3! Trying to compare datetimes for simultaneity, however, is almost always a severe PITA, when the source clocks are not both perfectly synchronized and using the same basic internal representation for clock time.
-
One of mine is - when dealing with
IComparablein .NET "Greater than is less than" What it means is Convertingif(10>5);
to
IComparableit readsif(0<10.CompareTo(5));
Note '>' vs '<'
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
If it ain't broke, fix it 'til it is. Oh, hang on - save your ass, you say?
