“It turns out that style matters in programming for the same reason that it matters in writing. It makes for better reading.”

wrote Douglas Crockford, in Javascript: the Good Parts.

Doug wrote this over 10 years ago, perhaps when the IDE autocomplete and semantic completion wasn’t as robust. And definitely before TabNine (which smart writes code snippets for you).

Yet, even with our modern IDEs and decades of best practice, it seems we (newer) devs take to the 'shorter is a better' approach by claiming efficiency; this laziness comes at a cost to understanding your own code 2 weeks from now and someone else's code from two years ago.

So with some thanks to Doug for his tips and looking through public JS and Ruby repos, use these clear and concise coding styles practices do's and do-nots.

Single Line Statements

Use () and {} to spread your code over multiple lines.

Compact single line code is not the gold standard, readability and understanding are.

Specific (and Long Variable) Names

Don’t: let setWord = ""

Do: let UserAccountName = “ “
This is a real before and after renaming of the same variable example. Which one is clearer?

Don’t use the same name for multiple things.

On a React project, we initially wrote a Service component, a service state, and a service function. Yet each service had a unique task and we weren’t explicitly acknowledging this task.

A bit of refactoring cleared up our intent: keep Service for the model, rename the service state to serviceShowState, and the service function to showHideServiceCards().

With our powerful IDE’s, we can and should write long names. Otherwise, we don’t use the power and magic of the IDE!

Use adjectives AND verbs to give a sense of what variables hold - don’t use just nouns.

Specific (and Long) Function Names

Functions make things happen. Make it clear exactly what it does.

Don’t: updateState()
Do: updateStateForServices() assigned to an onClick callback showHideServiceCards.

Long names make you think about what your code is doing. Vague names could be said to be vague thinking.

Use adjectives AND verbs to give a sense of what functions do or return - don’t use nouns.

Explain Your Code - Use Comments

Earn that dev karama++.

In time you will move to a new project (or a new company) and experience the joys of using well-documented code. But only if you use clear, plain English on the code you left behind. Otherwise, dev karma-- for you

Group Functions and Files Together

Put your fetch requests in an API/Fetch file and/or folder.

Group event listeners, event handlers, and function calls with their brethren.

A skim of the code should let you and others know where things are.

Ruby loves convention over configuration. Apply such thinking to your own JS code.

Final thought, with a hat tip to @afteralec, *write code with the intention of others understanding your code. **

Have thoughts on writing style? Drop note. I'd love to hear and see your examples (or counterpoints).