Re: Exclamation marks in method names

On Mon, Nov 14, 2011 at 1:08 PM, Sylvester Keil
<[e-mail]> wrote:
> As outlined in the Matz/Flanagan book (also in Pickaxe and, I believe, I =
read about it the Best Practices book, too), the prevailing convention is t=
o use exclamation marks for methods that should 'be used with caution'; com=
mon examples include mutators (when there is also a nonmutating variant), o=
r methods that raise errors (when there are variants that fail 'silently' b=
y returning a known good value or a default value). I have used exclamation=
 marks in both these contexts, however, I've also come up with a different =
idiom recently, mainly in combination with predicates.
>
> As we know, predicates (or predicate-like state) can often be accessed us=
ing methods ending with a question mark like #empty?, #nil? etc. Now, in ca=
ses where the predicate's state is determined solely by an attribute, I sta=
rted using methods with exclamation marks to set the value. For example, co=
nsider a Date class that is supposed to handle uncertain dates:
>
> d =3D Date.new
> d.uncertain? #-> false
> d.uncertain! #-> make date uncertain (instead of d.uncertain =3D true)
> d.uncertain? #-> true
> d.certain! #-> make date certain again
>
> These methods are mutators, but they are not really dangerous (and there =
are no non mutating variants), so this usage is in violation with the namin=
g convention. Nevertheless, I've grown quite fond of the symmetry (using bo=
th ? and ! for predicates), going so far as adding separate accessor genera=
tors (think attar_predicate).

That would be totally unobvious to me.  I would rather expect (and be
looking for) a "=3D" sign somewhere to update the property / attribute.
That also has the advantage to treat all attributes alike when it
comes to updating.  Not sure whether this in itself is such a big win
but the readability loss could be significant.

> To make matters worse, I broke another convention: in Ruby, the exclamati=
on mark mutators usually return self only if a mutation actually took place=
 (nil otherwise), for example:
>
> 'U'.upcase! #-> nil
>
> and are therefore not chainable. Because I wanted the predicate-setters t=
o be chainable, I made them return self always. For instance, I had a Name =
class that printed names according to different formatting rules and I want=
ed to write things like:

Chainability is useful sometimes but I am in doubt whether it is such
a big asset.  I'd probably judge convention higher.

> name.sort_order!.to_s #-> set name to sort order formatting and convert t=
o string

Doesn't look good to my eyes.

> What do you think? Is it a terrible idea to break conventions like that a=
nd would you discourage or condone such usage?

Well, conventions are there to make our lives easier.  If you break a
convention you need to compare the cost with the benefit.  If you
intend to make the code from these projects public I'd say costs (=3D
negative impact) clearly outweigh benefits, because your convention is
not compatible with the "core convention".  Even for purely internal
project I am not sure whether it is such a good idea.  New people need
to get used to it (which is probably not too bad), but if you look at
other code you will constantly have to adjust your expectations (i.e.
foo! is chainable in your case while it is not generally in other
code) etc.  I think the "beauty" to nicely align methods with
punctuation (!?) is not as important as the obstacles to reading and
writing code in an environment with your replacement convention.  And:
if it ain't broken, don't fix it - could be read as "don't change
established conventions unless you have very good reasons".

> Also, I'd be curious to know if there were any other common conventions r=
egarding the use of exclamation (and question) marks in method names?

I am not aware of any other right now.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/