Ask HN: Good Taxonomy Naming Conventions? | Hacker News Reader

Ask HN: Good Taxonomy Naming Conventions?

1 pointswaggyBoatswain2 comments

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.

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:

- 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.

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't namespaced already. Examples for class inheritance is (animal → dog).

------------------------------------------------------------------

Other applications relative to naming:

- CSS classes, and their hierarchial relationships

- Designing a CSS framework & its naming conventions

- Functions, variables, classes, etc for frontend or backend

- Defining different UX webcomponent names and their hierarchial relationships

- Defining keyword definitions document for larger projects, both from the users & developers standpoint

- Designing endpoint documentation for REST API's

- Writing technical documentation with actual relateable examples (without using the word foo or bar)

------------------------------------------------------------------

What are examples you use?

Do you use these principles in your codebase?

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.

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

Reply on news.ycombinator.com