
Ask HN: Good Taxonomy Naming Conventions? - Kagerjay
How do you go about naming things? I struggle with this. Especially when it comes to frontend design. I use mostly BEM style naming, but I find things to be too verbose sometimes, slowing down productivity and readability. Often times the first tool I grab off my shelf is a thesaurus.<p>Do you struggle with naming things, or have methods for handling this? I find what is most helpful is to use an analogy with a well defined hierarchial taxonomy. For instance:<p>- A stick figure has a head, a body, feet, arms - much like the DOM has a header, body, footer, and asides. Arms have fingers, feet has toes, much like there are footer links and aside widgets.<p>These examples could be either found in nature or just well established in society. What I am looking for is taxonomy hierarchial examples that could be used in any application, that aren&#x27;t namespaced already. Examples for class inheritance is (animal → dog).<p>------------------------------------------------------------------<p>Other applications relative to naming:<p>- CSS classes, and their hierarchial relationships<p>- Designing a CSS framework &amp; its naming conventions<p>- Functions, variables, classes, etc for frontend or backend<p>- Defining different UX webcomponent names and their hierarchial relationships<p>- Defining keyword definitions document for larger projects, both from the users &amp; developers standpoint<p>- Designing endpoint documentation for REST API&#x27;s<p>- Writing technical documentation with actual relateable examples (without using the word <i>foo</i> or <i>bar</i>)<p>------------------------------------------------------------------<p>What are examples you use?<p>Do you use these principles in your codebase?
======
x0hm
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
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

