4 ms·

We shouldn't try to shoehorn our design into a taxonomy. Name things based on their intent in a given context. If you're having trouble with names, you're ver

by x0hm 8y ago

We shouldn't try to shoehorn our design into a taxonomy. Name things based on their intent in a given context. If you're having trouble with names, you're very likely in one of 2 camps - 1) You're trying to shoehorn your objects into a specific naming convention. 2) You don't have a clear idea what the intent of your object is. In any case, the best solution is to simplify - as simple as possible for its given context, and no simpler. Trying to force a hierarchy or taxonomy of names across a given project is just going to confuse things. Your names won't be organic representations of your objects, and you'll have trouble down the line. If a thing is a type of another thing, those naming conventions are fine, but don't force it. Give things fitting names, don't fit them into names.

Kagerjay 8y ago
I guess taxonomy might have been the wrong word. For things like functions and variables, writing a name isn't terribly difficult, since you can use an object's intent. There's only a few ways to interpret this if you were following SOLID principles (specifically, singularity). For things like CSS class... and organizing enough that it becomes a mini framework - this has been challenging for me. CSS classes just tend to be so much more vague on what its intent is. I mean its styling a component, but that component could be called so many different things. Another issue is when I pull in a CSS framework like bootstrap. I only use 5 different components. I'll write 90% of my own custom CSS from scratch. But I still try to avoid using bootstrap's namespaced classes. I don't like intruding on these reserved namespaces. I have mixed feelings because there's only so many good ways of naming something. I'll pull up a thesaurus to see if there are good alternative semantic names. Sometimes, there isn't any. I hope this makes sense. My project has already been split to 20 sass files in 7 different directories. I've refactored it as many times as I could. But I'm starting to 2nd guess my naming conventions and realize how sloppy my code still is. Because I didn't define a button with 3 classes (one for sizing, one for color, one for general UI) but rather one at that time. I like a sense of rigidity in projects. Naming things is extremely important for me to get right the first time. Its like naming model#'s for a company that sells many goods. You can name it whatever you want, but, grouping together items and using special naming rules (prefixes, suffixes, etc) pays off in the long run. So you can identify a class, and immediately know what it is, without look at its actual code

by x0hm 8y ago

Kagerjay 8y ago

I guess taxonomy might have been the wrong word. For things like functions and variables, writing a name isn't terribly difficult, since you can use an object's intent. There's only a few ways to interpret this if you were following SOLID principles (specifically, singularity). For things like CSS class... and organizing enough that it becomes a mini framework - this has been challenging for me. CSS classes just tend to be so much more vague on what its intent is. I mean its styling a component, but that component could be called so many different things. Another issue is when I pull in a CSS framework like bootstrap. I only use 5 different components. I'll write 90% of my own custom CSS from scratch. But I still try to avoid using bootstrap's namespaced classes. I don't like intruding on these reserved namespaces. I have mixed feelings because there's only so many good ways of naming something. I'll pull up a thesaurus to see if there are good alternative semantic names. Sometimes, there isn't any. I hope this makes sense. My project has already been split to 20 sass files in 7 different directories. I've refactored it as many times as I could. But I'm starting to 2nd guess my naming conventions and realize how sloppy my code still is. Because I didn't define a button with 3 classes (one for sizing, one for color, one for general UI) but rather one at that time. I like a sense of rigidity in projects. Naming things is extremely important for me to get right the first time. Its like naming model#'s for a company that sells many goods. You can name it whatever you want, but, grouping together items and using special naming rules (prefixes, suffixes, etc) pays off in the long run. So you can identify a class, and immediately know what it is, without look at its actual code