May all your rules and “wisdom” choke you

While reading a technical discussion forum I was, not for the first time, stuck by some of the comments made by an otherwise cogent developer defending his development language choices. His argument started off well but quickly degenerated to the level of “professional application developers prefer not to…”.

When you resort to phrases like “serious programmers do/don’t”,“professional developers…” and “real programmers should…” you’ve already lost the argument because what you’re really saying, and what everyone else hears, is “why aren’t you more like me?”.

That isn’t going to convince anyone.

What’s your skateboard?

mvp

Minimal Viable Product is a cornerstone of Agile software development but very often (wilfully) misunderstood or misinterpreted. In a lengthy, but very readable, blog post, Henrik Kniberg of Swedish consultants Crisp gives the clearest example I have read yet of what MVP means in practice and why he thinks we should also add three more steps before MVP – Earliest Testable, Earliest Usable and Earliest Lovable Product versions.

 

More:

 

Brackets keyboard shortcuts now available in Dash

Dash, the documentation browser and code snippet manager for OSX, now includes a cheatsheet for Brackets editor, version 1.3

 
Dash is an excellent offline documentation browser and code snippet manager for OSX and iOS (though there are also “officially sanctioned” 3rd-party versions for Windows and other platforms).

Yesterday I submitted a pull request to the cheatsheets repo on GitHub that adds a cheatsheet for Brackets 1.3 keyboard shortcuts to Dash. Earlier today my change was accepted by Kapeli (a.k.a. Bogdan Popescu) and the cheatsheet is now available for download from within Dash.

To install it, first open the Dash Preferences then:

Select Downloads
Step 1
Choose Cheat Sheets
Step 2
Locate Brackets and click Download
Step 3
The Brackets cheatsheet as it appears in Dash
The Brackets cheatsheet as it appears in Dash


This version of the cheatsheet covers keyboard shortcuts for Brackets for Mac, version 1.3.



More:

The work #5

We are all many things. We all do many things. We will do many more things throughout our lives. Yet, when we are gone, most will primarily remember only one of them. They will pick from the lot and remember you as that. What they pick will, in their mind at least, be all that you are. Therefore, it is our job to ask ourselves with all the things we allow ourselves to do, with each and every one, “Is this something I want to be remembered for?”

— Patrick Rhone, “What Will You Be Remembered For?”



More:

Use concept naming to simplify and clarify your Javascript conditions

Concept naming comes naturally to most people but is still rarely seen in Javascript despite the benefits. In this post I’ll illustrate how a simple technique can make your Javascript code significantly more readable.

 
The benefits of writing simple, clear and human-readable Javascript code are well known if not always well practiced.  The other day, while skimming the source of some of the rules bundled with ESLint, I was pleasantly surprised to see many of them made use of “concept naming” for conditions. This is a practice common in many other programming languages but not something I see being used in Javascript very often, despite the benefits.

Let me illustrate the technique with a simple code snippet:


if (charsToMatch[line.charAt(cursorPos.ch)]) {
    // do something
} else {
    // do something else
}

The condition on line 1 is trivial but even something this simple can make us stop and pause as we try to work out what the test is doing, and why. If you’re new to the code or just haven’t worked on it for a while a lot of valuable time can be wasted trying to get an overview of the application flow. Each time we hit a condition we have to pause and ask “what are we trying to achieve here?”.

We could, of course, add a comment immediately before the condition but comments can quickly become out-of-date, incomplete or just plain wrong. For that reason there has been a general trend over the last few years to minimize or reduce the number of comments in source code, or even to abandon them altogether.

When it comes to conditions, there is a simple and reliable way of making your code more understandable – give a name to the concept that is expressed in the condition. In our simple example the intent of the condition might be to determine if the character at the cursor position is one that we don’t want to allow a user to enter. This is determined by checking if it appears in an array – charsToMatch.
We can rewrite our snippet to illustrate this concept:

var charAtCursorIsNotAllowedInInput 
       = charsToMatch[line.charAt(cursorPos.ch)];

if (charAtCursorIsNotAllowedInInput) { 
    // do something 
} else { 
    // do something else 
}

If I were to glance at the snippet above for the first time, I still wouldn’t necessarily know the specifics of the conditional test but I would immediately be able to glean the intent of the condition. It now more closely reflects how we think – in concepts rather than conditional statements – and is much more readable.

Of course, as conditions increase in complexity the benefits will become more apparent:

var charAtCursorIsNotAllowedInInput 
       = (charsToMatch[line.charAt(cursorPos.ch)])
         || (cursorPos.ch >= 0 
         && charsToMatch[line.charAt(cursorPos.ch - 1)]);

if (charAtCursorIsNotAllowedInInput) { 
    // do something 
} else { 
    // do something else 
}

In this snippet the test is more complex but the concept is unchanged and what is trying to be achieved is instantly understandable.

Am I suggesting you should always name your conditions? No. There is, of course, a slight overhead in the “noise” introduced by the extra variable (which I consider a small price worth paying) but, just as you wouldn’t find it necessary to comment every condition, you wouldn’t necessarily want to assign a name to every one either. As always, common sense and consideration for those that will come after you goes a long way.

I hope you can see from these simple examples that, like the judicious use of clearly named variables, applying concept naming to your conditions can make your Javascript code significantly more readable and easier to maintain.