"s almost like never having to think about logic. " Not really, because naming is 98% convention when it's done right. The challenge is establishing all the c

"s almost like never having to think about logic. " Not really, because naming is 98% convention when it's done right. The challenge is establishing all the conventions for a project, and then sticking to them. If there are really good conventions in place, well known, then naming is considerably easier. In fact, even if the conventions are not super good - they can be powerful when they are very well adhered to. Example: recently broke a rule and decided to use a known naming anti-pattern by suffixing variable names with the system type. This is normally not good. But within this module, the meta typing was ambiguous - by adding the suffix, the code was magically more clear. That little convention, very easy to apply, solved a clarity problem far more so than any issues around what functions should be called. So we used it for the module and that module only. Apple has some pretty hardcore naming conventions that I don't really like, but what's more important then whether they are good or not, is that they are very consistently applied - in other words - a lot less to think about.