IBAction methods naming and parameters

[icanzilb]

I didn't see any rule about IBAction methods in the guide.

I think there are 2 parts to this:

1) How to name such methods - "didPressButtonA" or "buttonAPressed", or something else. I myself, always prefix IBAction methods with "action" and that liberates me of coming up with a proper verb, subject, etc. so I always go for

-(IBAction)actionButtonA 

so there's no binding to what exactly the method will do (because this also might change along the way), but it says exactly "the method that is the action of buttonA"

2) I always add the "sender" parameter, but I end up using it in maybe less than 1% of the cases ... I'm not sure about it ... if you won't use the sender param to me it feels stylewise the same if you gonna have

-(IBAction)actionButtonA;

or

-(IBAction)actionButtonA:(id)sender;

opinions?

[ricardo-rendoncepeda]

1) I like the "action" prefix. Not something I use, but I could definitely adopt it for future tutorials.

2) I'm very careful with "sender" and only implement it when I need to. Furthermore, if I adopt it I usually send in the specific UI type, rather than just "id".

[funkyboy]

I am pretty sure Apple suggests to always have a sender, even if you end up using it 1% of the times. I'd stick to that. And yes, I am aware it's extra typing, but we do it for the readers, right :)

On Nov 8, 2013, at 8:11 PM, Ricardo Rendon Cepeda notifications@github.com wrote:

1) I like the "action" prefix. Not something I use, but I could definitely adopt it for future tutorials.

2) I'm very careful with "sender" and only implement it when I need to. Furthermore, if I adopt it I usually send in the specific UI type, rather than just "id".

— Reply to this email directly or view it on GitHub.

[moayes]

+1 @funkyboy and having sender.

[icanzilb]

okay, so if we are to make having sender obligatory, should it be casted to the sender type or not? So ...

-(IBAction)actionButtonA:(id)sender;

vs.

-(IBAction)actionButtonA:(UIButton*)sender;

I myself, always cast the param, in case I actually need it. Probably it's the better way to go ...

[funkyboy]

You solve a problem you introduce a new one :) I am in favour of casting, but as far as I remember all of the Apple APIs use id.

-c.

Cesare Rocchi cesare@studiomagnolia.com

On Nov 8, 2013, at 8:24 PM, Marin Todorov notifications@github.com wrote:

okay, so if we are to make having sender obligatory, should it be casted to the sender type or not? So ...

-(IBAction)actionButtonA:(id)sender; vs.

-(IBAction)actionButtonA:(UIButton*)sender; I myself, always cast the param, in case I actually need it. Probably it's the better way to go ...

— Reply to this email directly or view it on GitHub.

[hollance]

I don't like the action prefix. That just doesn't read well to me. I often do use it as a suffix, i.e. buttonAction. That's more natural English.

[ndubbs]

My preferred way would be this:

• (IBAction)buttonAAction:(UIButton *)sender;

If you create this method/action via ctrl and drag from IB to the class interface, then you can select UIButton vs id. Since you know it is a button or UISegmentedControl, etc it will create less code if you use sender further down in the method.

[ndubbs]

What is everyone's opinion on specifying the sender type vs using default id?

[ricardo-rendoncepeda]

+1 specific sender type

[hollance]

I think it depends on the situation, but specifying the type instead of id is simpler than doing a separate cast (likewise for array and dictionary enumeration).

Sent from my iPhone

On 9 nov. 2013, at 22:41, Nick Waynik notifications@github.com wrote:

What is everyone's opinion on specifying the sender type vs using default id?

— Reply to this email directly or view it on GitHub.

[moayes]

I usually use id but I think it is a bad habit and specifying sender is more appropriate, because eventually I cast it anyway.

[icanzilb]

+1 on casting the sender @ndubbs - if you gonna use the sender at all, you might have it already casted anyway. In case there's a different class coming in - hey let the app crash, so you can figure out the mismatch as soon as possible and fix that.

[icanzilb]

_Prefixes vs. suffixes. _

I prefix everything because that makes autocompletion works. If you have noticed - the autocompletion does not autocomplete based on what suffix a method has or a property has ... you write from left to right (at least you code for sure that way) therefore suffixes are useless.

If you call like me all your IBOutlet buttons "_btnWhatever", whenever you need to work with one you just type "_bt" and autocomplete already shows you a list of ALL your buttons to choose from.

Therefore to keep the style consistent I like to also prefix IBActions, because every now and again it is actually neccessary to simulate a tap or so, and then autocomplete also helps you type that.

Anyways ... my point is - suffixes don't have any use for anyone. Imagine you are having your .m file open. You click on the drop down that gives you list of all class methods to look for a certain method. It's way more difficult to look for certain suffix as method names have different length and format ... it's WAY easier to look at the prefixes - if you're search for your "actionSomething:" method - it's so easy to just skim through the left side of the list for the word "action" - on the other side - try skimming through a wobbly right hand side of the list for the suffix "Action" ...

so .. in fewer words ... suffixes suck big time, while prefixes are the best :]

[hollance]

Might as well use Hungarian notation for everything then...

I'm sure you're right that prefixes make autocompletion easier but do they also make tutorials easier to understand?

Sent from my iPhone

On 10 nov. 2013, at 09:27, Marin Todorov notifications@github.com wrote:

_Prefixes vs. suffixes. _

I prefix everything because that makes autocompletion works. If you have noticed - the autocompletion does not autocomplete based on what suffix a method has or a property has ... you write from left to right (at least you code for sure that way) therefore suffixes are useless.

If you call like me all your IBOutlet buttons "btnWhatever", whenever you need to work with one you just type "bt" and autocomplete already shows you a list of ALL your buttons to choose from.

Therefore to keep the style consistent I like to also prefix IBActions, because every now and again it is actually neccessary to simulate a tap or so, and then autocomplete also helps you type that.

Anyways ... my point is - suffixes don't have any use for anyone. Imagine you are having your .m file open. You click on the drop down that gives you list of all class methods to look for a certain method. It's way more difficult to look for certain suffix as method names have different length and format ... it's WAY easier to look at the prefixes - if you're search for your "actionSomething:" method - it's so easy to just skim through the left side of the list for the word "action" - on the other side - try skimming through a wobbly right hand side of the list for the suffix "Action" ...

so .. in fewer words ... suffixes suck big time, while prefixes are the best :]

— Reply to this email directly or view it on GitHub.

[icanzilb]

Hungarian notation was per se "bad" before powerful IDEs with autocomplete. Objc naming is already ridiculously long so if adding a prefix which speeds up your coding experience and generally helps you out on a daily basis I don't see anything wrong with that.

I would say the best way to write a tutorial is the way to teach somebody a style which they will use when they code themselves.

[hollance]

The rules for naming things are are simple as this: either something has a good name or it has a bad name. A good name makes it immediately what something does or what it represents. A bad name is unclear, ambiguous or misleading. The style guide doesn't have to go any further than that.

Enforcing a naming convention for certain types of methods is arbitrary and reeks more of personal preference than pedagogical value.

Aside from that, naming action methods "actionButtonA" is just bad English. This does not describe an action, it describes a button. A better name would be "actionForButtonA" but that's also kind of silly. The word "buttonAAction," on the other hand does describe an action, and follows English grammar.

But adding the word "action" to the names of these methods isn't really necessary in the first place because the return type already indicates it is an IBAction. In addition, the guide suggests that all actions are grouped together using #pragma mark, so they should be easy to find.

[hollance]

@icanzilb If you find using those prefixes helps you on a daily basis, then great. :-) But see it for what it is: your personal preference. Our readers will have to find out for themselves what sort of style they will use. One size does not fit all.

(By the way, I optimize my code for readability, not coding speed.)

[icanzilb]

Matthijs - I think you said it best. "actionForButtonA" is just what the method is: the-action-for-button-a, it's the best English I can think of. You won't find any other phrase that describes better what does this method do. So I think the readabilty concert here is out of question.

I'll give you an example why this naming is better than anything else. You have a complex UI with a number of buttons, you need to quickly check what does the button "Verify" do. You have your code file open already and 2 choices:

1) open new tab, open your storyboard, wait for the interface builder to initialize (at least on my mbp takes lots of time, I avoid opening storyboards as much as I can), select the button, switch to the connections tab, and check what the connected method is called. Only to discover later on that by selecting the button, IB moved it into a uiimageview which stays behind the button. Then switch back to code and find that method

2) click the dropdown menu, skim through the list and click on "actionForButtonVerify:" Done

I don't want to convince you to switch yourself to a naming convention; nor I want to get into coding style wars ... but you see that my opinion is not based solely on emotion - it's just super helpful and helps me daily in my coding.

[hollance]

@icanzilb I perfectly understand. :-) It makes sense in your workflow. But that doesn't mean it's necessarily the workflow we should teach.

Also, you did not suggest the naming actionForButton but actionButton. These read as two very different things! When I see actionButton I do not immediately think, "Oh this means action-for-button", but "The button that has the text 'Action' on it."

By the way, IBActions have a circle next to them (in the gutter of the source editor). Click on it to see the control it's connected to; click on the control to open IB and highlight the control. Just pointing out that an alternative workflow can solve that problem too. :-)

[mattjgalloway]

I would steer clear of actionButton myself, because that sounds like it's a method that would return a button that performed an action. That's why I usually go with:

- (IBAction)buttonAPressed:(id)sender

On the id vs UIButton* for sender - I think that one is down to the situation. I usually have the specific type anywhere where I'm going to use the sender (e.g. gesture recogniser actions). I usually leave as (id)sender until I come to use it in the method and then change to something like (UITapGestureRecognizer*)tapRecogniser when I first write code that uses it.

[rwenderlich]

My vote is not to enforce a naming convention for action methods - I think that's overreaching a bit.

Regarding casting sender or not - I'd be happy either way there.

[ghost]

+1 for not enforcing a naming convention. +1 for casting. It makes more sense, and makes the code more readable, if you cast the sender in the method signature :thumbsup:

[mattjgalloway]

+1 for not enforcing a naming convention as well. I think it goes under the general method naming advice though.