[mercora]

i like clear and concise naming and don't care too much about how long it is generally if it helps understand what it does without being extraneously verbose. However, i think there is an argument to be made about how long a single line of code should be before it becomes too hard to read. The example given would be too long for me and i would try to shorten it. In this case probably by implementing some abstraction ;)

[Geminidog]

You claim there is an argument. But you don't actually state your argument.

My claim is that you think there is an argument, but there really isn't. That function name can do no real damage to the clarity or structure of the code. You only wish to shorten it because of OCD.

The logic here is easily illustrated if I rewrote that function name in English:

If my goal was to communicate this to you:

   A function that finds the x y coordinates of dogs cats and baboons in a picture.

This is perfectly ok, but only because it's english. If I tried to write the English as if it was a function.

   func xy_babboon_cat_dog_detector

The above doesn't fly in the English language. But it only works in programming. This is contradictory logic.

The question is, if both programming and English are both mediums used for communication why do they both have contradictory styles?

The reason is because there is no reason behind it. It's the same reason why people in Japan still use fax machines. Habit and typical human irrationality.

When you peel away the layers of your bias you will realize that this contradiction exists because the level of verbosity of my function doesn't actually matter. It doesn't matter in English, and therefore it doesn't really matter in programming.

Seriously, didn't you find it strange that you made your point without even stating what your argument was? Typically if you had a clear reason you would give it, if you had examples you would show it, instead you just said an argument existed probably never realizing what that argument actually was.

It's not just you. The other commentor just reiterated some points without trying to prove any argument. English has a preferred communication style that is contradictory to the preferred programming communication style even though both mediums can go back and forth between either style without any clear difference.

If you self reflect about it, your desire to make my function concise arises more from a feeling and a "emotion." You did not logically deduce your point using evidence... rather you just felt that it needed shortening and that it looks "ugly."

Then when I questioned that logic, your mind, without realizing it, began building a logical scaffold around the feeling to support the desire with some rational framework. Such is human nature, and this type of thing happens for all kinds of strange human biases that we posses. Religion, no doubt, is a similar bias... when questioned the religious persons' brain will go through the exact same process that your brain did upon seeing that ugly wordy function name.

The question is, by going meta and describing the situation in this way would that help you take a step up above that bias? Or will you continue to build that logical scaffold and try to justify your strange desire to make the function more concise for no reason?

Think about this before you reply... did you already honestly have an argument that justified your point? or are you building one right now to respond to me?

This is literally as close as I can get to what I'm talking about. There's this strange bias that every human (including me) has when they first learn programming to write concise "elegant" names for no real purpose. It's so strong that sometimes a normal argument can't help the other party reach an epiphany. Hopefully by going meta I can help better illustrate what I'm referring to.

[simo7]

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]

>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]

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.

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]

> 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.

[simo7]

You're mostly arguing on why your naming preferences are better. You're missing the point, I'm not addressing that.

Instead you seem to agree people name things in the same (irrational according to you) way both in English and Python. Which is exactly my point and what you previously claimed not to be the case.

Once again I am addressing this comment:

    A function that finds the x y coordinates of dogs cats and baboons in a picture.

> This is perfectly ok, but only because it's english.

No, it's not ok only because it's English. It's ok because it's a definition, it is not a name. In English as in Python we tend to prefer more concise names.

A function's name is...a name (duh), the comparison to prose makes no sense. Once you actually compare English and Python names you'll see they both tend to be more concise.

> See past your bias and ignore pointless aesthetics.

Ironically I find your style more poetic (we really have opposite tastes :P). But as you saw we both keep the same preferences independently of the language. No incoherence/bias there. That's the only point I'm making.

[throwaway201103]

The argument is that at some point the length of the name is detrimental to readability, in the same way that a run-on sentence is detrimental to the readability of prose. I thought it was quite clear and your 16 paragraph response didn't touch on that at all. Or if you did, it was lost in the noise.

[Geminidog]

Oh I thought it was obvious that you don't want to rename a function after a 300 word paragraph. I didn't realize we need to get into that kind of semantics. My argument is that a sentence long function name of 10 words roughly is still a good function name. There's no hard rule here. Judgement is still qualitative The main point that I was arguing for is that this:

  find_xy_coordinate_of_dogs_cats_and_baboons_in_picture

is a perfectly good function name. The poster I responded to disagrees with me and I was responding to that specifically.

[pitay]

Your original function definition here:

  def find_xy_coordinate_of_dogs_cats_and_baboons_in_picture(picture: Picture) -> List[XYCoordinates]:

Can be made better by turning it into this:

  def find_dogs_cats_and_baboons(picture: Picture) -> List[XYCoord]:

Reasoning:

'xy_coordinate_of_' taken out because XY coordinates are already in the return type. '_in_picture' taken out because the information is already in the 'picture: Picture' parameter. The return type 'List[XYCoordinates]' changed to 'List[XYCoord]' because Coord is well known as an abbreviation for a coordinate and having XY in front of it makes it completely obvious. Removed the 's' from the end of the return type because it is already contained in a list and shouldn't be pluralised. It would be pluralised if you are returning a list of lists of coordinates.

There are problems with having huge function names, especially if other programmers need to use the functions you write in their code. One is the amount of screen space needed to use your function, this bites when the could be many functions with long names used in a single expression, long names can be harder to understand in that context. There are reasons that mathematical operators in programming languages are usually one character, things like '+ * - /', it should be obvious the problems people writing in that language would have if the operator names were replaced with things like 'multiply'. Now imagine mathematics being written in a verbose English style, it is not done this way because of all the extra effort it would take to write it, and all the extra effort it would take to understand it.

[ptr]

While I do like me some good meta-reasoning, at least I have an argument for shorter function names: Short names are read in O(1) while longer are O(n) (unless the name can be simplified as “the function with the long name”)

[Geminidog]

Then you need to shorten your comment! Not as verbose as my replies but it can definitely use some improvement on the big Oh! Try this out for size:

> me like metareason, me have arg for short func name: Short name O(1), long are O(n) (some name too long: “the function with the long name”)

There's where your logic breaks down. If you truly followed the O(N) argument for all your communication mediums outside of programming you'd sound not so intelligent. Likely you built this argument as a response rather then actually followed it in both your English and programming communication styles.

Better re-examine that meta-reasoning.

[ptr]

It's probably not worth continuing here, seeing that you're already pretty hostile. But I definitely try to minimize the amount of reading necessary to understand a concept. Ideally, the concept should be such that it's easy to describe in few words (note "words", not "letters". Also, using many words doesn't make you sound smarter, often it's the opposite). Things don't live in a vacuum, there's always a context, and that's important to consider when communicating...

[mercora]

my point is that i think there should be a soft limit on how long a single line of code should be because i feel like it becomes too hard to read if they get too long. that is an emotion as you said and it might be kinda arbitrary but i don't think there is something fundamentally wrong with it.

[Geminidog]

Sure there is a logical reason for why you don't want your function to be 4000 lines long. It gets unwieldy and becomes mechanically hard to manipulate or even understand the full meaning behind all 4000 lines. That's a logical argument. I completely agree with the soft limit.

But you stated that this function name:

   find_xy_coordinate_of_dogs_cats_and_baboons_in_picture

needs shortening.

There is no logical reasoning that can justify shortening this function yet the feeling is strong. That is the bias I am trying to illustrate. There is, in fact, nothing wrong with not shortening this function and keeping it as it is.