Add a specification for bang methods

[gylaz]

No description provided.

[paulcsmith]

Small typo

unless you *have* a safe method

[JoelQ]

Extraneous 'you' in the sentence

[jferris]

Looks good to me once the typo is fixed.

[calebhearth]

👎 I don't think this is something we should provide a guideline for. It's very much a "does it feel right in this instance" sort of thing, which every conversation on the topic I've had has evolved into.

[jyurek]

"unless you a safe method" <-- should that be "unless you know a safe method"?

[calebhearth]

Also my opinion about bang methods has changed, I don't know if any one else feels similarly. I feel like the bang method is there as an indication that something unexpected will happen and don't feel like that is mutually exclusive to a non-bang method existing.

• @halogenandtoast

I 👍 this, but still don't like having the guideline added.

[gylaz]

@calebthompson I think a guideline is important, this will prevent discussions in pull requests about personal opinion on method naming.

[calebhearth]

God forbid we have discussions or opinions.

Caleb Thompson
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Tuesday, October 22, 2013 at 1:45 PM, Greg Lazarev wrote:

@calebthompson (https://github.com/calebthompson) I think a guideline is important, this will prevent discussions in pull requests about personal opinion on method naming.

—
Reply to this email directly or view it on GitHub (#122 (comment)).

[jferris]

My general issue with bang methods that "feel right" is that they don't actually tell you anything. They end up seeming random, and as a reader of a method like 'invite!`, I have no idea if the author wants me to know that it's going to modify the user, might raise an exception, or something new and exotic. It's become a smell like "do_invite" or "execute_invite." It tells you nothing about what the method does in addition to its base name.

I'd rather not have bang methods at all than try to guess what the bang means.

[jferris]

indication that something unexpected will happen

I don't think we should have methods where something unexpected will happen. Can you give an example of a method with unexpected consequences that isn't just poorly named?

[calebhearth]

I think that it tells you that you should probably check out what it is. Does the method invite modify the record, set an attribute, send an email? Bang methods are there to tell you to be careful before using them, and that maybe you should read it first.

Caleb Thompson
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Tuesday, October 22, 2013 at 1:47 PM, Joe Ferris wrote:

My general issue with bang methods that "feel right" is that they don't actually tell you anything. They end up seeming random, and as a reader of a method like 'invite!`, I have no idea if the author wants me to know that it's going to modify the user, might raise an exception, or something new and exotic. It's become a smell like "do_invite" or "execute_invite." It tells you nothing about what the method does in addition to its base name.
I'd rather not have bang methods at all than try to guess what the bang means.

—
Reply to this email directly or view it on GitHub (#122 (comment)).

[halogenandtoast]

@jferris the point I feel is that you should look at what the bang method does and understand why you'd use it. The bang is there to signify that to you. As developers we shouldn't avoid reading the code.

[halogenandtoast]

I'd rather not have bang methods at all than try to guess what the bang means.

I don't disagree with this.

[jferris]

I think we should merge the guidelines as-is; it's a guideline, and not a rule, and it makes sense for most cases.

If we find cases where the "feels right"/"unexpected effects" argument holds up, we can revise or remove.

Objections?

[calebhearth]

I'd disagree that it makes sense for most cases. It just happens to align with the way ruby-lang and rails define their methods, not how developers use it in most cases. That we have it come up so often proves that.

[salbertson]

I would be fine with avoiding bang methods completely. I think renaming a method to describe the unexpected behavior is more clear than using a bang.

[calebhearth]

That seems like a good compromise to me as well.

"Avoid defining bang (!) methods; prefer descriptive names."

On Tue, Oct 22, 2013 at 6:31 PM, Scott Albertson [email protected]
wrote:

I would be fine with avoiding bang methods completely. I think renaming a method to describe the unexpected behavior would be more clear than using a bang.

Reply to this email directly or view it on GitHub:
#122 (comment)

[jferris]

@gylaz Looks good to merge.