31–40 of 66 posts
Earlier quoted context omitted.
You're still making two function calls when you could be making one. If one of them gets lost in the fray, you'll spend just as much time solving that problem.
Are the costs of function call overhead worth worrying about?
Which is more expensive, a few milliseconds of machine time a few million times or a whole bunch of human time once or twice?
Earlier quoted context omitted.
You're still making two function calls when you could be making one. If one of them gets lost in the fray, you'll spend just as much time solving that problem.
Are the costs of function call overhead worth worrying about?
Earlier quoted context omitted.
"I'd rather detect an error and bail then have a slew of nested ifs." And here's what inevitably happens when you do that: 14 mods are applied and your early exit(s) get lost in the muck. Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months. Then I come along, find the errors, fix the data ba…
That's why "return" (and "throw" and "assert") is syntax-highlighted in most editors. ;-) Honestly, I've never had a case where I visually missed an early exit. Most of the time, such exits are guard statements, designed to bail out with an exception if some precondition isn't met. Most of the rest, they're "found it, don't need to do any more processing" and apparent from the logic. I'll usually mark the latter with…
Too bad the same's not true for those I have followed. And when it does happen, it makes the worst kind of mess - the kind you don't discover until 6 months later.
Guidelines and rules are not meant for the best of us; we don't need them as much. They're meant for the mediocre masses who are everywhere and wouldn't know any better.
Earlier quoted context omitted.
"Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months." I can certainly see how this is true in a large organization which hires lots of mediocre programmers. However, if you're in a company where the other programmers are top notch, this sort of thing is not a problem. In fact, if I ever see…
"if you're in a company where the other programmers are top notch" I've never seen such a thing (and I've seen alot). Reason #127 for starting your own.
Earlier quoted context omitted.
Early returns make code more readable. I'd rather detect an error and bail then have a slew of nested ifs. It isn't always about being clever.
"I'd rather detect an error and bail then have a slew of nested ifs." And here's what inevitably happens when you do that: 14 mods are applied and your early exit(s) get lost in the muck. Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months. Then I come along, find the errors, fix the data ba…
Earlier quoted context omitted.
Early returns make code more readable. I'd rather detect an error and bail then have a slew of nested ifs. It isn't always about being clever.
"I'd rather detect an error and bail then have a slew of nested ifs." And here's what inevitably happens when you do that: 14 mods are applied and your early exit(s) get lost in the muck. Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months. Then I come along, find the errors, fix the data ba…
Cue the blame-the-programmer-for-not-being-smart-enough comments.
Guys. The goal isn't to provide the "perfect" code that somehow those poor average schmucks just can't understand. The goal is to provide the dumbest, easiest-to-follow narrative of how the computer is going to solve the problem for the user so that the next guy is able to understand it.
Earlier quoted context omitted.
(6) Happens even when you know better. (10) Good programmers don't repeat themselves, true, and to continually improve as a programmer it is important to patiently do everything correctly the first time. However, obsessing over a few bits of code duplication is often a complete waste of time.
"obsessing over a few bits of code duplication..." Applying good coupling and cohesion principles is not obsessing. It's as much legitimate programming as writing an equality test.
Perfect programmers may manage to avoid duplicating code on the first try. But unless we have dozens of Mozarts posting here I'd guess that no one qualifies. That means we make mistakes, and the question of whether correcting those mistakes is good practice or obsession depends on the circumstances.
Earlier quoted context omitted.
"obsessing over a few bits of code duplication..." Applying good coupling and cohesion principles is not obsessing. It's as much legitimate programming as writing an equality test.
It is obsessing if it detracts from the end product. I'm not saying DRY isn't good practice or that chunks of code duplication are just fine and dandy. However, bits of code duplication are hardly a viable litmus test for judging quality of a programmer. When an actor screws up a line in a performance, he can't afford to stop and correct it. In fact, if he stops to correct a meaningless line he'll cause far more dama…
I think from your comment, we can agree that there are two scenarios to consider: when the programmer is in control of the product and when the schedule is in control of the product. "Programming is not always so time-and-performance-sensitive, but it's not time-insensitive either."
Here's the deal: when you stop your design process and kick the compiler up and start coding, you haven't stopped your design work at all, you've simply switched from top-down to bottom-up design. Every line of code you write is a validation/denial of the assumptions and planning you're supposed to do before you start. If you're not refactoring aggressively as you go along, you're not taking the chance to see where your code is supposed to be going: you're simply trying as hard as you can to get to point B from point A. It's like driving a car from one side of the field to the other by letting go of the steering wheel and hoping it gets there okay. Most of the time you make it to the other side just fine, but you have zero control over where on the other side you're going to end up.
To me, that's hacking, and I mean in a bad way. I've been known to hack like a freaking electric weed-eater, trust me! But that's when something else is out of whack on the project. It's a sign that there are serious problems. When you're doing it right, your code is constantly evolving as you refactor to the point where changes become less and less of an issue. So good programming means you spend all the time necessary to refactor with the knowledge that you'll going to make it back in spades later on.
It's like when playing rummy, and you decide to pick up a huge stack of cards. At first, it seems like a crazy move, but if you know how to play the game, you realize that the only way to win is to constantly redefine the problem domain of what you have in your hand. Hacking doesn't get you that -- it just gets you to point B no matter what. It may not be the sign of poor programmer, but it's definitely a red light that something is out of whack somewhere.
My opinion only. Your mileage may vary. Do not attempt to drive heavy machinery after reading my comments. Consult a physician before beginning a regimen of refactoring. Etc.
Earlier quoted context omitted.
"if you're in a company where the other programmers are top notch" I've never seen such a thing (and I've seen alot). Reason #127 for starting your own.
reason #1 to get a new job. You might have seen a "lot", but you've seen a lot of the wrong thing.
Earlier quoted context omitted.
0. You refuse to use recursion even when working with a language that supports it properly because you think it's horribly slow.
"a language that supports it properly..." Meaning what exactly? A language that automatically optimized for tail recursion? Are there languages which don't support recursion "properly?"
edit: I just realized what I actually mean. Some programming languages, or the culture/community around them, do not seem to encourage certain things that can be done with the language. In the case of C/C++, while/do/for loops are used before recursion. In the case of Scheme, you try a recursive solution first and then go for a do-loop if you really need to...or something like that.