4 ms·
The problem with your analogy to English is that you're comparing the wrong things. A function is a "thing", you should rather compare it to an entity in the E
by simo7 6y ago
The problem with your analogy to English is that you're comparing the wrong things.
A function is a "thing", you should rather compare it to an entity in the English language.
Why do we say washing machine instead of a home appliance powered by electricity used to wash laundry through the use of centrifugal force?
When naming things you need to balance descriptiveness with conciseness, a name is not a definition.
As a rule of thumb, avoid specifying things that can be easily guessed, especially if they are right there in your function signature (!):
def find_xy_coordinate_of_dogs_cats_and_baboons_in_picture(picture: Picture) -> List[XYCoordinates]:
I'd refactor it to:
def find_animals_in_pic(picture: Picture) -> List[XYCoordinates]:
- Geminidog 6y ago>A function is a "thing", you should rather compare it to an entity in the English language. It's more a verb that does an action on a noun. You can't express the concept with just a word. add one to number >Why do we say washing machine instead of a home appliance powered by electricity used to wash laundry through the use of centrifugal force? Obviously there's no need to describe the plumbing behind the machine just the purpose of the machine is good enough. Everyone understands what a washing machine does as it's culturally a part of our language. If I lived in a civilization without washing machines and I had to implement it as a variable name in code I would call it "clothes_washing_machine" because of added clarity and no actual harm done with the extra word. >When naming things you need to balance descriptiveness with conciseness, a name is not a definition. Sure and I'm saying most people are wrong about where this "balance" actually lies. People place too much emphasis on conciseness. >As a rule of thumb, avoid specifying things that can be easily guessed, especially if they are right there in your function signature (!): I don't like readers to do any guessing at all. It's wrong to make assumptions that a guess that comes easily to me will come easily to my audience such is the nature of documentation and documentation as code. I want people to read my code like they read english. But that's just my opinion. def find_animals_in_pic(picture: Picture) -> List[XYCoordinates]: I mean what's the benefit of shortening this. I'm looking at this function and I'm feeling nothing happened. You just did extra work. If I want to be nit, XYCoordinates should not be plural, List should contain many Types each called XYCoodinate. XYCoordinate(s) is better used as an alias for the entire list. Additionally my function only operates on cats, dogs and baboons. It does not operate on all animals. Someone can mistakenly use this function to try to find lions and tigers and bears Oh my! But that's besides my point. You attempted to shorten my function name while preserving meaning for which I totally understand the point you were trying to convey. What I'm saying is your changes are logically negligible. They do nothing to improve understanding of the program while trivially shortening things. Nothing practical occurred here. It's simply the scratching of an OCD need for more poetic names.
- simo7 6y agoNB: I'm answering to the claim that we behave differently when naming things in programming languages vs natural languages. Otherwise I think it's mostly a matter of preferences. I understand you prefer to be more detailed in your naming, that's fine, but in natural languages your names would sound unusual/verbose as much as they do sound unusual/verbose in Python. You say everybody understands what a "washing machine" is therefore a short name. Are you saying that when washing machines were still a novelty they should have been called "clothes-washing machines" instead? Unusual naming right? People do seem to have a distaste for long and overly-detailed names in spoken languages as well, don't you think? And what's the point of a dictionary if names embed a full definition that leaves nothing to be guessed? > Sure and I'm saying most people are wrong about where this "balance" actually lies. People place too much emphasis on conciseness. Where to draw the line can be a matter of preferences, no intention of debating that, but people do tend to draw the line the same way whether they speak English or Python. No incoherent behaviour there.
- Geminidog 6y ago> NB: I'm answering to the claim that we behave differently when naming things in programming languages vs natural languages. Otherwise I think it's mostly a matter of preferences. And I am saying this behavior is attributed to an irrational instinct. There is no practical logic to it even though are instincts push us to behave this way. >I understand you prefer to be more detailed in your naming, that's fine, but in natural languages your names would sound unusual/verbose as much as they do sound unusual/verbose in Python. The purpose of an action is to serve practical purpose. Something sounding unusual has nothing to do with whether the associated action was practical or impractical. A name may sound unusual in python and suddenly sound perfectly fine in english. How this name sounds has nothing to do with the actual practical significance of the name. If the name is informative then it is practical. Place that name in python, place it in english. How you feel about the name and how you think it sounds is irrelevant to your purpose of practicality. The practical goal here is maximum clarity with zero ambiguity. Your instincts and feelings are lying to you. You are subconsciously reacting to a purely aesthetic attribute. A poetic and elegant name does not serve an actual purpose. Only an informative name serves an actual practical purpose of being informative. We program to make things work, not to come up with function names that are poetic/brief/unreadable. An aesthetically pleasing name does assist us in achieving the actual goal of our program but an informative name does. >You say everybody understands what a "washing machine" is therefore a short name. I'm saying anyone in our culture who speaks english. >Are you saying that when washing machines were still a novelty they should have been called "clothes-washing machines" instead? Unusual naming right? People do seem to have a distaste for long and overly-detailed names in spoken languages as well, don't you think? I'm saying in a hypothetical culture where we didn't have context on what a "washing machine" was "clothes-washing-machine" would properly communicate the intent and meaning about what that machine actually does. I am able to throw away any preconceived biases I have and not assume that a machine that washes things only washes clothes. Keep in mind I prefixed my entire point with a hypothetical culture that didn't know about "washing machines"... you seemed to have missed the fact that I did that. >And what's the point of a dictionary if names embed a full definition that leaves nothing to be guessed? There would be no point to a dictionary. But clearly the things we define in most functions aren't defined in the dictionary so rather then make up names no one can understand you can combine english words that everyone understands into sentences and phrases and use those to Name your functions. >Where to draw the line can be a matter of preferences, no intention of debating that, but people do tend to draw the line the same way whether they speak English or Python. No incoherent behavior there. Everything is a matter of preferences. Even believing in 1+1=1 is a preference you can choose to believe in. I am saying in terms of of the set of attributes people hold to qualitatively describe whether or not something is practical, most people mistakenly believe that poetic and terse function names possesses the very same attributes they hold as "practical." TLDR: I am saying once people understand my point, most peoples preference are in full alignment with my preference. I am saying when you ignore your inner OCD, you will see that aesthetic/poetic/elegant naming serves zero practical purpose and short and brief names have negligible practicality when compared with long names. Thus a slightly longer function name that is ugly but very very informative and similar in grammar to the english language is the most practical and logical way to name your functions. It doesn't matter how "unusual/verbose" you feel that it looks/sounds as that feeling is orthogonal to the logical purpose of your naming in programming: to communicate and inform. See past your bias and ignore pointless aesthetics.