Comments (23)
-
I like the "action" prefix. Not something I use, but I could definitely adopt it for future tutorials.
-
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".
from objective-c-style-guide.
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 [email protected] wrote:
I like the "action" prefix. Not something I use, but I could definitely adopt it for future tutorials.
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.
from objective-c-style-guide.
+1 @funkyboy and having sender
.
from objective-c-style-guide.
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 ...
from objective-c-style-guide.
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
[email protected]
On Nov 8, 2013, at 8:24 PM, Marin Todorov [email protected] 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.
from objective-c-style-guide.
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.
from objective-c-style-guide.
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.
from objective-c-style-guide.
What is everyone's opinion on specifying the sender type vs using default id?
from objective-c-style-guide.
+1 specific sender type
from objective-c-style-guide.
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 [email protected] 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.
from objective-c-style-guide.
I usually use id
but I think it is a bad habit and specifying sender is more appropriate, because eventually I cast it anyway.
from objective-c-style-guide.
+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.
from objective-c-style-guide.
*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 :]
from objective-c-style-guide.
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 [email protected] 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.
from objective-c-style-guide.
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.
from objective-c-style-guide.
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.
from objective-c-style-guide.
@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.)
from objective-c-style-guide.
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:
-
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
-
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.
from objective-c-style-guide.
@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. :-)
from objective-c-style-guide.
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.
from objective-c-style-guide.
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.
from objective-c-style-guide.
+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 π
from objective-c-style-guide.
+1 for not enforcing a naming convention as well. I think it goes under the general method naming advice though.
from objective-c-style-guide.
Related Issues (20)
- Init section contradicts Golden path section HOT 2
- Can we lint to enforce some of this style guide? HOT 6
- Symbol prefix: 2 vs. 3 characters HOT 26
- English should be used, really? HOT 7
- What's the point on using properties instead of instance variables? HOT 8
- Direct access to properties. HOT 5
- License for this guide? HOT 1
- Not linking to Official Apple Style Guide HOT 1
- RWT prefix typo in constant definition HOT 1
- What is the recommended line width for Objective-C?
- Use style guide principles in examples
- arrayCount should be named something else HOT 4
- Contradiction between Init Methods and Golden Path
- Error handling
- I want make new branch for Korean ver.
- Google style guide URL is broken HOT 2
- Should self keyword should be used in init methods ?
- How do I indent something like this??? HOT 3
- Xcode behavior regarding indenting block
- ε ³δΊζδΈΎ(Enumerated Types)ηζ³ζ³
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from objective-c-style-guide.