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:

 

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.

Starting Brackets from the Mac terminal command line

With the imminent release of Brackets 1.3 we now have the much-needed ability to easily start the editor from the terminal.

 
Setup of the command line shortcut takes just a couple of minutes:


1. Install Brackets 1.3

The latest version should be released for automatic update in a few days but if you can’t wait you can download the pre-release version right now from the Brackets GitHub repository.


2. Install the Command Line Shortcut

Start up Brackets then select the File… Install Command Line Shortcut menu item which now appears at the very bottom of the File menu.

Install the Command Line Shortcut

You’ll be asked to confirm your password, then the shortcut will be installed.

If everything went smoothly you’ll see a confirmation message and Brackets will be ready to use from within terminal:

Brackets Command Line tool installed

Notice that you can open a single file or switch projects.


3. Start Brackets from within terminal

brackets_zsh

As is common with other GUI apps started from the terminal there is one peculiarity:

  • If Brackets is closed, it will be started, the file (or project) to be edited will be loaded and the app brought to the front
  • If Brackets is open but not on top (or in another space), the file (or project) to be edited will be loaded and the app brought to the front
  • If Brackets is minimised, the file (or project) to be edited will be loaded but the app will not be brought to the front. This can be confusing if you haven’t seen this behaviour before because it appears that nothing at all has happened.

More info about Brackets 1.3 can be found in the release notes on GitHub.
Command line startup can also be set up on Windows; brief details are in the release notes.

The four Brackets extensions I use most often

 
When it comes to writing code I have no interest in using a bloated IDE or some “I do everything, but none of it particularly well” editor. I work mostly with HTML, Javascript, Node.js and need a text editor that does that job and does it without getting in my way. If I need FTP, or SSH or one of the many other tools that are useful to developers then I’d rather use the inevitably superior standalone versions, not have them cluttering up and complicating the editor. That isn’t to say that there aren’t some non-editing functions that can benefit from being integrated with the editor, just that I’d rather choose what those features are.

Unfortunately, Sublime Text is limping ever closer to an early grave, Atom is no closer to being usable (unless you enjoy swimming in a half empty swimming pool filled with treacle). End result; I switched to using Brackets as my day-to-day editor. By now, Brackets is well enough known that there’s no point in me singing it’s praises. If you still haven’t tried it then you should. Unlike the competition, it’s free, open source, multi-platform, expandable, modern and has a very low learning curve.

The beauty of Brackets is that the editor itself is written using web technologies — HTML, CSS, Javascript. This also means that anyone who knows these technologies can extend the editor with extensions. In January 2015 (the last date I can find stats for) there were 616 extensions from 371 different authors. Of course, not all of these extensions are going to be useful but many are. In no particular order, here are four extensions that I use every day:

 

Brackets Git
by Martin Zagora

This extension is both incredibly powerful and easy to use. An instantly accessible dialog gives access to most of the Git functions you’ll need day-to-day; Pull, Push, Stage, Commit and many more. The interface is clean, intuitive and unobtrusive but if you find the built-in commands aren’t enough there is one click access to a Terminal/Command window opened in the projects folder.

All of the available commands can be accessed from here.
All of the available commands can be accessed from the bottom panel
Git Diffs of changes are displayed in an editor dialog
Git Diffs of changes are displayed in an editor dialog

A particularly useful feature is that changes made since the last commit are highlighted by a coloured block in the editor gutter. Clicking this block reveals the changes and gives us the option to revert it with just one click.

Changes made since the last commit can be viewed and reverted if necessary
Changes made since the last commit can be viewed and reverted if necessary

 

Brackets ESLint
by Andrée Hansson

ESLint is by far the most most configurable and most useful Javascript linter. Install this extension and your code can be validated for adherence to your coding standards and style guidelines on each save.

Code is linted on save
Code is linted on save

 

Show Whitespace
by Dennis Kehrig

Does what it says on the label.

Whitespace Off
Whitespace Off
Whitespace On
Whitespace On

 

White Space Sanitizer
by Miguel Castillo

If you’ve recently started using JSHint, JSLintESLint or some other, lesser-known, linting tool, the chances are (depending on the strictness of the settings) that you were shocked by the number of errors or warnings your code generated. Many of these alerts will likely be the result of your excessive or perverse use of whitespace. Lines with trailing spaces or containing only spaces, mixed tabs and spaces — all common mistakes. Install White Space Sanitizer and those problems will soon be a distant memory. On every save (but before linting) your white space will be cleaned up automatically.

 

All of these extensions and many, many more can be installed directly from within Brackets using the Extension Manager or from their respective GitHub repos.


More:

Ternary Operators in Javascript aren’t just harmful, they’re selfish and evil

 
I recently spent many hours pouring over the CodeMirror source code in an attempt to track down a number of unpleasant bugs that turned what should have been a straightforward and quick update to my Brackets editor extension ‘Go To Matching Bracket‘ into a day-long slog.

The main reason for the wasted time? The unnecessary and excessive use of ternary operators (and ternary operators inside ternary operators inside ternary operators), whose soul intention seems to be nothing more than to obfuscate logic at every opportunity. Oh, and to save a few characters typing, because the web is short of characters and we don’t want to use them all up.

Apart from being ugly, confusing and error prone, ternary operators are a premature optimisation and usually turn simple refactoring into rewriting – they can rarely be sensibly expanded upon without reverting back to using a regular if/else statement (or heaping more stupid on top of the existing stupid).

So, next time you’re thinking about using a ternary operator, stop for a minute, read David Hayes excellent essay ‘Ternary Operators Considered Harmful‘ then… don’t. Just don’t.

Bonus:

If you’re using the excellent ESLint to improve the quality of your code then you can minimise the destruction that ternary operators wreak by enabling either the no-ternary or no-nested-ternary rule in your .eslintrc config file.


"no-nested-ternary": [2]

Add either of these rules, run ESLint in a Git pre-commit hook and you’ll never waste your colleagues time again (well, not with ternary operators anyway).

Iterate and improve

I think I tend to have this picture in my head that “master programmers” just get it “right” on the first pass. It’s incredibly comforting to know that being a great programmer is not about never making mistakes; rather, it’s about knowing how to continually iterate and improve on a solution.

– Ben Nadel reviews “Clean Code: A Handbook of Agile Software Craftmanship” by Robert C. Martin (a.k.a. “Uncle Bob”)

 

More: