There is a better way to iterate over collections in Objective-C 1.0<\/a>. You really should use it. It’s easier to write, easier to read, less prone to bugs, faster, and makes what I’m going to rant about here a non-issue, because you won’t have any The standard iteration idiom in Objective-C 1.0 is: Unfortunately, I see otherwise steller programmers name their This is an especially amateurish practice because …<\/p>\n Call it, the plural of the For example, to fix:<\/p>\n We should name These rules can be applied without much thought, but will improve the clarity of code.<\/p>\n Firstly, the practice of naming an the index in a But at least, Also, there is something to be said for the idiom you can just use Everyone agrees informative names are good, yet poorly named enumerators are everywhere (just browse Apple’s sample code!) Poorly named enumerators persist because nobody really uses an enumerator per se, they are just part of an iteration idiom. (So stop declaring them and iterate smarter<\/a>). When was the last time you saw code that did anything with an But bad habits matter<\/em>. Don’t pick up the habit of naming something poorly when it’s easy to do the right thing.<\/p>\n","protected":false},"excerpt":{"rendered":" Disclaimer There is a better way to iterate over collections in Objective-C 1.0. You really should use it. It’s easier to write, easier to read, less prone to bugs, faster, and makes what I’m going to rant about here a non-issue, because you won’t have any NSEnumerator variables in your code. Badly Named Problem The […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18,7,6,12,5,4,10,8],"tags":[241,413,288,242],"class_list":["post-202","post","type-post","status-publish","format-standard","hentry","category-bug-bite","category-c","category-cocoa","category-design","category-objective-c","category-programming","category-tips","category-usability","tag-best-practices","tag-names","tag-nsenumerator","tag-programming-style"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/202","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=202"}],"version-history":[{"count":2,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/202\/revisions"}],"predecessor-version":[{"id":431,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/202\/revisions\/431"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=202"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=202"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=202"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}NSEnumerator<\/code> variables in your code. <\/p>\nBadly Named Problem<\/h3>\n
\n
\nNSEnumerator *enumerator<\/em> = [collection objectEnumerator];
\nid element = nil;
\nwhile( nil != (element = [enumerator<\/em> nextObject]) ) {
\n ;\/\/do stuff...
\n}
\n<\/code><\/p>\nNSEnumerator<\/code> variables “enumerator”.<\/strong> That’s always wrong, because it does not tell you what<\/em> the enumerator enumerates<\/strong>. We already know that enumerator<\/code> enumerates things, because it’s type is NSEnumerator<\/code>, unless it’s name tells us more then that it’s hardly better then no name at all.<\/p>\nNaming an Enumerator Well is Easy!<\/h3>\n
element<\/em><\/code> variable<\/strong>. And if that won’t work you can always<\/em> fall back on calling it collection<\/em>Enumerator<\/code><\/strong>.<\/p>\nNSEnumerator *enumerator = [input objectEnumerator];\nNSString *path = nil;\nwhile (path = [enumerator nextObject])<\/pre>\n
enumerator<\/code> paths<\/strong><\/code> or inputEnumerator<\/strong><\/code>. You might find “paths” to be too close to “path” in which case let the “plural form” of element<\/em><\/code> be everyElement<\/em><\/code><\/strong>, giving everyPath<\/strong><\/code>.<\/p>\nWhy
enumerator<\/code> is Worse Than i<\/code><\/h3>\nfor<\/code>-loop i<\/code> is not good. You can avoid it by renaming i<\/code> to thingThatIsIndexed<\/em>Index<\/code>.<\/p>\nfor(int i = 0; i < collection.size(); i++)<\/code>, is concise<\/em>; therefore better than a equally-poorly-named NSEnumerator<\/code>.<\/p>\ncollection[i]<\/code> over declaring an extra element<\/code> variable.<\/p>\nThe Right Choice<\/h3>\n
enumerator<\/code> besides [enumerator nextObject]<\/code> in a while<\/code> loop?<\/p>\n