[Geminidog]

The bigger tragedy is the illogical need for programmers to come up with "elegant" names. A 20 character name doesn't do any damage if it communicates the correct point. Neither does a 10 character name that also communicates the same point.

Why does a developer favor the 10 character name over the 20 character name when both do the exact same thing? Is the goal to save memory? What is the point? There is no point.

It is a subconscious bias that makes programmers want to give things elegant names over clear names. There is no harm in creating a 40 character name that is ugly.

   def find_xy_coordinate_of_dogs_cats_and_baboons_in_picture(picture: Picture) -> List[XYCoordinates]:
          #there is NOTHING wrong with this function name.

It baffles me to no end why humans have a tendency to turn the above for no clear reason into:

   def imgrecFindAnimal(p: Pict) -> List[vectxy]:

Beauty and elegance in code belongs in structure not naming. Clarity belongs in naming not structure (Golang is the antithesis of this). When both are unionized perfectly you get elegant code that does not sacrifice clarity.

A really good example of this is a function that encapsulates a complex regular expression. That regex is all but unreadable but you can embed an entire comment/description into the function name. Seriously write a grammatically correct sentence and make it a function name, there is no reason why this is bad... was there a more elegant name that you could have came up with??? Who cares. No harm done with your huge name other than burning the eyes of your inner OCD.

Except of course if you don't have auto complete. Then I can see how it's annoying for you to type out a whole sentence when you just want to call a function.

[tomxor]

> A 20 character name doesn't do any damage if it communicates the correct point.

That depends on the context. If the function is the highest level task called infrequently (as in your example), then long highly descriptive names are completely fine.

If this occurs at every level, all the way down to the building blocks it absolutely, severely affects legibility of the entire code base - it is literally a multiplier of code size, in the worst case of "all the way down" it's some kind of power function.

This barely fits on a line:

  (a leftmultipliedbyright (a leftsubtractedbyright 1)) leftdividedbyright 2

Yet it's a simple polynomial that should just be a(a-1)/2, probably part of a larger expression, now the other parts will end up on other lines (because no one writes 500 char width code), the effect is artificially spreading code thinly - this destroys locality and legibility.

You would be right to point out my example is extreme and absurd, however operators are functions, they only use different, implicit syntax. Many intrinsically complex pieces of code must create their own domain specific building blocks at a slightly higher level of abstraction that are much like operators, and this is the place for extremely short function names (think vector libraries), as such a commonly used building block it is unreasonable to expect each reference to fully and explicitly express the functions purpose.

As with all of these types of things, there is a balance, I am arguing _for_ balance, not suggesting all names should be single letter or single word - but that they have their place. However in my experience very long names are far more commonly due to thoughtlessness, they include excessive redundant context and at worst even grammatical words.

[MrPatan]

You are right in everything you say, and I'm just replying to your comment because it seems like a good place to say my piece:

Why do we (devs) know that one-letter variables are bad, but still don't know that one-letter generic types are bad?

Why do we put up with this (random function from rxjs):

    export function concatMap<T, R, O extends ObservableInput<any>>(
      project: (value: T, index: number) => O,
      resultSelector?: (outerValue: T, innerValue: ObservedValueOf<O>, outerIndex: number, innerIndex: number) => R
    ): OperatorFunction<T, ObservedValueOf<O> | R> {
      return isFunction(resultSelector) ? mergeMap(project, resultSelector, 1) : mergeMap(project, 1);
    }

Why T and not INPUT_TYPE or whatever it is (see? I can't tell!)?

[Aeolun]

Wait, you can use more than 1 character for generic types?!

My whole life is a lie!

[rShergold]

Bit late to the party but I really enjoyed this comment and the subsequent conversation. I was given some advice when I was junior and I've been repeating it for years.

Code it read 100 times more than it is written/edited. Writing in a high level language is writing for a human first and a computer second.

As a general rule of thumb a variable name should be as big as the scope of that variable.

* If it's scope is one line it's okay to use a single letter.

    deletedDocuments = documents.find(d => d.deleted)

* If it's within a block normally one or two words will be fine.

* If it's one file, 3 or 4 words.

* If it's global it should read like the opening paragraph to war and peace.

The last two are generally indications that something has gone wrong with how you are encapsulating your code and you should consider a refactor. However you will often have no other option in which case always lean towards more descriptive not less.

[akavel]

For the same reason some non-programmers seem to also value conciseness:

https://quoteinvestigator.com/2012/04/28/shorter-letter/

I think it may boil down to highly respecting the readers' time. If something conveys the same information to them but is shorter, it will appropriate less of the precious limited time of their lives. Notably this then becomes a subtle balancing act of estimating their knowledge and intelligence: make it too short and some implied context may be lost and require extra effort to research from them. An extreme example is science papers - the same paper can be clear and concise for you if you are an expert in the domain (the usually assumed audience), or an overwhelming effort if you're not.

[Geminidog]

I agree with this in general.

For programming, specifically, though, I feel the typical style used in programming straddles the line where the brevity hits a point of obscurity that actually leads to more time spent trying to decipher meaning.

I would say the time that is lost to deciphering meaning is much much more detrimental then time lost to parsing over-verbose words by a very large margin. Thus it's better to err on the side of longer names in programming until the verbosity is equal to the English language. I mean nobody complains about the English language being way too verbose, so why not bring programming up to the same level of clarity and verbosity?

Better to over communicate so they say.

[akavel]

That's an interesting argument. Personally, I don't think I agree, i.e. I feel very differently (though e.g. typical Haskell is an example of being too dense for me too). But I can't currently capture the feeling in more concrete words. That said, if we're both now speaking about what we feel, did I manage to at least succesfully counter your argument about this being illogical? ;)

One question came to my mind that I'm curious what's your take on, from the point of view you present: what's your opinion on notations such as: numbers (i.e. 123 vs. English language: hundred twenty three), and chemical formulas (e.g. H2O vs. English language: particle of water)?

[Geminidog]

>But I can't currently capture the feeling in more concrete words.

I mean if you want something more quantitative: Count the amount of posts in this thread that were communicated with a programming language as the primary mode of information transfer versus the amount of posts that used English instead.

Because the usage of Verbose and wordy English exceeds the usage of code one can conclude that people prefer the general wordy nature of English over the conciseness of code.

Due to this, it makes sense to make your code as close to verbosity as English as possible. I can read a novel or magazine almost passively, the same cannot be said of code.

>One question came to my mind that I'm curious what's your take on, from the point of view you present: what's your opinion on notations such as: numbers (i.e. 123 vs. English language: hundred twenty three), and chemical formulas (e.g. H2O vs. English language: particle of water)?

Whatever makes sense. 123 and one hundred and twenty three basically communicate the same thing. Humans as a whole prefer 123. There's no lapse in communication using either method. "One hundred and twenty three" takes a bit longer to read but no crime was committed. 123 doesn't lack any clarity for a typical human being either.

Perhaps I would prefer 123 as Arabic numerals are more universal globally then English.

For chemical formulas, H2O is used for balancing equations. It's specific notation for an algebra of using symbols to derive an exact conclusion, it is less a form of communication and more a system of symbols used for solving problems.

H2O, specifically, however, has culturally entered English nomenclature as a well known concept so it can be used in naming. There is however a slight potential for confusion so ultimate clarity makes more sense to me here. There is zero ambiguity with "particle of water" or even "H2O molecule" and thus my preference is to use English if the goal is communication.

The thing that you have trouble putting into words here is H20 is an elegant symbol that communicates the exact same concept then the uglier "particle of water." Humans are instinctively reacting to an aesthetic issue not a practical one. Again no crime is committed when someone uses the variable name "particle_of_water" in a programming language over "H2O."

I didn't go into it in other arguments but I will get into it here because you've noted to me that you have identified this "feeling" and you acknowledge the contradiction between English and coding.

The reason why the contradiction exists is purely an aesthetic issue. It's a response to what we consider categorically to be "ugly" and "beautiful" and has nothing to do with practicality. When viewed this way the contradiction between English and programming languages makes sense:

We define bad grammar in English as "ugly" but we also have a separate aesthetic sense for poetically naming things. This comes from beyond just programming. For example humans generally find "the White house" to be a better and more poetic name for "The place where the president of the United States" resides.

There's actually two separate modules in your brain here that are odds here. Bad english grammar is clearly triggering the language module in your brain, but at the same time your brain has a poetic naming module that prefers "The White house" over "presidents place of residence" and this module is being triggered when you program or write poetry. You can only begin to see this when I point out the logical contradiction.

Both of modules in your brain are bypassing the neocortex of the brain where people conduct higher order logic. It's actually very hard to realize this if it's not pointed out as people often mistake these feelings for being something that arose from their own internal higher order logic. The whole point of my writing take all of these modules in your brain and place them at odds so you can identify the origin of each and give your neocortex executive control. Anyway here are the three modules that are getting triggered:

  - Bad english grammar triggers the language module in your brain. 
  - Verbose naming in code triggers the poetry module in your brain.
  - The logical contradiction between the two modules above when identified through meta analysis triggers your neocortex. 

Now that you know, you can step above it all. You can override instinctual your emotions and use your higher order logic to come to the correct conclusion.

To go a bit off on an tangent here there is in fact a morality module in your brain as well! What most people consider to be good and evil is actually instinctual emotions triggered by this module! Again similar to the main topic, most people don't realize this and believe their morality is built around logic when in actuality people are all just building a logical scaffold to justify a pre-existing instinct. Think about it... same with the whole whole poetic naming instinct we have, morality actually starts out as a feeling before we begin to logically justify it.

Believe it or not using the exact same method of pointing out logical contradictions I can actually prove to you that morality is in fact an instinctive module within your brain. It's off topic though, and I've digressed to much, so I won't get into that here.

[IncRnd]

You wrote 295 words to state then restate a single point - that you don't see an issue with verbose naming.

You demonstrated the equal importance of correctness, completeness, and also _brevity_.

[Geminidog]

No there's a difference. :) I made a point AND proved my point by showing a contradiction in human logic.

While I agree that the length of my argument made you not actually read it at all and miss the entire point, proving a point with illustrative examples does necessitate such verbosity.

What you're doing is stating a point without proving it and claiming that my own argument is self defeating with no explanation.

Why don't you try proving your point and also countering my proof while being concise at the same time? Because right now you just stated a point with nothing. You're stating in a single sentence the world is flat after I Proved it's round. Ok... So what? prove it.

[BlargMcLarg]

They proved their point already. You took much longer and much fancier wording to say what could be said in a few lines, without losing any meaning. Verbosity for the sake of verbosity.

This is what I mean. Using long names compounds not only on itself. It compounds onto the entire codebase. Unless you blackbox the code, make it 100% bug free and it doesn't require changes for future features, that code will be read. Reading takes a lot of time, but worse: it takes far longer for someone to process a much larger cognitive load. This is especially dangerous in huge codebases that need to be changed on a regular basis, usually retorted by "it takes time to get in the swing of things".

We have better things to do in life. Respect the person who will read the code. Be concise.

[Geminidog]

In all my arguments I'm saying that this logic you present doesn't apply to English. Nothing was proven because my points weren't addressed.

You're not respecting my time with your grammatically correct comment above. You can shorten your comment by mangling the grammar and preserving the meaning.

>We have better things to do in life. Respect the person who will read the code. Be concise

See that sentence it's wasting my precious time you can get rid of a lot of unnecessary info and preserve meaning.

>We have better thing do. Respect reader. Be concise.

There. same point but more concise but now you sound as if you have brain damage. My point is we use programming languages and english to communicate a point, but clearly in english nobody takes any effort to respect anyone's time. It's full of wordy unnecessary stuff and the entire population of english speakers actually prefers reading this very verbose english then reading obscure code.

I am saying because of this contradiction all your logic flies out the door.

Bring the level of verbosity of code to the level of verbosity in english. We don't complain about english, we actually prefer it over code. So clearly nobody is actually caring about 'saving' those precious seconds of reading long grammatically correct sentences. Who cares if someone uses it as a function name.

[BlargMcLarg]

You spent so many words, yet you still side-step the main argument, and then further ridicule my argument by taking it out of context.

These are different contexts. I do not wish to read a 300 page manual when it can be described in 2 pages, similarly to not wanting to scan 10 pages worth of code that has hundreds of thousands of code I may be expected to have to look at. I require both enough energy and insight to solve the problem after reading.

This is a discussion forum. We write differently here. Information sharing is not our prime objective, unlike writing code.

>I am saying because of this contradiction all your logic flies out the door.

Contradiction solved. Now, will you answer or continue to side-step?

[Geminidog]

> You spent so many words, yet you still side-step the main argument, and then further ridicule my argument by taking it out of context.

Nothing is being ridiculed here nor taken out of context. This is simply a misunderstanding by you.

As for the side stepping... It's a matter of perspective. From my perspective you are the one side stepping because you didn't even bring up the contradiction. So I'll regurgitate your words right back you were side stepping the contradiction thank you for finally addressing the issue.

>These are different contexts. I do not wish to read a 300 page manual when it can be described in 2 pages, similarly to not wanting to scan 10 pages worth of code that has hundreds of thousands of code I may be expected to have to look at. I require both enough energy and insight to solve the problem after reading.

Let's frame the context here so that we both agree. The context is to communicate a concept to a reader WITHOUT being verbose. Code and English both live within this context because you use code to communicate to other programmers and you're using English to communicate to me Right Now.

We can also agree that BOTH code and english can be over verbose.

Context Established.

>This is a discussion forum. We write differently here. Information sharing is not our prime objective, unlike writing code.

Information sharing is the prime objective Of all written and verbal forms of communication. You need to understand this. There is zero point of writing anything if it is not communicating a point. Any form of communication is a form of information sharing, and english being a medium of communication which makes it a medium for information sharing.

Have you ever heard of "Documentation"? Documentation communicates the EXACT same information that code does but better because it's in English and more verbose. That's why Documentation often exists along side code. One can derive code from documentation and documentation from code.

>Contradiction solved. Now, will you answer or continue to side-step?

Contradiction not solved. You still need to address it. English and programming occupy the same context with English actually being used within programming. Think about it, Programming is basically a shitty version of english that's only used because a computer understands it. Nobody would be programming otherwise. If you can program a computer efficiently using English I guarantee you traditional programming languages will be thrown out the door within a day, nobody will use it anymore.

So the context that programming occupies is two fold. It occupies the same context as English to communicate with other people, and at the same time it also has to communicate with a computer. That is the prime difference. So why do we have reduce naming to some poetry contest when you can write a fully grammatically correct and clear sentence as function name and call it a day? We don't do it in English why can't we stop doing it in programming? The contradiction is still there and still invalidates all your points.

There is no logical reason why we shouldn't bring programming up the same level of clarity and verbosity as English. The only thing stopping us are the technical limitations of the computer, so we should get as close as possible with what we currently have.

[GuB-42]

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

It is redundant. It doesn't need the "xy_coordinate" because that is the return type. Furthermore it is wrong, it should be "xy_coordinates", with an "s". Or it shouldn't return a list.

The "in_picture" part is also redundant, it takes a Picture argument so why mention it?

Note: these arguments depend on whether you language supports polymorphism or not. In C for instance, you often have no choice.

The "dogs_cats_and_baboons" part is fine as long as it really is what you are looking for. If your intent is to find any animal and you implementation only finds dogs cats and baboons now, then you should call it "animals" with maybe a comment clarifying that point.

The problem with long fonction names is that they produce long lines. Long lines are terrible. Not as bad as they used to, thanks to large, wide screens but still, I hate having my editor window unnecessary large or have a horizontal scroll bar.

[minot]

I think the point is that you should use Longer names where possible.

Powershell’s Set-Location is better than shell’s cd.

Invoke-Webrequest is better than curl.

npm install —-global is better than npm i -g.

There was a need for names to be short forty years ago. We don’t have that anymore.

You might know that you’re dealing with x, y coordinates but how do I know there is no z?

Senior developers tell me to fix the problem in the correct spot. We can have aliases but the default should be long names.

[bjohnson225]

For maximum readability you want function names which are descriptive, but concise. My personal pet hate is when people make it concise by using acronyms and I’m just left wondering what the hell it stands for.

Personally, I find the ‘in_picture’ suffix superfluous as it’s clear from the input parameter what you’re finding the animal in, but otherwise find it a good name.

[ericb]

> My personal pet hate is when people make it concise by using acronyms and I’m just left wondering what the hell it stands for.

I agree. I can find, and understand reducePermissionLevel, but reducePermLvl is unguessable, and not searchable because abbreviations are arbitrary. Never abbreviating provides a predictable scheme.

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

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

[wolco2]

Shorter is easier to read and understand at first glance.

Writing a paragraph kills any formatting in vi/vim.

Why not write a comment if a paragraph is required to understand what you are doing.

This sounds like Hungarian notion taken to the extreme.

[Geminidog]

>This sounds like Hungarian notion taken to the extreme.

No it's sanity taken to the extreme.

Have you ever noticed that all things written to communicate things to people in the United States outside of programming is written in a very verbose manner using a language called English? It's used for technical manuals, text books, and stories.

Is English "hungarian notation taken to the extreme?" No dude. People actually find verbose English stuff easier to read. You don't have English writers abbreviating words and coming up with elegant acronyms in a physics text book.

>Why not write a comment if a paragraph is required to understand what you are doing.

I didn't say name your function after a paragraph. A functions English language analog is a word and at most a sentence. A paragraph would be several functions chained together. If you name your functions well, composed procedures will read close to an actual English paragraph.

That being said there's nothing wrong with comments, comment away but don't call your function doXYZ and put the entire description in the comment. Your comment doesn't follow the a function call.

Here's an example:

    list_of_profiles = get_list_of_profiles_from_file("profiles.txt")
    list_of_profiles_named_bob = filter_profiles_by_name("Bob", list_of_profiles)
    list_of_profiles_named_jane = filter_profiles_by_name("Jane", list_of_profiles)
    list_of_profiles_named_bob_and_jane = concatenate_profile_lists(list_of_profiles_named_bob,
                                              list_of_profiles_named_jane)
    list_of_pairs_with_a_married bob_and_jane = merge_married_profiles_into_list_of_pairs(
                                                   list_of_profiles_named_bob_and_jane)

Trust me, you may think your eyes are bleeding but they are not. The above is actually closer to the English language then 90% of code out there. What you don't realize is that there wasn't a need for a single comment and there wasn't a need to dive into any of these functions to read the definition. You just read the variable and function names and you know exactly what's going on. If you recompose these functions to do something else it's like recomposing sentences and words in the english language. The end result is still readable without the need for new comments.

When you read a recipe or follow directions to build something does the writer give you those directions in some coded nomenclature? No the writer writes verbose English with clear grammar. The point is clarity in naming in these entities, it makes zero sense why we don't do the same in programming.

>Writing a paragraph kills any formatting in vi/vim.

You know this might be a really different chain of thought that goes against the grain...

But maybe due to this lack of formatting in vi/vim makes vi/vim an extremely bad editor for programming? Seriously, humans are weird (Japan for example still uses fax machines). If it's so bad why do so many people use it? Maybe to look smart or maybe for the same nonsensical irrationality as to why we have to come up with some unreadable but "elegant" name for every programming primitive but at the same time we have to be extremely verbose for ALL other forms of written communication with English.

Programmers like to think they're smart and original. Most aren't... they follow the same tropes as every other programmer trying to come up with elegant names for no reason whatsoever and strangely unable to see the purposelessness behind this whole naming thing. If you can't come up with a good "name" for it, make the name an entire sentence, it's that simple... it's the reason why sentences exist.

[BlargMcLarg]

"from_file", "by_name", etc. are fairly needless here. Most people are apt enough to grasp the first argument relates to the last word of the function name. Use properly named variables so a summary can take care of it, or only omit the noun, "get list of profiles from".

Get itself is a terrible prefix and could be omitted, especially if you keep "from". "list_of_profiles_from(X)" isn't any less clear. Alternatives like "read_list_of_profiles(file)" exist.

"List_of_profiles" can be changed to "profile list". You already did it with "concatenate_profile_lists", showing inconsistency. Alternatively, depending on the context, "list" itself can be omitted entirely, and just state "profiles".

"merge_married_profiles_into_list_of_pairs" can arguably be shorted to "merge_married_profiles" depending on IDE and language: that last bit should be clear from the returned value. Even without, it can still be shortened to "pair_married_profiles", as the context should make it obvious if we look for more than 1 married couple, there will be some kind of collection. Additionally, your naming has one problem: "merge_married_profiles". With all the verbose naming, it is still not clear what "married profile" is. I'll assume it means "pair profiles of married couples", where you might as well say "pair_profiles_of_married_couples".

>Programmers like to think they're smart and original.

It is because they think to be smart and original, they fall into the trap of overly verbose naming. Not from a lack of it. Have you looked at a legacy Java code base? Many of them can be slashed in half just by renaming variables to something that keeps the meaning, or draws meaning from the context very obviously. These guys are going against their own mind's natural ability to read context, or worse, conditioned themselves to learned helplessness.

[spion]

They are in fact bleeding.

Clear writing is about structure, not verbosity or repetition. Concise-and-clear is preferred over verbose-and-clear.

[ybothr]

You mean "being more conciseness is better if you don't have to sacrifice clarity for it"? Or just - "conciseness is a good thing"?

How would you rewrite that example, specifically, to make it more concise without sacrificing clarity, then? Do you mean to change the names without omitting type or relational information somehow? Or to omit some variables entirely in favor of nesting function calls?

If the latter, I don't see the relevance to that commenter's actual point about short vs long names; reducing the number of names is entirely tangential.

[spion]

I would omit most information that can be inferred from context so long as context locality is good.

Single-letter names are OK for context smaller than 1 line (like lambdas), type information can be omitted for context up to 10 lines (lists etc) and generic functions (filter, concat, inner_join) are better over custom domain functions when the audience consists of other programmers.

Abbreviations are best avoided unless they are extremely common and familiar in the specific domain / industry. If they are only ever used within that team and company, that's probably bad.

Example here: https://news.ycombinator.com/item?id=25477495

[Geminidog]

>I would omit most information that can be inferred from context so long as context locality is good.

context also changes with time as other people edit your code. Your single variable name with simple context can balloon in complexity and move around. Don't assume locality is fixed.

Additionally locality wastes precious time. It is preferable to read a variable name and not even need to touch context.

>generic functions (filter, concat, inner_join) are better over custom domain functions when the audience consists of other programmers.

Not true. For filter and innter_join especially the predicate or inner lambda can be intricately complicated and hard to decipher, better to wrap all that complexity in an english name. You save programmer time by having the programmer read an english over deciphering even simple code.

Rule of thumb: It is far easier to read one line of english then it is to read a one line of code. So it is better to allow readers to ascertain meaning from naming over context. You are wasting the programmers time otherwise.

[Geminidog]

>They are in fact bleeding.

>Clear writing is about structure, not verbosity or repetition. Concise-and-clear is preferred over verbose-and-clear.

Except this is where the contradiction lies. In both well written literature and great text books... clarity trumps all even when conciseness is sacrificed. English is one of the most verbose languages out there. I can take your sentence and make it concise:

>My eye bleed.

>Writing about struct. No verbose or repeat. Short n' Clear beter den wordy n' Clear.

Is that better? Your misguided logic paints my concise version of your comment as "preferred" even though it has the exact same clarity. The stark reality is, for purely human reasons, people prefer the former example over the later and there is no real rationality behind it.

Try to think a bit outside of the box here. You share the biased and delusional opinion of a typical average programmer.

The real logic is, that the conciseness or verbosity is inconsequential. Our human nature allows us to prefer contradictory approaches in code vs. english because verbosity and conciseness doesn't actually matter that much. Clarity is king by a long shot hence the reason why most humans prefer reading literature over code.

My code displays the ultimate clarity. You insultingly claim that your eyes may be bleeding, but I guarantee you that unless you're mentally deficient, no part of my code was unclear. It was 100% obvious and crystal clear what my intentions are. The best part is, you only need to read it one time.

When is the last time in your life you've read a similar snippet of unfamiliar production code at first glance and left with the exact same level of clarity? Most similar production code needs a good number of guesses and hypothesis and a couple of reads and code following to develop the same level of clarity and confidence of understanding that my code can produce on a SINGLE reading.

I would wager we can agree on that point and if your claim otherwise I would wager that you are lying.

[yxhuvud]

The problem is that all those words make it harder to find the meaning. Well-chosen naming exposes it.

[Geminidog]

If it can be found. But more often then not it can't be found. Do you always search for the most elegant single word to describe a point in English? Sometimes. But more often then not you have to resort to sentences.

There's no reason why this logic can't be applied to programming.

[amatecha]

Yeah, I don't need conciseness or brevity. The processor or the network connection needs conciseness. Programmers need specificity and clarity. Verbosity is fine too, IMO :)

[spion]

My comment was already concise to begin with. Your change reduced clarity. Here I will exaggerate your example:

    list_of_profiles_that_we_got_from_reading_a_file_named_profiles_dot_txt = get_list_of_profiles_from_file("profiles.txt")
    
    list_of_profiles_from_the_file_named_profiles_dot_txt_which_are_filtered_by_name_where_the_name_was_bob = 
      filter_profiles_by_name("Bob", list_of_profiles_that_we_got_from_reading_a_file_named_profiles_dot_txt)
    list_of_profiles_from_the_file_named_profiles_dot_txt_which_are_filtered_by_name_where_the_name_was_jane = 
      filter_profiles_by_name("Jane", list_of_profiles_that_we_got_from_reading_a_file_named_profiles_dot_txt)
    combination_of_the_profiles_from_the_profiles_dot_txt_file_containing_both_the_profiles_with_a_name_bob_and_the_profiles_with_a_name_jane = 
      concatenate_profile_lists(
        list_of_profiles_from_the_file_named_profiles_dot_txt_which_are_filtered_by_name_where_the_name_was_bob,
        list_of_profiles_from_the_file_named_profiles_dot_txt_which_are_filtered_by_name_where_the_name_was_jane
      )
    list_of_pairs_from_the_profiles_txt_file_where_the_first_person_is_named_bob_the_second_is_named_jane_and_they_are_also_married = 
      merge_married_profiles_into_list_of_pairs(
        combination_of_the_profiles_from_the_profiles_dot_txt_file_containing_both_the_profiles_with_a_name_bob_and_the_profiles_with_a_name_jane
      )

There is a point where verbosity decreases clarity by overwhelming the reader with irrelevant detail which can already be inferred from context.

Lets try a concise example:

  profiles = get_profiles_from_file("profiles.txt")

  bobs = profiles.filter(p => p.name == 'Bob')
  janes = profiles.filter(p => p.name == 'Jane')

  marriages = bobs.inner_join(janes, (bob, jane) => bob.partner == jane)

Does it matter whether profiles is a list or not? If the typical data structure / convention you use for plural variables is a list, you don't have to say it.

Do I have to say that the variable bobs is a list of people named bob? Not if its obvious from the context on the right hand side that I'm filtering by name

Do I have to use a more verbose argument name in the lambda passed to `filter`? Not really - its short and there is plenty of context around to deduce that its a profile, especially if the reader is familiar with a commonly used standard library function.

The last one is tricky, and it depends who you're communicating with. Do you expect your readers to be familiar with the standard library of the language, even less commonly used functions? If so, then its fine. If not, again it depends. Is the reader familiar with SQL or relational algebra? If so, then yes they probably have no problem with this.

As long as your context and conventions are clear, you can leave a lot of details out and still get the message across. Its better to err on the side of caution, yes, but it doesn't mean that unlimited verbosity leads to unlimited clarity. As with writing - your audience is what matters.

[Geminidog]

> My comment was already concise to begin with. Your change reduced clarity. Here I will exaggerate your example:

Your comment was concise because it was just a statement. You didn't attempt to prove a point.

My comment was a proof against your point hence why it's longer. Now you're trying to disprove my proof which also explains why your subsequent reply is also significantly longer.

> There is a point where verbosity decreases clarity by overwhelming the reader with irrelevant detail which can already be inferred from context.

I agree with the above completely, but I also think the point is obvious. I never stated there was a level of verbosity that is excessive because I thought that notion is actually completely clear to all readers.

Here's a good rule of thumb to follow. We clearly don't think the English language is too excessive in verbosity. So All I'm saying is bring programming to the level of verbosity of English and don't go past that.

Obviously your first example is excessive and past typical English verbosity. But your second example is below English verbosity and has several problems.

> Does it matter whether profiles is a list or not? If the typical data structure / convention you use for plural variables is a list, you don't have to say it.

It doesn't hurt if I put "list" or "profiles" in the name it's just some additional letters letters and adds more information. It doesn't matter at all. Also your assumption is wrong. Many containers can be plural including linked lists, hash maps, trees and graphs.

>Do I have to say that the variable bobs is a list of people named bob? Not if its obvious from the context on the right hand side that I'm filtering by name

You don't have to, but you don't not have to either. The Bob variable can be used in a section very far away from the context... then what is a bobs? What is a janes? How do you even know it's a list of profiles? You're literally making me follow and decipher code to figure it out. That is the point. Give a function an English name where I don't need to decipher anything. I read the function name and I don't have to dive in to decode anything.

>Do I have to use a more verbose argument name in the lambda passed to `filter`? Not really - its short and there is plenty of context around to deduce that its a profile, especially if the reader is familiar with a commonly used standard library function.

There is nothing you "have to do" here. You can do whatever you want. I am saying what you're doing is actually is worse for communication and that my way is better for communication with the incredibly negligible downside of being more verbose. That being said context can balloon in complexity, reading code is harder than reading english so make the reader read english when he can rather then code.

>The last one is tricky, and it depends who you're communicating with. Do you expect your readers to be familiar with the standard library of the language, even less commonly used functions? If so, then its fine. If not, again it depends. Is the reader familiar with SQL or relational algebra? If so, then yes they probably have no problem with this.

All your variables can be used far away from the context where they are created. You can't rely on the fact that the creation of Bobs is right next to it's usage in marriages. Often times your style of coding will result in people having to follow code and dive into definitions to figure stuff out.

First off marriages. Marriages of what? Sam and Bob? George and Shirley? Second the expression itself. Again what is a bob and jane? What is a partner? Partners in crime? Also seriously:

   bob.inner_join(janes, (bob, jane) => bob.partner == jane)

compare the two.

   list_of_pairs_with_a_married bob_and_jane = merge_married_profiles_into_list_of_pairs(
                                                   list_of_profiles_named_bob_and_jane)

I think most people will agree that mine is more clear in communicating what's going. Your version despite the brevity needs some deciphering.

Also you can't expect that the profile data structure is so simple that it can be done in a one liner. You assumed the data structure to be very simple. What if the data structure is an incredibly complex graph structure of profiles. Marriages can only be found by a complex graph algorithm. I don't want people to decipher a graph algorithm to decode what I'm trying to do here.

Write your function names so people can avoid deciphering meaning from context. The point is so people can decipher meaning from English because English is ten times easier.

[throwaway201103]

Programming is more like mathematical notation than english prose.

In mathematics we write a² + b² = c² to describe the relationship between the lengths of the sides of a right triangle. We don't write it out in english words longhand, because the notation is brief, packs a lot of meaning into a small amount of space, and lets our minds focus on larger concepts rather than parsing long phrases and keeping their meanings organized.

[Geminidog]

>In mathematics we write a² + b² = c² to describe the relationship between the lengths of the sides of a right triangle.

Therein lies the problem. Can you explain to me the meaning of a² + b² = c² without English? Can you just write down an equation and expect me to know what you're talking about?

Can you explain to me the concept of entropy by just showing me all the equations?

Can you explain to me the meaning of your program with only one letter variable names as shown in your Pythagorean equation above?

You can't. That's why math texts consist of equations AND English, and there's no reason programming shouldn't either.

Anyway a side note, have you ever heard of literate programming?

[MrPatan]

Yeah!

Why is matematical notation full of one-letter variables?

Cool when paper and ink is expensive and you're trying to send your proof to the other mathematician, in a letter in the mail, in the 16th century, but now? Why?!