Ensuring editing consistency with .editorconfig


Today I updated my recently created GitHub repo configs to include my .editorconfig file. EditorConfig is one of those incredibly simple ideas that I initially hesitated to install (“is that all it does?”) but now find invaluable. By defining a few properties in a file that you store in your repo, usually in the root, you can go some way to ensuring that everyone that works on your source uses the same basic whitespace settings; indent style, indent size, line terminator, and so on.

Nowadays, many (most?) editors allow for settings at both the user and project level, but often a project repo doesn’t include a settings file for the project or, if it does, it’s for an editor that you don’t use. If you work on multiple projects with differing conventions or even just in a team where everyone uses their own favourite editor, EditorConfig can ensure consistency of layout and less time wasted in reformatting.

EditorConfig consists of two parts; a simple configuration file, .editorconfig, and an editor/IDE plugin. Once you have selected and installed the plugin for your preferred editor (at the time of writing there were over twenty available) you can set your preferences and you’re ready to go. As it’s a simple text file it can be checked into your repo to ensure that everyone working on your project shares the same settings.

The config file allows eight properties to be set with seven of them allowing you to control the appearance of your code.

EditorConfig

EditorConfig is one of those things, like Markdown formatted ReadMe’s, that has become ubiquitous in open source projects. Even a cursory browse through GitHub or BitBucket will reveal that many projects make use of it.

My own .editorconfig can be found in my configs repo, a small collection of my most-used config files on GitHub.



More:

 

The work #2


Of the hundreds upon hundreds of programmers we’ve worked or spoken with in the past year, I can’t think of a single time when the existence or absence of a degree made any difference. Anecdotally, we’ve seen little correlation between being a good programmer and having a degree in computer science (yes, even when it comes to understanding stuff like the growth of functions or tail-call optimization). There does, however, seem to be a strong correlation between writing lots of code, loving programming, and being awesome.

— Nick Bergson-Shilcock




More:

Moving a tag on a Git branch to a different commit


Today I slipped up when assigning a release tag to a Git repo. After committing my changes and pushing them to GitHub I tagged the HEAD as v1.0.0 and pushed the tags to the remote. Almost immediately I realised that I had forgotten to make a change that I really wanted to be included in that release. Now, the changes had already been pushed to the remote (GitHub in this case) so the sensible and proper thing to do would be to commit my fix and tag it as v1.0.1 but, as this is currently a private repo which only I have access to, I decided to move the tag.
It’s been a while since I’ve done that so it took me a few attempts to remember exactly the steps involved so I thought I’d document them here “just in case”.

If all you’re looking for is the commands, here they are (in these examples I’m assuming the tag to be moved is ‘v1.0.0′). A more detailed explanation follows.


$ git tag -d v1.0.0

$ git push origin :refs/tags/v1.0.0

$ git tag v1.0.0

$ git push origin master --tags



How it works

Firstly, let’s have a look at the state of the repo before running any of these commands


$ git log

* 276ceee (HEAD, master) Fixed spelling.
* 204f97c (tag: v1.0.0, origin/master) Initial commit.

As expected, the tag v1.0.0 is on the initial commit rather than the HEAD, which is where we want it to be.
[Note that I’ve abbreviated the output for clarity].

A quick check of the repo in GitHub confirms that the tag has already been pushed, and is associated with commit 204f97c

Tags_1

The first thing we want to do is delete the v1.0.0 tag from the local repo using git tag -d:


$ git tag -d v1.0.0

Deleted tag 'v1.0.0' (was 204f97c)

$ git log

* 276ceee (HEAD, master) Fixed spelling.
* 204f97c (origin/master) Initial commit.




Then remove it from the remote repo (GitHub):


$ git push origin :refs/tags/v1.0.0

To https://github.com/davidwaterston/test.git
- [deleted] v1.0.0




Then we can assign the tag to the new HEAD:


$ git tag v1.0.0
$ git lg
* 276ceee (HEAD, tag: v1.0.0, master) Fixed spelling.
* 204f97c (origin/master) Initial commit.




and push it to the remote:


$ git push origin master --tags

Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 288 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/davidwaterston/test.git
204f97c..276ceee master -> master
* [new tag] v1.0.0 -> v1.0.0




Another quick look at GitHub and we can see that the tag is still there but has been moved to the new commit, 276ceee:

Tags_2



Mission accomplished.

A new GitHub repo for config files


Earlier today I created a new public GitHub repo, called configs, appropriately enough. Simply put, this is going to be somewhere for me to keep my development configuration files so that they are always and easily accessible. Should anyone else find them of use then that would be a bonus.

The first config added to this new repo, .eslintrc, is for ESLint, the linting tool for Javascript and JSX that helps detect errors and highlights confusing constructs and violations of stylistic conventions. Having tried both JSLint and JSHint in the past I settled on ESLint as, compared to those alternatives, I find it to be more comprehensive in its checks, better documented and very easily extended.

I have a number of other config files I intend to add to the new repo but I’m taking the opportunity to give them the once over, refresh their contents and bring them up-to-date so updates will be spread over the next week or so.

More:

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 here.

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:

The work


This.

One could argue we should consider the good-enough-to-get-a-job skills to be the “baseline.” But there are a whole lot of front-end jobs to choose from, and getting one doesn’t establish much of a baseline. For me, I don’t want to get a job; I want to get invited to great jobs. I don’t want to go to work; I want to go to work with talented people. And I don’t want to be satisfied with knowing enough to do the work that needed to be done yesterday; I want to know how to do the work that will need to get done tomorrow.
— Rebecca Murphey



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).