14 ms·

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 corre

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.

wolco2 6y ago
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 6y ago
  >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.
  - spion 6y ago
    They are in fact bleeding. Clear writing is about structure, not verbosity or repetition. Concise-and-clear is preferred over verbose-and-clear.
    - Geminidog 6y ago
      >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.
      - amatecha 6y ago
        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 :)
mercora 6y ago
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 6y ago
  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.
IncRnd 6y ago
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 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - BlargMcLarg 6y ago
    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.
    - deleted 6y ago
      [deleted]
    - 6y ago
akavel 6y ago
For the same reason some non-programmers seem to also value conciseness: https://quoteinvestigator.com/2012/04/28/shorter-letter/ 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 6y ago
  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 6y ago
    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)?
MrPatan 6y ago
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 6y ago
  Wait, you can use more than 1 character for generic types?! My whole life is a lie!
bjohnson225 6y ago
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 6y ago
  > 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.
tomxor 6y ago
> 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.
- Geminidog 6y ago
  Clearly for algebra you want to use algebraic notation because the conventions of algebraic grammar are suited for those tokens. You're right context does matter. I'm more referring to naming as a means of communication. If your function is not intended for use as an algebraic operator and it does some complex operations like extracting the x y coordinates of the locations of dogs cats and baboons from a picture it doesn't hurt to place that entire description into the function name. It doesn't hurt to make the function name grammatically correct either as it certainly doesn't hurt when you try to communicate the same point in English. >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. I agree with balance. What I'm arguing here is that our general intuitive sense of what is "balanced" is actually off. People think "find_xy_coordinate_of_dogs_cats_and_baboons_in_picture" is an ugly function name and needs to be shortened but there is actually nothing logically wrong with it.
GuB-42 6y ago
> 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 6y ago
  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.
rShergold 6y ago
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.

wolco2 6y ago

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 6y ago
>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.
- spion 6y ago
  They are in fact bleeding. Clear writing is about structure, not verbosity or repetition. Concise-and-clear is preferred over verbose-and-clear.
  - Geminidog 6y ago
    >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.
    - amatecha 6y ago
      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 :)

mercora 6y ago

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 6y ago
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.

IncRnd 6y ago

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 6y ago
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.
- deleted 6y ago
  [deleted]
- BlargMcLarg 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - 6y ago

akavel 6y ago

For the same reason some non-programmers seem to also value conciseness: https://quoteinvestigator.com/2012/04/28/shorter-letter/ 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 6y ago
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 6y ago
  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)?

MrPatan 6y ago

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 6y ago
Wait, you can use more than 1 character for generic types?! My whole life is a lie!

bjohnson225 6y ago

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 6y ago
> 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.

tomxor 6y ago

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

Geminidog 6y ago
Clearly for algebra you want to use algebraic notation because the conventions of algebraic grammar are suited for those tokens. You're right context does matter. I'm more referring to naming as a means of communication. If your function is not intended for use as an algebraic operator and it does some complex operations like extracting the x y coordinates of the locations of dogs cats and baboons from a picture it doesn't hurt to place that entire description into the function name. It doesn't hurt to make the function name grammatically correct either as it certainly doesn't hurt when you try to communicate the same point in English. >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. I agree with balance. What I'm arguing here is that our general intuitive sense of what is "balanced" is actually off. People think "find_xy_coordinate_of_dogs_cats_and_baboons_in_picture" is an ugly function name and needs to be shortened but there is actually nothing logically wrong with it.

GuB-42 6y ago

> 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 6y ago
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.

rShergold 6y ago

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.