Looking on the bright side of life, makes things easier. The glass is half full.
A coding style also can be positive, which makes the code more accessible. While reading code, negations cost additional brain processing and therefore should be avoided.
That not only applies to negating conditions like unless or if !:
# bad return if !bank_account.empty? # also bad return unless bank_account.empty?
but also negations in naming, like method names with non or not:
# bad again return if bank_account.not_empty?
That is why conditions and names should be positive. Negations can be abstracted away.
Ruby sets the example
In Ruby some methods have a positive counterpart implementation. For instance Enumberable:
numbers = [1, 2, 3] # bad puts "bad" unless numbers.empty? # good puts "good" if numbers.any?
Rails does it too
In Rails, some of the Ruby classes were enhanced to even improve the positive coding experience:
object = Object.new # bad puts "Object present" unless object.nil?
# good puts "Object present" if object.present?
A Person having diseases, as an imaginary use case:
class Person < ActiveRecord::Base has_many :diseases def has_diseases? diseases.any? end end
The query, whether the person is healthy:
# bad puts 'healthy' unless person.has_diseases? puts 'healthy' if !person.has_diseases?
includes a negation, which means an extra thoughts step while reasoning about the code.
The negation can be abstracted away into a method. However there is little gain in readability, if the method naming is miserable:
# bad puts 'healthy' if person.has_not_diseases?
# good puts 'healthy' if person.healthy?