<p>In my models, there are lots of attributes and methods that perform some calculation based on the model instance's attributes.  I've been having the methods return nil if the attributes that the calculations depend on are nil.  As a consequence of this design decision, I'm doing a lot of nil checks before displaying these values in my views. </p>

<p>I thought about having these methods return zero instead of nil when they don't have enough information, but I chose nil because zero is a valid computation result and nil implies that there was not enough information.</p>

<p>Should I return 0 instead of nil?  Is there any other pattern that I could use to avoid doing a bunch of nil checks in my views?  </p>

I tend to think you are doing things right if your problem is choosing whether to display, or not display, the results of a calculation.  If it would make no sense to display any value, then nil is perfectly reasonable.
If, however, your business logic is resulting in you getting into a state where much of the view will be habitually blank, then you probably should refactor such that your program loses its leaky abstractions.
Consider, for example, an application which starts by tracking recipes for
```
Food
```
.  Then, as requirements morph, we get the notion of pies needing to display different information than burgers.  Rather than having a
```
calculate_deliciousness_of_pie_or_nil_for_burger
```
method, and then checking for nil in the view, I'd break that into a pie view for pies and a burger view for burgers.  This might (probably would) require rethinking my object abstractions.