5 ms·

Don't solve with conditionals that which can be solved by your language's dispatch mechanism.

by calambrac 17y ago

tptacek 17y ago
Don't solve with 15 minutes that which you can bill your client 80 hours for.
- stcredzero 17y ago
  And don't forget, lots of those 15 minute intervals can add up to serious money. ("Stovepipe" systems.) You can also set up an opportunity to bill for coming later in and "fixing" a seemingly intractable big mess.
  - Confusion 17y ago
    Do not attribute to malice what can be equally well explained by stupidity.
    - stcredzero 17y ago
      Malice has a better chance of sustained profitability. EDIT: This is a clue to bad intent. "Follow the money!"
      - stavrianos 17y ago
        and yet, the world over, people are still both basically decent and basically stupid. Edit: correlation?
  - tptacek 17y ago
    "Oh, I see the problem right here, Mr. Client. Your previous consultant used 'if' statements. Here, let me replace that function with 80 new class files. You'll be much more agile!"
    - stcredzero 17y ago
      I find that the opposite is true: replacing lots of runtime type identification with polymorphism results in placing repeated code in just one place. Don't Repeat Yourself is more agile. Even better: wait until at least the 3rd repetition before refactoring. (But don't wait too long.) This cuts down a lot of unnecessary coding, and leaves the programmer some leeway for good judgment.
- calambrac 17y ago
  In retrospect, my comment sounded like it was reaffirming the article's point, but that's really not how I meant it (snark fail on my part). I agree with what you're getting at, and I think that the idea of popularizing "AntiIf" as a slogan is really stupid and dangerous. The first eager intern who suggests refactoring some code because "ifs are bad", I'm not a religious man, but God help them. What I was trying to point out is that the single example they have up right now showing that 'if' is "bad" is dispatching on types, which a good number of languages support out of the box (in other words, it's a strawman). If you're already inspecting types, then they presumably already exist, so there's no additional overhead in using your language's features to get clearer code when you can.

Don't solve with conditionals that which can be solved by your language's dispatch mechanism.

tptacek 17y ago

Don't solve with 15 minutes that which you can bill your client 80 hours for.

stcredzero 17y ago
And don't forget, lots of those 15 minute intervals can add up to serious money. ("Stovepipe" systems.) You can also set up an opportunity to bill for coming later in and "fixing" a seemingly intractable big mess.
- Confusion 17y ago
  Do not attribute to malice what can be equally well explained by stupidity.
  - stcredzero 17y ago
    Malice has a better chance of sustained profitability. EDIT: This is a clue to bad intent. "Follow the money!"
    - stavrianos 17y ago
      and yet, the world over, people are still both basically decent and basically stupid. Edit: correlation?
- tptacek 17y ago
  "Oh, I see the problem right here, Mr. Client. Your previous consultant used 'if' statements. Here, let me replace that function with 80 new class files. You'll be much more agile!"
  - stcredzero 17y ago
    I find that the opposite is true: replacing lots of runtime type identification with polymorphism results in placing repeated code in just one place. Don't Repeat Yourself is more agile. Even better: wait until at least the 3rd repetition before refactoring. (But don't wait too long.) This cuts down a lot of unnecessary coding, and leaves the programmer some leeway for good judgment.
calambrac 17y ago
In retrospect, my comment sounded like it was reaffirming the article's point, but that's really not how I meant it (snark fail on my part). I agree with what you're getting at, and I think that the idea of popularizing "AntiIf" as a slogan is really stupid and dangerous. The first eager intern who suggests refactoring some code because "ifs are bad", I'm not a religious man, but God help them. What I was trying to point out is that the single example they have up right now showing that 'if' is "bad" is dispatching on types, which a good number of languages support out of the box (in other words, it's a strawman). If you're already inspecting types, then they presumably already exist, so there's no additional overhead in using your language's features to get clearer code when you can.