> As it stands, the `selector` argument's effect the return value is pretty clear. With the constructions you've suggested, it is harder to recognize this effect (you have to visually compare two statements), […]

There's an argument to be made either way. Allow me to elaborate. :)

```javascript
var $set;  // $set is declared

//
//
//
//
//
//

$set = this.make(set);  // $set is assigned a value

if (arguments.length) {
  $set = $set.filter(selector);  // $set is assigned another value!
}

return $set;  // $set's value is returned
```

In order to reason about the return value, one must first make a pass to understand how the value of `set` changes over time, then make a second pass to track changes in the value of `$set` over time. Note that `$set` will take on either two or three different values (including its initial value of undefined).

The second pass is not required in the following case:

```javascript
if (arguments.length) {
  return this.make(set).filter(selector);
} else {
  return this.make(set);
}
```

If an argument is provided, return *this* value. Otherwise, return *that* value.

This is a somewhat philosophical issue, as we're discussing the merits of procedural versus a more functional style of coding. That said, cheerio does make quite good use of Underscore functions such as map and reduce in several places, and @MatthewMueller has been receptive to refactoring code to a more functional style.

> […] and it may be harder to maintain (any operations on the Cheerio object will have to be repeated across code paths).

Excellent point. I certainly don't like duplication. I think it unlikely this situation will arise, but if and when it does I wouldn't oppose shuffling things around a bit.