Matching Google Chrome’s developer tools theme to your text editor theme

Sublime Text 2
Sublime Text 2

My main coding text editor is the excellent Sublime Text 2, my favourite theme is called Tomorrow-Night by Chris Kempson, and my go-to browser is Google Chrome.

Being involved in web design I use the Chrome web developer tools all the time for debugging JavaScript, identifying HTML classes and tweaking CSS. It looks like this:

Google Chrome developer tools
Google Chrome developer tools

But as you can see from the screenshot above, the default view is rather dull: white background, uninspiring syntax highlighting. It’s a shame that you can’t match the Chrome developer tools code panel with my text editor of choice.

User StyleSheets

Well, it turns out you can! Chrome provides a “User StyleSheets” directory into what you can drop a Custom.css file.

C:\Users\%username%\AppData\Local\Google\Chrome\User Data\Default\User StyleSheets\
~/Library/Application Support/Google/Chrome/Default/User StyleSheets/
~/.config/chromium/Default/User StyleSheets/

A number of people have also done the hard work for us and made available ready-to-use CSS files for various themes. These are my two favourite dark themes:

  • Tomorrow
  • Monokai (UPDATED: This version works better when editing code in the Elements tab.)

Having saved the code to your Custom.css file and saved it, Chrome updates immediately:

Google Chrome developer tools with Tomorrow theme
Google Chrome developer tools with Tomorrow theme

How to be a Programmer

Button with Enter Code written next to it.

I can’t remember how I stumbled on this essay “How to be a Programmer: A Short, Comprehensive, and Personal Summary“, but it was probably via

I’ve not yet had the change to read it through fully, but I have printed it to PDF so that I can access it at a later date, and on my Psion if I want. It really is worth a read.

Debugging is the cornerstone of being a programmer. The first meaning of the verb to debug is to remove errors, but the meaning that really matters is to see into the execution of a program by examining it. A programmer that cannot debug effectively is blind.

In some ways it reminds me a little of a book that my friend Bernard recommended many years ago: Code Complete by Steve McConnell.

Code Complete is now in its second edition, and has its own website: where you can download sample chapters and example code.

The book is packed with examples of good practice, and tips galore. Back when I was spending more time programming my Psions in OPL I found little tips like prefixing all my global variables with a lower-case ‘g’ really useful, eg gHighScore. It meant that at a glance I could tell whether a particular variable in a procedure was local or global. Simple, obvious, and quite beautiful.

There have been plenty of examples of good behaviour that I’ve been able to incorporate into my web design practices, such as the importance of planning and designing before building, and techniques for self-documenting the code. I even managed to squeeze a sermon out of a one chapter a few years ago: comparing our faith to software development. Sometimes a piece of code says do x, y and then z regardless of what else is going on at the time; at other times the code depends on where it is, and what else has happened. Sometimes our faith is like that too, sometimes we’re in a different place when God comes a visitin’ again.

The day that I preached that sermon there was a visiting computer programmer from Texas in the congregation in Inverness. I was blessed by that, and if I remember correctly the comments that I got at the West Door as people were leaving he was about the only person who fully understood that particular metaphor that day. But then God is like that sometimes: sometimes part of the message is tailor-made for that one person.

I wonder if I can get a sermon out of “How to be a Programmer”?