3 ms·

I sometimes wonder if naming things would have the perceived difficulty it does in our field if that quote never existed. Naming variables/functions/classes is

I sometimes wonder if naming things would have the perceived difficulty it does in our field if that quote never existed. Naming variables/functions/classes is not hard - just say what it does. Sure, naming a library may seem difficult if your plan is to be clever, but I don’t think it really matters that much. Are [PyTorch, mallet, angular, dplyr, scikit-learn, cucumber, react] good names? Why? Could someone just as easily give a list detailing why they’re poor names? Probably.

thatswrong0 6y ago
> just say what it does But it isn't always easy to describe both clearly and succinctly what exactly a function (/ etc.) is doing. And a particular issue I have is one of audience: to whom is this name addressed? Should it be at least somewhat obvious to a newcomer to the codebase to understand what the function is doing? Or can I assume that the reader / maintainer is already knowledgeable of the context in which this function exists? In my (limited) experience, this becomes exacerbated when I'm trying to name some abstract operation in a context that doesn't already have a well defined lexicon. So then I, unfortunately, must be the person to create this dictionary of terms that I will be referring to repeatedly throughout the problem space. On top of this, I generally don't even know how I'm going to solve the problem when I first start implementing, so my first round of names might be strikingly obtuse to an outside observer. But if the implementation becomes sufficiently complex, and I don't take the time to refactor or receive input early on, these names become intuitive to me via repetition, so then I end up building on top of them and create this pyramid of gibberish that at some point made sense to me but that someone will unfortunately have to take the time to grok at some point in the future. This doesn't happen so often that I would say it's the second hardest problem in our field, but it definitely is something that can contribute significantly to tech debt. ¯\_(ツ)_/¯

thatswrong0 6y ago

> just say what it does But it isn't always easy to describe both clearly and succinctly what exactly a function (/ etc.) is doing. And a particular issue I have is one of audience: to whom is this name addressed? Should it be at least somewhat obvious to a newcomer to the codebase to understand what the function is doing? Or can I assume that the reader / maintainer is already knowledgeable of the context in which this function exists? In my (limited) experience, this becomes exacerbated when I'm trying to name some abstract operation in a context that doesn't already have a well defined lexicon. So then I, unfortunately, must be the person to create this dictionary of terms that I will be referring to repeatedly throughout the problem space. On top of this, I generally don't even know how I'm going to solve the problem when I first start implementing, so my first round of names might be strikingly obtuse to an outside observer. But if the implementation becomes sufficiently complex, and I don't take the time to refactor or receive input early on, these names become intuitive to me via repetition, so then I end up building on top of them and create this pyramid of gibberish that at some point made sense to me but that someone will unfortunately have to take the time to grok at some point in the future. This doesn't happen so often that I would say it's the second hardest problem in our field, but it definitely is something that can contribute significantly to tech debt. ¯\_(ツ)_/¯