Open alexeieleusis opened 7 years ago
The issue that Bob is pointing out has less to do with the number of characters in the name as it does with including characters that don't add useful semantic value. The name "myFoo" isn't long, but the "my" is unnecessary. On the other hand even very long names can be reasonable if there's really nothing unnecessary in them. But I don't know of any reasonable static analysis that we could do to determine which parts are and are not useful to human readers.
Maybe start with showing lint for names, that have type in them? Like:
String someString = ''; int zeroInt = 0;
Interesting suggestion. I'd be interested to see how many places such names currently appear. I'm guessing that it's not that uncommon for people to use type names in variable names. Not that it isn't worth putting in the extra effort to come up with a better name, but I'm guessing that there would be enough violations that the rule would never be enabled.
There's a difference between the ideal goal behind lint rules (whether that's making code better, reducing time spent doing code reviews, or something else) and the practical reality of the time it takes to sanitize an existing code base so that a rule can be enabled. In my experience, people are much more willing to spend the time if the rule helps improve the quality of the executable, and less willing if it "only" helps improve the quality of the code base.
To be clear, I'm not trying to say "don't bother", but I do think it's worth articulating clearly at the outset (a) what the goal of the rule is (improving the quality of names), (b) how we would implement that rule (how do we measure the quality of a name), (c) what the challenges with a rule are likely to be (disagreements about what makes for a good name, needing to support multiple human languages, being able to figure out when adjectives are necessary and when they are not, etc.), and (d) the value of the rule, both in absolute terms and in comparison to others (will anyone use the rule, would it be more productive to spend time writing other rules, etc.).
Personally, I think this rule has a lot of challenges (a good way of measuring the quality of names across multiple languages being one of the more difficult) and not a lot of value compared to many others. As a result, I would tend to encourage spending time on other rules rather than this one.
Agreed, other rules are definitely more valuable that this. I was thinking in the same way @dikmax mentions above, the low hanging fruit that adds lots of noise to names, regardless of them being long or not as @bwilkerson points. Nothing too complicated, I will detail it before working on it.
@alexeieleusis: I'm curious if you made any progress on this one?
Never worked on it :(
I wonder if we could have a few lints that address issues described here. Will be hard to automate, but considering that naming things is a known hard problem in CS ;) even one lint will be valuable.
We should probably look for other places with similar recommendations and even what other tools provide.