201–210 of 339 posts
I don’t think you need to go full startup when naming stuff, but you also don’t have to go full bureaucrat either. I once created a PHP framework called RocketSled because it was “the fastest thing on rails” and that gave rise to somewhat whimsical but also descriptive names on the same theme: RocketPack: package manager DataBank: caching auto loader Murphy: automated testing Each of those modules is named quite spec…
Where does Murphy come from?
Also, unique. Or at least unique-ish. Whoever named the ML thing "transformer" deserves a special place in hell. So many intriguing headlines, so few things worth reading. (I'm an EE, so I'm very interested in the other transformers. For some reason, the headlines for these things scan like they could apply to either. Alas, they don't.)
The EE transformer is just as descriptive than the ML transformer. Your complaint is similar to cryptography conference attendants hating the word ,,crypto'' to change from cryptography to cryptocurrency, but that's just the natural evolution of language with technology (not mentioning that the original meaning of the Greek word is hidden/secret).
Earlier quoted context omitted.
But as products evolve, their boring names become misleading. At least with non-boring names you can re-define what they represent in your company.
Isn't it even harder to re-define names in a company? There might be 3 people involved in re-definition, but it affects 15 people. How are we going to notify those 15? Do we even know who those 15 are? Are we going to create a weekly redefinition newsletter? I think in most cases new meaning deserves a new name. Everything else is just hacks. How hard is it to change a name is a actually a really good metric for a co…
I would argue it's easier to maintain peoples understanding of a product since that will also be done gradually. It's not easy to update naming inside of a code base without potentially breaking software significantly or causing unknown bugs elsewhere. I think most software would fail the renaming test. It's also generally not worth the money and time needed to make that change.
The author seems to be talking about names for two totally different things, lumping them under the term "component." Whimsical project name? No problem. Whimsical type name within a project? Really bad idea. Whimsical variable name? Don't even think about it. The concept the author is missing is "convention." Whimsical project names fall within a well-understood and used convention. The convention for type and varia…
> Whimsical project names fall within a well-understood and used convention. Boy, I wish! I 100% second TFA when I tell you: There are a lot of really really boring people out there that just don't get it. They think "Product Data Exporter" is the perfect project name.
Earlier quoted context omitted.
I have nothing against undescriptive product names. But if you are constantly changing the entire problem your software is intended to solve, you have a problem. And if you just happen to change it eventually, it's best for everybody if you go and make it a different project with a different name. Descriptive or not.
Commercial software is mostly to solve real world problems. Real world problems can change very quickly and as such, software changes too. Sure constantly changing in the complete opposite direction is probably a sign of something wrong, but changes are inevitable and we can’t expect to reinvent the wheel or start a new project as you say when you can potentially reuse what you already have.
So you keep the old product, and make a new one for solving the new problem. (You can even sell them on the same package.)
The alternative will have almost all of your customers badmouthing you because they brought your product, and you pulled the functionality out of their feet.
1. Names must be descriptive.
2. Names must be unambiguous.
3. Names should be no longer than they need to be to achieve #1 and #2.
If your names are becoming less descriptive over time it's because you're not writing well. It's not easy to write well, but that's the job.
This is something I am very grateful for when I return to a project after some time away and the code is documenting itself.
But I'm also a fan of disposable code. If I'm actively working on something I probably rewrite more or less the whole project every 18 months bit by bit.
Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…
I came here to write something similar. The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming. For a long long time I’ve convinced people to use literal names for things and not get creative. A BillingStatusService , as the author has cited, isn’t an example of a bad name. It’s an example of bad engineering that it does more than BillingStatus . Often times when peo…
I'd assume everyone here could at least agree that naming is hard. I don't think the article was attempting to explain how to name, but instead point out one potential pitfall when naming.
I work on the same, but never learnt to use non-descriptive names.