I love when I return to some project after few years, realize I need some new feature, write the function name only to find out that the exactly the same function already exists and does what I want. When I choose the same name after so long it means there is some serious consistency in my naming conventions. Feels good.
I have one frontend naming habit that might be worth sharing. The root element of my react components always have a className that matches the component name exactly (ie capitalized). All other classNames are uncapitalized. Makes navigation pretty easy in browser dev tools.
> If you’re the first person on the project, use camelCase; it’s easier to select camelCased text in an IDE than it is hyphenated text<p>Doesn't this go against the conventions of the most popular CSS libraries that your code will likely be used with? It's a pain and ugly that JavaScript and CSS don't use the same conventions though.<p>The IDE select issue is probably fixable e.g.
<a href="https://stackoverflow.com/questions/45590695/visual-studio-select-word-with-hyphen" rel="nofollow">https://stackoverflow.com/questions/45590695/visual-studio-s...</a>
> Does a Test need it?<p>> Use .qa<p>Generally, I'd recommend trying to query elements in a test using accessible selectors, if possible. For example, look for the input[type=email] or button[aria-label~="Submit"]. That helps prevent people from forgetting to update or accidentally removing these often invisible properties.<p>I'd especially recommend testing-library for this purpose, which allows you to easily query by e.g. role and the accessible name of an element: <a href="https://testing-library.com/" rel="nofollow">https://testing-library.com/</a>
The general ideas are fine, but the examples are pretty outdated. For modern SPA, CSS naming has become largely obsolete. A lot of the JS code shows the principles it is supposed to well but sadly includes other cruft.<p>Here's a guide I would recommend instead: <a href="https://github.com/labs42io/clean-code-typescript" rel="nofollow">https://github.com/labs42io/clean-code-typescript</a>
Mostly good but I hate getProperty names. If a method returns the temperature call it temperature() not getTemperature(). If the private data member has to have a different name, _temperature or some similar convention will do.
For js and qa needs I’d recommend custom html data attributes instead of using classes (data-js=, data-qa=). It’s a much clearer separation of concerns.