13

I was just writing an if statement with fairly long property names and came occross this problem.

Let say we have an if statement like this:

if(_someViewModelNameThatIsLong.AnotherPropertyINeedToCheck == someValue &&
   !_someViewModelNameThatIsLong.ThisIsABooleanPropertyThatIsImportant)
{
    //Do something
}

The second property is of a boolean type and it makes no sense to have the stetement like

if(boleanValue == true)

Is there a better way to emphasize the negation then to put the ! in front. To me it seems like this can easily be overseen when reading the code and may potentialy cause problems with debuging

  • 7
    Extract the condition into a method with a meaningful name. – Joachim Sauer Jan 21 '13 at 11:20
  • 2
    ...or assign the negated value to a variable with a meaningful name and use it in the if condition instead. – scrwtp Jan 21 '13 at 11:22
  • +1 what @JoachimSauer said, if possible put that method on the object that is being queried.. In this case the whole condition could be encapsulated with a method on _someViewModelNameThatIsLong – MattDavey Jan 21 '13 at 11:51
  • 2
    A general thing I often do is to surround the negation with a space on each side to make it more visible. if( ! something) vs if(!something) – Svish Jan 21 '13 at 14:44
  • If you're emphasizing negation, why not use ... && model.Prop == false)? Personally I very rarely use !, it's too easy to overlook. –  Jan 21 '13 at 17:49

4 Answers4

22
if(_someViewModelNameThatIsLong.NeedsMeToDoSomething(someValue))
{
    //Do something
}

And then, in the view model object

public bool NeedsMeToDoSomething(string someValue)
{
    return AnotherPropertyINeedToCheck == someValue &&
        !ThisIsABooleanPropertyThatIsImportant;
}

(assuming someValue is a string and isn't known by the model object)

This not only emphasises the ! operator, but it makes it more readable generally. Now, in the calling method, I can see one condition, which should be well-named to describe the condition in the context of the calling object. And in the model object, I can see what that means in the context of the model object.

pdr
  • 53,607
  • 14
  • 138
  • 224
5

Put it in its own if block prior to evaluating the less important conditions. Not only would it be easier to read without the clutter of the other conditions, but it's also the first condition a programmer will read. Combine this with the idea already mentioned by @scrwtp to assign to a variable with a meaningful name and you get:

var isValid = !_someViewModelNameThatIsLong.ThisIsABooleanPropertyThatIsImportant;
if( isValid ) 
{
    if( _someViewModelNameThatIsLong.AnotherPropertyINeedToCheck == someValue ) 
    {
        //Do something
    }
}

If you're programming in a compiler language, most times these nested if blocks get combined in the end anyway, so long as you don't insert code between the outer if and the inner if, so it shouldn't affect performance in these cases.

Neil
  • 22,750
2

If you are using C/C++ then the preprocessor could provide readability.

#define NOT !

if(_someViewModelNameThatIsLong.AnotherPropertyINeedToCheck == someValue &&
    NOT _someViewModelNameThatIsLong.ThisIsABooleanPropertyThatIsImportant)
{
    //Do something
}
Andres F.
  • 5,139
  • 2
  • 30
  • 41
CWallach
  • 1,108
0

I'd just extract

`!_someViewModelNameThatIsLong.ThisIsABooleanPropertyThatIsImportant`

In a Method that returns this. If you name this method NotThisIsABooleanPropertyThatIsImportant you should be fine.

mhr
  • 660
  • 6
  • 18