3 ms·
The difficult in naming things is that you're trying to encode semantics and an interface contract in a name. If you give up doing that, it's easy. For example
by AlienRobot 2y ago
The difficult in naming things is that you're trying to encode semantics and an interface contract in a name. If you give up doing that, it's easy.
For example, say you have getFoo(). It's clear it gets the foo. But later you introduce getFooAsync(). Suddenly it's no longer clear whether getFoo() is sync or async, because you didn't call it getFooSync().
If instead you used names like getFoo1, getFoo2, getFoo3, etc., the semantics you're providing is that there are multiple "ways" to getFoo without making promises (a contract) about what the function actually does in its name.
Although this sounds like bad naming practices (it is), it effectively solves the naming problem. Apply this to CSS, and instead of .red-button or .secondary-button, you get .button1, .button2, .button3, and you just don't have to think about WHY are you creating a button to give it a class and start styling it.
- card_zero 2y agoYep, that sort of thing happens constantly. Things get misleading names because the first three alternatives I came up with were also misleading. So I agree, and indeed I considered a foo bar baz scheme instead of icons, same difference. Then you have to look somewhere else for what the thing does. Self-documenting code doesn't really work, and strict naming schemes are long-winded and worse than ad-libbing it, so it would have to be comments, but then the comments get forgotten and no longer reflect the code. I give up, might take up woodwork instead.