3

I have a developer for last 3 years, have been using if-else or if-else if statements a lot in my programing habit.

And today, I found This link.

One obvious sample i put here

public void doSomthing(String target, String object){
    //validate requests
    if(target != null && target.trim().length() < 1){
        //invalid request;
    }

    //further logic

}

Now, I have seen this sort of check all over the places, libraries. So, I wanted to have a discussion about the worthiness of such a movement.

Please let me know your views.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
Vijay Shanker Dubey
  • 4,308
  • 6
  • 32
  • 49
  • 3
    "the worthiness of such a movement". Doesn't that seem like a value judgement more than a question? – S.Lott Dec 21 '10 at 20:47
  • Oh boy, I can already see the TDWTF code snippets kindly contributed by people who have looked at this page and decided that "`if` is EVIL, a `class If` is so much better!" :( –  Dec 21 '10 at 20:53
  • I want to see a code/design to remove if statements form my code sample. that is all. – Vijay Shanker Dubey Dec 21 '10 at 21:03
  • 1
    @Vijay: Well you won't, because an `if` statement makes perfect sense in your code and the Ant-If Campaign doesn't have anything to do with such uses of `if`. – ColinD Dec 21 '10 at 21:11
  • 3
    I don't think this question is subjective and needs to be closed. +1 for reopen. – Bozho Dec 21 '10 at 21:27
  • 2
    I would also like it to be opened. +1 for reopen. – Vijay Shanker Dubey Dec 21 '10 at 21:33

6 Answers6

9

The article is advocating against the use of if to simulate polymorphism. In other words, if you find yourself switching or testing if your object is of some type, you're doing it wrong -- you should let the type system do that for you.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
6

One thing I'd like to point out is that the linked article isn't anti-if. It is anti-type-based-logic. Assume each animal is a type/class.

IF i am a giraffe then eat a leaf
else IF i am a rhino eat some grass
else IF I am a monkey eat a banana
etc

this is egregious IMO. Not because it has a string of ifs, but because the way the conditionals are type-specific.

Instead, each animal could implement its own eat() method. Now the code above becomes

animal.eat();

and that's that. Since there are no if statements there's no chance of a logic error. Further, adding a new implementation of Animal doesn't require this code to be changed. In the first example, adding an Elephant requires code to be changed.

Tony Ennis
  • 12,000
  • 7
  • 52
  • 73
4

I don't think the anti-if campaign should aim at removing all ifs. From the code in the article it appears that it is against constructs that can be otherwise implemented via utilizing polymorphism. In your example it is fine to use an if-clause.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
1

This article is not talking about never using ifs. They are needed for program control. That being said there are cases that it makes sense to avoid chains of if statements and that is what I believe the "anti if" movement is about.

jzd
  • 23,473
  • 9
  • 54
  • 76
1

I'd have to read up on it. Unfortunately, it appears that there are some unsubstantiated claims on the site like "Kent Beck joins the Anti-IF campain".

IF statements to increase the complexity of code, that is true. So do try/catch blocks, loops, and any conditional expression. To make a blanket statement that they are bad/evil/etc. is not good form. See: Is anything in programming truly evil?

I can't see where his solutions truly remove the need for conditional logic. The bottom line is whatever makes the code easier to maintain, do it.

Community
  • 1
  • 1
Berin Loritsch
  • 11,400
  • 4
  • 30
  • 57
0

The example you give seems somewhat reasonable. However you should not silently let it fail or return null or something else but throw an exception when it is invalid. And better yet is to use assertions.

Using ifs to test object types is kind of bad practice, rather than that think about your classes and relations more. In a statically typed language like Java that shouldnt be the norm to do if (a instanceof b) all the time.

rapadura
  • 5,242
  • 7
  • 39
  • 57
  • 2
    No. Assertions are for sanity checks. When an assertion fails, your code is broken for it has reached a state that ought to be impossible. Assertions != error handling. –  Dec 21 '10 at 20:49
  • @delnan, yes, in the example he gives his code shouldnt have failed, thus the assertion. If processing further doesnt make sense, then fail, and this will force you to fix your code. – rapadura Dec 21 '10 at 20:53
  • Invalid arguments aren't a bug in your code. It's not even necessarily a bug in the caller's code. When passed an invalid argument, you should raise an **appropriate** exception or return a sensible result (say, `null`) than crashing with an error message that says "this function is broken". –  Dec 21 '10 at 20:57
  • If they arent invalid then dont test if they are null or empty. If a method expects non-null, non-empty to complete its task, then it should fail if it gets null, and it is my preference that assertions suitable for this, but exceptions are OK aswell. But returning null or even empty list is bad practice since the caller then has to check if the required computation was actually done or not. However, if the argument sometimes MAY be null, then dont even do a null check and just return it as is. – rapadura Dec 21 '10 at 21:01
  • You should use [Preconditions](http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/base/Preconditions.html) (or the normal `if` with an exception) for such checks, not assertions. Assertions are more for documentation and ensuring something that should be impossible does in fact never happen during development. – ColinD Dec 21 '10 at 21:04
  • Yes, it should fail if there's no sane return value for the given arguments. But not via assertions. That a failed assertion happens to act like an exception (in some languages assertions are only checked debug mode, by the way) doesn't change its semantics from "validation that is true" to "succinct way to throw exceptions". Returning `null` or "null objects" *can* be sensible. –  Dec 21 '10 at 21:09