3 ms·

If you are looking only to optimize your career and expertise, do whatever you want. If you care about having a codebase that is accessible to all levels of ta

by mvid 12y ago

If you are looking only to optimize your career and expertise, do whatever you want. If you care about having a codebase that is accessible to all levels of talent, then you should optimize for readable code. The least skilled team member is still a team member. The fresh grad, the intern, the customer support rep with an interest in code, the new hire. Why are you so willing to discount any of these members as not valuable? Just because they don't have an innate skill and interest in code golf? Reading symbols is a near instantaneous exercise. You can tell the difference between "i" and "index" with no extra work. Stopping to think to decipher the meaning of cryptic code is slow. It doesn't hurt to use a full word instead of a single letter variable name, or an explicit function call instead of an alias to some cryptic character. We don't use languages anymore that benefit from have a small file size. Reading will always be more important than writing, until you get down to hardware drivers and kernels.

marcosdumay 12y ago
> If you care about having a codebase that is accessible to all levels of talent, then you should optimize for readable code. "All levels of talent" is such a can of worms. No, not even in a team environment you should have all code accessible to all levels of talent. That's just a recipe failure. Anyway, that isn't really relevant to the argument of how many characters you should use in a variable name.
JackMorgan 12y ago
Oh, I wasn't talking about variable names, those are certainly the fastest to read and communicate the complexities of a domain. I was talking about programming languages that require 3-4x the code/boilerplate to write the same logic. For example, F# usually needs roughly half the lines and way less than half the characters than the equivalent C# code, assuming all the same variable and function names. Other examples are Scala, Haskell, Clojure, Go, or even lambdas and the Linq features of C#. I've heard others argue we shouldn't use these because "jr members won't understand them". Usually the person arguing this position is not junior, and does not know the feature or language now. Which leads me to believe it has nothing to do with junior members at all, and everything to do with them. Edit: I also think that writing down to the least skilled member is disrespectful to them and you. It's pandering to treat them as too ignorant or stupid to learn powerful concepts, no matter who they are. I also think most people who make this argument disregard the sheer cliff wall of difficulty that is modern software development. The difference in difficulty between an entire C# stack with inheritance, interfaces, threads, polymorphism, and mutable class state and all that plus lambdas is really minor.

by mvid 12y ago

marcosdumay 12y ago

> If you care about having a codebase that is accessible to all levels of talent, then you should optimize for readable code. "All levels of talent" is such a can of worms. No, not even in a team environment you should have all code accessible to all levels of talent. That's just a recipe failure. Anyway, that isn't really relevant to the argument of how many characters you should use in a variable name.

JackMorgan 12y ago

Oh, I wasn't talking about variable names, those are certainly the fastest to read and communicate the complexities of a domain. I was talking about programming languages that require 3-4x the code/boilerplate to write the same logic. For example, F# usually needs roughly half the lines and way less than half the characters than the equivalent C# code, assuming all the same variable and function names. Other examples are Scala, Haskell, Clojure, Go, or even lambdas and the Linq features of C#. I've heard others argue we shouldn't use these because "jr members won't understand them". Usually the person arguing this position is not junior, and does not know the feature or language now. Which leads me to believe it has nothing to do with junior members at all, and everything to do with them. Edit: I also think that writing down to the least skilled member is disrespectful to them and you. It's pandering to treat them as too ignorant or stupid to learn powerful concepts, no matter who they are. I also think most people who make this argument disregard the sheer cliff wall of difficulty that is modern software development. The difference in difficulty between an entire C# stack with inheritance, interfaces, threads, polymorphism, and mutable class state and all that plus lambdas is really minor.