3 ms·

This is one of the most interesting artifacts of programming, and it's probably impossible to explain to people outside the field. How at the same time it's tri

by jariel 5y ago

This is one of the most interesting artifacts of programming, and it's probably impossible to explain to people outside the field. How at the same time it's trivial and important, and a constant cause of neuroticism. It takes up far too much tought-space to the point I would gladly follow some ugly set of conventions merely to have to just never think about it.

hallway_monitor 5y ago
Sure, following some guidelines and standards is helpful. But never having to think about naming is almost like never having to think about logic. What you name things dictates how future developers think about them. Just this week we had a feature that could belong in an existing module or it could require a new module all depending on how we define the domain and therefore the name of the existing module.
- jariel 5y ago
  "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.

by jariel 5y ago

hallway_monitor 5y ago

Sure, following some guidelines and standards is helpful. But never having to think about naming is almost like never having to think about logic. What you name things dictates how future developers think about them. Just this week we had a feature that could belong in an existing module or it could require a new module all depending on how we define the domain and therefore the name of the existing module.

jariel 5y ago
"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.