For me there was a time that can only be described as adolescence in the field of programming and more specifically JavaScript. This period was characterised by a certain laziness and hubris. I thought I was right. I thought others were wrong. I could see no path but the very strict one that I had boxed myself into through a process in which I longed for certainty and the expulsion of realistic doubt.

Today I present a short list of JavaScript practices that once seemed right but I now deem foolish (in most situations):

Using logical operators as statements

a() ||; m && c() ? d() : l ||[bee](3);

There is no real advantage in forgoing convention for the sake of cleverness.

Always declaring variables at the top of their scope

function calculate() {
  var a, m, t, y, This, is, really, understandable = false;
  // Actual logic goes here

Instead I declare a variable where it makes sense. Much of the time this is at the top of the scope, but there are enough exceptions to make me shake my head in dissapproval at the thought of a style guide imposing religious top-of-scope declarations.

Repeatedly used inline object literals

function prepareRequest(mode, updateId, value) {
  var req = {
    mode: mode,
    updateId: updateId,
    value: value,
    uid: genUID()
  // etc.

It’s better for clarity and performance (potentially) to define separate classes for cases where you repeatedly make object literals of the same structure. For example the above could be refactored into a Request class.

Complex inline regular expressions

if (/r[ -~]?(?:m\d+|\d+[0-3]{2,})_m?$/.test(thing)) {
  // ... wat

It makes sense to cache these things. Plus naming it means someone might have a chance of understanding WTF the code does.

Using single letter variable names

They make no sense unless used in the various idiomatic loops.

Strict equality everywhere

if (typeof x === 'string' && x === 'mode:45') {
  // ... 

Sometimes it’s overkill. Regular equality can be used in both of the above cases.

Assuming truthiness equals presence

if (!cachedReturnValues[key]) {
  cachedReturnValues[key] = value;

It’s potentially dangerous. E.g. It’s better to use the ‘in’ operator to discover presence, or even ‘hasOwnProperty’.

Commenting nothing or commenting every little thing

// This is a loop
for (var i = 0; i < arr.length; i++) {
  // This is me adding one to the item in the array at the index
  // specified by the variable `i` declared slightly above this comment:
  arr[i] += 1;
} // this is the end of the loop

Commenting everything demonstrates either a lacking clarity in your code or a lacking clarity in your mind as to the intention of comments. Commenting nothing shows hubris and laziness.

Thinking I can write something reliable without unit tests

Unit tests give me the confidence to be sure that my code does what I intend it to do.

Using long names and being overly specific

A long name suggests bad API design. Re-think where you’re defining the variable/method. Think of a circumstance in which the variable name could be shorter — a context that makes sense for that variable. Then create that context. You’ll probably end up with a cleaner internal API. E.g.

// Version 1:
var responseCache = {};
function generateNextIDForANewResponseCacheItem() {...}
function deleteResponseCacheItemsThatDoNotEqual(value) {...}
// Version 2:
function ResponseCache() { = {};
ResponseCache.prototype = {
  genNextID: function() {...},
  remove: function(optionalFnCheck) {...}

Strict coherence to a standard

This never works and never solves what you think it will. It’s better to dynamically sway and constantly rethink your idea of what is right and wrong given each situation as it arises. This is why I try to steer clear of over-zealous coding style dogma, or all dogma for that matter.