We Are Mobile First
In the first post in the Know Your Damn IDE blog series, I focused on the strengths and limitations of specific IDEs. This second instalment focuses on one of the most useful (but perhaps seen as one of the most frivolous) features found in integrated development environments: colour customization.
Developers spend a big chunk of their time both reading and writing code so why don’t we all make the effort to make it more identifiable? Working with a defined colour palette within your IDE could help you to identify any possible issues or sections of code which may be prone to errors. Furthermore, since we spend around 6-8 hours a day working our way through code, choosing a set of colours that we find relaxing may prevent fatigue in our sight.
What does my setup look like? Read on to find out!
Since I am a believer in leading by example, I’m going to share some screenshots of my current colour setup in Xcode – my IDE of choice.
The aforementioned code is taken from one of my iOS projects, titled ‘OptimusPrime’; it’s a prime number calculator that I use as a demo project for talks, workshops and crazy tests.
At a glance, thanks to my colour coding, I’m able to distinguish the following:
System reserved keywords (pink): System reserved keywords cannot be overridden by any means and compilation fails if we try to do so.
I probably don’t know every system reserved keyword in Xcode, so having some way of distinguishing them easily is most welcome!
Apple’s owned properties, classes and functions (cyan) versus user-defined properties, classes and functions (lime green): Apple-owned and user-defined objects, properties or functions, work in exactly the same way but errors arising from their code are solved in completely different ways – especially since we can modify our implementations but not Apple’s.
It, thus, helps to have some definition between the two.
Hardcoded numbers (purple) and strings (red): Most developers, including myself, agree that hardcodes should be avoided at all costs.
By giving them a dedicated set of colours, we may be able to spot them easier and thus replace them with constants much sooner.
Comments (grey): Comments are code clarifications (or part of the IDE on-screen documentation) but they aren’t a part of the actual code that is compiled or processed.
They should, therefore, be coloured accordingly as a non-essential part of the file.
Property and framework declarations, in-function property accessors (white): When paying more attention, I can also see that function invokes are brighter than property invokes.
In my particular case, I didn’t even need to spend time customising the colour palette as one of the default palettes in my IDE suited my needs and personal taste.
In previous Xcode and macOS versions, however, I did have to customize it using the ‘Midnight’ palette as a base:
In terms of customisation, I would soften the contrast across the colours and increase the font size, since my eyesight could not handle the fatigue caused by the default contrast and the tiny font on a huge screen.
Luckily for me, however, the new Default (Dark) palette that came in the last Xcode release is the perfect fit!
In the initial screenshots, there are several additional visual elements that you may have noticed. These elements, whilst unrelated to colour customisation, provide me with some additional information that I find useful when coding.
Let’s review them!
‘Currently editing’ line marker. The current line in the source code editor is highlighted, thus providing an easy way to know which line I am editing when typing.
It’s also a great indication of whether or not you’ve scrolled outside of the editing scope.
Line numbers. The presence of the current file line numbers in the left margin serves a number of purposes.
Firstly, here at We Are Mobile First, we don’t like large source files. They are difficult to debug and maintain. As discussed in our post on healthy coding practices, we use the single responsibility principle. If a file is too large, it usually means that we can split our code into smaller tasks. As a rule, I try to keep my files within less than 150 lines of code (excluding comments).
Secondly, having the line numbers in sight is useful when debugging, since the compiler or the debugger may refer to the line of code that triggered an error.
Lastly, when using a version control tool, having the line numbers in sight is helpful when merging or peer-reviewing code.
Updated with respect to version control tool. Some may have noticed the blue marker alongside the line numbers on some of the lines. These marks highlight which lines of code have been changed with respect to the last commit in our version control tool.
Right vertical margin. We use linters on several projects. One of the most common rules we use is ‘at most XXX characters in a single line’. ‘XXX’, in this context, is usually 120. Tired of triggering compiler warnings or errors, I set up Xcode to automatically add this vertical margin at the 120th character in a single line so I have a visual reference of that limit.
Folding markers. The code folders that sit alongside the line numbers allow me to easily fold/unfold pieces of code.
Having a visually appealing setup is easily accomplished in most current IDEs and yet I haven’t seen that many developers customizing their own.
It may seem frivolous but all it takes is five minutes of your time and, in turn, it may aid your eyesight and help to improve your performance. It’s a no brainer!
---
I’d love to know what colour palette you usually use in your IDEs and why.Tweet us at @WeAreMobile1st and we’ll be sure to retweet your responses.
This is the second blog post in a series in which I’ll share my experiences with some of the most popular IDEs (such as Xcode, Sublime Text and, maybe, Android Studio).
In the next post in the series, I’ll be looking at keyboard shortcuts and how we can use them in our IDEs to optimize our time. Follow us on Twitter, LinkedIn or Medium to be notified of our future posts.