do any of you others have little coding mantras that save your behind?
-
only twice? I find a bout of analysis paralysis followed by headdesking a few times is really the way to go. :laugh:
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.
It's a metaphorical twice as in more than once. Although I have found sometimes just taking a shot in the dark can be useful if you can learn from failure.
"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?"
-
It's a metaphorical twice as in more than once. Although I have found sometimes just taking a shot in the dark can be useful if you can learn from failure.
"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?"
I hear you. I just did that. But I learned from success. I mean, I was working from some sample code, in C++, on implementing B+ trees, but I ported it to C# and then rewrote it using .NETisms and adding features. Then I realized it was almost pointless without a little database system going with it because it only optimized situations where nodes are directly tied to disk access. On the other hand, I did the same thing with the regular B tree and it worked flawlessly, and is useful as an in-memory autobalancing tree structure (inserts and deletions are slow, searches are very fast and consistent - every search takes the same number of comparisons) so woo. but i guess someone already implemented one here. Not sure how mine stacks up, but it works.
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.
Something similar: Never compare floats for equality. It may bite sooner than later.
-
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.
-
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!)
-
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.
-
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.
-
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.
