tl;dr;
There is no one true answer. You can pick one of the many out there, or create your own standards based on what makes sense, depending upon who you're working with. And it is 100% dependent upon the platform.
Original Post
Just one more alternative standard to consider:
<div id="id_name" class="class-name"></div>
And in your script:
var variableName = $("#id_name .class-name");
This just uses a camelCase, under_score, and hyphen-ation respectively for variables, ids, and classes. I've read about this standard on a couple of different websites. Although a little redundant in css/jquery selectors, redundancies make it easier to catch errors. eg: If you see .unknown_name
or #unknownName
in your CSS file, you know you need to figure out what that's actually referring to.
UPDATE 2019
(Hyphens are called 'kebab-case', underscores are called 'snake_case', and then you have 'Title Case', 'PascalCase', and 'camelCase')
I personally dislike hyphens. I originally posted this as one alternative (because the rules are simple). However, Hyphens make selection shortcuts very difficult (double click, ctrl/option + left/right, and ctrl/cmd+D in vsCode. Also, class names and file names are the only place where hyphens work, because they're almost always in quotes or in css, etc. But the shortcut thing still applies.
In addition to variables, class names, and ids, you also want to look at file name conventions. And Git Branches.
My office's coding group actually had a meeting a month or two ago to discuss how we were going to name things. For git branches, we couldn't decide between 321-the_issue_description or 321_the-issue-description. (I wanted 321_theIssueDescription, but my coworkers didn't like that.)
An Example, to demonstrate working with other peoples' standards...
Vue.js does have a standard. Actually they have two alternate standards for several of their items. I dislike both of their versions for filenames. They recommend either "/path/kebab-case.vue"
or "/path/PascalCase.Vue"
. The former is harder to rename, unless you're specifically trying to rename part of it. The latter is not good for cross-platform compatibility. I would prefer "/path/snake_case.vue"
. However, when working with other people or existing projects, it's important to follow whatever standard was already laid out. Therefore I go with kebab-case for filenames in Vue, even though I'll totally complain about it. Because not following that means changing a lot of files that vue-cli sets up.
UPDATE 2021
At this point in my life, I try to exclusively use kebab-case
for project file names.
And a weird combination of snake_case.kebab-case.dot.case.Title.Case
for files which are for human communications. Like an excel file that contains a report might be "Report_Name-Report_Type-2021.05.04_13.02"
for a report generated on May Fourth at 1:02 PM. I was actually going to use Title Case
in said report name, but if you resave the file, you'll get no spaces. And I was going to use kebab-case and make the datestamp iso-compliant, but the client got confused because they use American month-day-year format for dates. Another example is "SomeRequestForm-ProjectName-01.pdf"
.
Client-Readable stuff is hard to work around.
I avoid spaces where possible (and the client doesn't ask for them), because they're not cli-safe. I've taken up the Angular approach to filenames in projects. some-thing.type.ts
, where the description is kebab-case
, and the standard type of object stored in the file is separated with dots like the extension. I don't typically do some-area_some-thing.type.ts
, unless the file is standalone and portable. If it's in a project, then I just use folders like some-area/some-thing.type.ts
Additionally, I use kebab-case
for css classes and I sometimes mix snakeAndCamel_case
for html ids, but typically I no longer use html ids, because I work with reusable components, and that breaks. When I do use ids, it's typically something like someComponent-someElement_49bea6c9-551b-400a-a3e0-59ed40967646
where that uuid is a generated uuid self-assigned by each component instance. This is not supported in Angular, so I tend to come up with other workarounds, such as keeping the entire form input inside the label.
Additionally, for variable names, I still use mostly camelCase, except for class names and sometimes function names. When working with an external package, I just do what they're doing. For things that mimic environment variables, I do use ALL_CAPS_SNAKE_CASE
, this includes node.js process.env.SOME_ENV_VAR
and combinedConfiguration.SOME_ENV_VAR
(for when I'm overriding process.env with a parameter config)
My tl;dr; still applies a few years later. There is no one true answer. But try to keep one style per project. And lower the number of words in your symbols wherever possible.