10 ms·

As a chronic over-generalizer, you have no idea how much time I've wasted trying to think of the right name for meta-monstrosities.

kylegill 6y ago
My friend told me at their company they'd commonly convene the "variable naming committee" for such occasions, and I can't help but think of it every time I find myself in the same place.
- rob74 6y ago
  A variable naming committee might seem exaggerated, but I've seen far too many variable/method/class names already that are wrong, misleading or at best misspelled, so some more thoughtfulness is definitely warranted...
  - BlargMcLarg 6y ago
    Unfortunately, a lot of people who believe to be "thoughtful" have caused a lot of 20+ character names, which still need other names compounded on top, when they could have used 10 character names that explain things just fine. The developers I met generally weren't that great at narrating themselves, regardless of seniority. Narrative skills are woefully undervalued, and they aren't solved by a set of hard, scientific rules just yet. I pray I'm a unique example in experiencing this, but I doubt it.
    - deleted 6y ago
      [deleted]
    - Geminidog 6y ago
      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.
  - gregmac 6y ago
    Some of the highest value-to-effort feedback I've both given and received in a PR is about naming. Whenever I see something where my first impulse is to react with "WTF?!?" I now try to ask myself "does something here just have a bad name?" and much of the time that's all it is.
    - hanniabu 6y ago
      I was working on a financial trading program at one point, specifically a function to filter orders into bids and asks. They named the order value "total" and the order size "sum". It made a really simple function incredibly difficult to read.
- throwaway201103 6y ago
  I've worked at a place where variables (and in particular, database table and column names), had to be approved by the naming committee.
  - sverhagen 6y ago
    Hey! We've worked in the same place then! Joking aside. I agree that it doesn't seem like the kind of thing you want to convene a committee for. But it happens where the database is the contract shared by a bunch of applications, in which case it's important to get it right, maybe important enough to spend a meeting on. It's not my architectural style of choice... but it happens.
- rualca 6y ago
  > My friend told me at their company they'd commonly convene the "variable naming committee" for such occasions, and I can't help but think of it every time I find myself in the same place. You better call it the bike shedding committee. I don't see how that saves time over, say, just let anyone working on that code who really dislikes to propose their change in a next merge request.
throw1234651234 6y ago
Agreed. My problem isn't even naming, but overly long names, which become a problem in C# and Java, where you have the namespace, the method, a service inside the method, a long type (because "var" can be an issue), and so on.

kylegill 6y ago

My friend told me at their company they'd commonly convene the "variable naming committee" for such occasions, and I can't help but think of it every time I find myself in the same place.

rob74 6y ago
A variable naming committee might seem exaggerated, but I've seen far too many variable/method/class names already that are wrong, misleading or at best misspelled, so some more thoughtfulness is definitely warranted...
- BlargMcLarg 6y ago
  Unfortunately, a lot of people who believe to be "thoughtful" have caused a lot of 20+ character names, which still need other names compounded on top, when they could have used 10 character names that explain things just fine. The developers I met generally weren't that great at narrating themselves, regardless of seniority. Narrative skills are woefully undervalued, and they aren't solved by a set of hard, scientific rules just yet. I pray I'm a unique example in experiencing this, but I doubt it.
  - deleted 6y ago
    [deleted]
  - Geminidog 6y ago
    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.
- gregmac 6y ago
  Some of the highest value-to-effort feedback I've both given and received in a PR is about naming. Whenever I see something where my first impulse is to react with "WTF?!?" I now try to ask myself "does something here just have a bad name?" and much of the time that's all it is.
  - hanniabu 6y ago
    I was working on a financial trading program at one point, specifically a function to filter orders into bids and asks. They named the order value "total" and the order size "sum". It made a really simple function incredibly difficult to read.
throwaway201103 6y ago
I've worked at a place where variables (and in particular, database table and column names), had to be approved by the naming committee.
- sverhagen 6y ago
  Hey! We've worked in the same place then! Joking aside. I agree that it doesn't seem like the kind of thing you want to convene a committee for. But it happens where the database is the contract shared by a bunch of applications, in which case it's important to get it right, maybe important enough to spend a meeting on. It's not my architectural style of choice... but it happens.
rualca 6y ago
> My friend told me at their company they'd commonly convene the "variable naming committee" for such occasions, and I can't help but think of it every time I find myself in the same place. You better call it the bike shedding committee. I don't see how that saves time over, say, just let anyone working on that code who really dislikes to propose their change in a next merge request.

throw1234651234 6y ago

Agreed. My problem isn't even naming, but overly long names, which become a problem in C# and Java, where you have the namespace, the method, a service inside the method, a long type (because "var" can be an issue), and so on.