Name symbols to end in the class or primitive type they represent about objective-c-style-guide HOT 8 CLOSED

Yeah I find this applicable to views too, for example you can have *messageLabel as opposed to message for a UILabel

from objective-c-style-guide.

I wonder how we could clarify that this is a common (and useful) practice in some but certainly not all cases.

For example, an Article class probably has a title property, which is probably a fine name for it.

I will need to take some time to think through what exactly determines whether this naming style applies in my day-to-day coding.

from objective-c-style-guide.

For example, an Article class probably has a title property, which is probably a fine name for it.

Totally agree. This can be helpful, but sometimes gets a bit wordy.

from objective-c-style-guide.

I mostly disagree with this overall premise. Symbols should be named the most appropriate name. title is a much better name for that property than titleString, because it's obvious that title will be a string. An array of articles would ideally be called articles because expressively that's what it is. But a string representation of a date should definitely be called something like dateString. I think that the rule should be something like only appending the type of the symbol to the variable name if it is unexpected or otherwise unclear. But that is so difficult to codify for anything other than variables that include one type in their name but are actually another.

This is especially important when dealing with a variable that is not precisely the semantic type it sounds like

I agree, but I think that this is actually the only time we should follow this as a rule.

from objective-c-style-guide.

Capps' description matches my practice. I put the type after rarely used classes too like blahBlahIndexPath for example

from objective-c-style-guide.

I think that the rule should be something like only appending the type of the symbol to the variable name if it is unexpected or otherwise unclear.

Agreed.

I think the key point is that the name should clearly represent what the symbol is, which just sounds like common sense. Consider the following examples, which I would consider good names:

• NSString *title: It is reasonable to assume a "title" is a string. No further clarification needed.
• NSString *titleHTML: A title, which may contain HTML which should be parsed for display. "HTML" is needed for the programmer to use this variable properly.
• NSAttributedString *titleAttributedString: A title, formatted for display.
• articles: Could be an array or set of articles; either way, it's a collection containing n articles.
• NSDate *now
• NSDate *lastModifiedDate: Simply lastModified is ambiguous; one could reasonably assume it is one of a few different things.
• NSURL *url vs. NSString *urlString, for obvious reasons

from objective-c-style-guide.

Totally agree with @cdzombak here. Not sure how we can write it up in the guide, but it makes complete sense.

from objective-c-style-guide.

Totally agree with @cdzombak here. Not sure how we can write it up in the guide, but it makes complete sense.

Written in #108.

from objective-c-style-guide.