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.
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...
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.
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.
> 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.
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.
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.
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?
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.
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.
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.
> 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.
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 ;)
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.
>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.
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.
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.
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.
> 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.
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.
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.