4 ms·
I'd suggest that `count(customers)` or `incrementScore(goodCustomers, delta)` are shorter, more readable, don't embed type information in the variable name (e.g
by Huggernaut 8y ago
I'd suggest that `count(customers)` or `incrementScore(goodCustomers, delta)` are shorter, more readable, don't embed type information in the variable name (e.g. what happens if you realise your customers are actually a set, not a list), and don't end up embedding type information in your function name (e.g. what if I want to count employees).
Also, by not including semantic information in the variable, it also requires this to be conveyed everywhere else e.g. your function names. You rightly point out that hopefully there's tight context around this thing (e.g. it's only about customers) and maybe you can leave that out, but over time as code changes and grows in weird ways, this may not always hold.
What do you think?
- Yokohiii 8y agoEmbedding types in the method names is a habit of using dynamically typed languages. If the method is private it can be shorter, if it is public it should be a bit more descriptive. With statically typed languages I'd agree with your suggestion, but i'd likely would remove the type info from variables as well.
- nailer 8y ago> If the method is private it can be shorter Won't other people still need to read private code?
- Yokohiii 8y agoOf course, but the scope is heavily limited. This doesn't justify nonsense naming, but it can be very compact.
- emodendroket 8y agoTo me, if you feel compelled to start putting type information in the variable names, function names, etc., what you're showing is that you really want a type system.
- marcosdumay 8y agoHaving types on your API names is a good indicator that you didn't abstract your problem in separable enough concerns. It does help one turn a bad API into a bad API that will lead to slightly less bugs.