Avoid double negation

[wnagrodzki]

Don't not avoid double negation.

if !unavailable {
    //...
}

This is to avoid confusion.

Use "positive" names for variables and properties.

if available {
    //...
}

return available ? operationWhenAvailable() : nil

This is to decrease mental tax often caused by "negative" properties. It will also help keeping "main" application flow on the left hand side of colon when conditional operator ?: is used.

Do not use negative conditions with guard.

guard !array.isEmpty else { return }

This is to restrain overusing of guard statement where if would suffice. if array.isEmpty { return }

Source: Uncle Bob, Mattt

[wnagrodzki]

@pwgr Do you have any comments on that guideline? Michał and I think this would be useful to add.

[pwetrifork]

That’s reasonable, I would also expand this with a recommendation against using “negative” names for boolean variables/properties, e.g. name the variable “isAvailable” instead of “unavailable”.

[pwetrifork]

The above matters when a variable is used with ?: operator - placing the “main” flow in the first segment (before the semicolon) usually feels more natural, I’m doing it even if it forces me to negate the test.

[wnagrodzki]

@pwetrifork Good point, I also prefer "positive" variable/property names as I experience mental tax when reading "negative" ones.

However, if I were to choose from the examples below I would use the second one.

let light = !resource.unavailable ? .green : .red
let light = resource.unavailable ? .red : .green

Did I understand you correctly that you would prefer to use the first option?

[pwetrifork]

There is no clear “main” path in the example above, what I meant were cases like returning nil from the test. In such situation I would avoid placing the nil segment first.

[wnagrodzki]

@pwetrifork Could you provide an example?

[pwetrifork]

return unavailable ? nil : someOperationOnAvailable() vs return !unavailable ? someOperationOnAvailable() : nil

Here I would prefer the second option when it comes to ?: operator segments arrangement. That’s why I mentioned the whole positive vs negative boolean naming thing.

[wnagrodzki]

@pwetrifork Good point, I like that idea

[wnagrodzki]

@pwetrifork @Moskacz Would you consider the section good enough to become the guideline? Maybe we should change the title, but I do not have any better propositions now.

[Moskacz]

Looks good for me, I'd just remove parentheses from examples that have if statement

[pwetrifork]

Do not use negative conditions with guard.

Guard statement often forces you to use negation, and at the same time it's better than if for early returns - it's not possible to miss a return/throw/etc. statement.

[wnagrodzki]

This is a very good point. I am leaning towards using if as potential mistakes should be caught by unit tests.