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.
"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?
-
I have a few. The popular "if you're doing single line if statements you're doing it wrong." The equally catchy "only psycho's don't put spaces between their operands and operators." And my personal favorite "what would codewitch do, do the opposite." :D And one that's not so much related to code, but to specs. If it'll never happen, it'll happen soon (or it'll never never happen, but people don't tend to understand that one).
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
The popular "if you're doing single line if statements you're doing it wrong."
I had done quite a bit of Pascal programming when C came onto the scene. I have heard numerous arguments in favor of C, as opposed to Pascal. One of the major arguments against Pascal was "All that writing! All those keywords! It is almost like COBOL!" Essentially this referred to BEGIN-END. One-keystroke braces makes programming sooooo much faster... I have argued a lot about the impact on productivity from two or three extra keystrokes. Or fewer! Before C, no modern language required parentheses around a condition! No modern language required putting braces (or other delimiters) around single statements! The parser expects a block, and a single statement is a block! Then came this craze for LOC/day prouctivity measure. "My LOC/day is bigger than your LOC/day! So there!" The more lines you can spend on trivial things, the better programmer you are. Rather than
if ExpectedRainfall > 0 then BringTheUmbella;
you write
if (ExpectedRainfall > 0)
{
BringTheUmbrella();
}- some programmers would even give the "if" its own line, putting the condition on a separate line. And lots of C programmers consistently add blank lines around every conditional statement and every loop. In the days of hardcopy listing, I frequently printed out source code double-spaced to give the impression of a lot of blank lines to make the code more readable. Screens were 24 lines tall at that time - that is not much. I wanted it to display 24 useful code lines, not twelve blank lines. I wanted that IF statement to use one of the 24 lines, not 4 or 5, plus a blank line. With C, we replaced a four-character keyword with two sets of (), one set of {} and 3-5 more line breaks, to reduce all that typing of writing "then"... But the modern mantra is "doing it like that single-line Pascal statement is wrong! The 4-5 line (+ blank line) solution with three sets of delimiters added is the right way to do it". I miss Pascal!
-
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 return
null. Throw an exception instead. Removes need to null check everything. Hopefully give a more meaningful error when a problem occurs.
