DEV Community: Matt Jones

I wrap my code at 80 columns; why you should too

Matt Jones — Tue, 15 Jan 2019 07:04:59 +0000

Part of my standard Visual Studio setup on a fresh install is to add editor guidelines with a guide set at column 80, and to tell Resharper that it should wrap my code at 80 columns as well. In an era of high DPI, super-wide screens why should I adopt a column width that is more suited to the era of teleprinters and pre-GUI green-screen terminals?

Naming

Naming members when you only have a few columns to play with suddenly becomes really important; you can't get away with _incrediblyLongVariableNameLikeThis any more because it uses up a quarter of your available width, even before you start passing it around as a parameter.

Variable names have to be descriptive enough to be useful and unambiguous, but now also have to be concise enough to fit. We all know naming things is difficult, but adding this extra constraint requires that we give it a few cycles more thought.

Indentation and nesting

If every time you have a new scope (be it class, method, delegate, if, while or switch) you lose a tab width (4 characters) then that's 5% of the available width taken straight off. Thus in a conventionally formatted C# class file, you're already losing one tab width each for namespace, module and method; we're at column 12 before we even start writing any implementation.

Complex passages of code (particularly ones that use conditionals like if and switch statements) now carry an overhead in legibility, which is a good thing because too many nested ifs and switches also place a cognitive burden on the reviewer in understanding the code itself.

Inlining

While it can be tempting to achieve some dazzling algorithmic trickery in a single line of code, your colleagues may not be as impressed when you're on holiday and they've got to debug it.

Inlining code is useful in some circumstances but, as ever, too much of a good thing is, by definition too much. Adding a new constraint of column width places just enough of a restriction to force the developer to think about formatting, and not to concatenate so many calls into few lines.

Review

GitHub's default behavior for PR review is to present the diff in a split screen; the existing code on the left, your proposed change on the right. Wrapping code at 80 characters ensures that these two panes sit comfortably side-by-side on a single screen, and that GitHub doesn't have to wrap the code onto extra lines that don't exist in the original file. This is a great help when I review diffs as it's immediately obvious what has been added or modified, and my eye doesn't have to take in additional lines in order to understand the full statement.

In summary, this is why I think formatting your code to wrap at 80 columns gives you just enough of a constraint to work within, with the result being code that is easier to review and understand.

Starting Again

Matt Jones — Tue, 06 Feb 2018 15:58:50 +0000

It was midday on the day I was meant to be skulking away from the office early to jump in the car to head to a job interview in London. I was sitting at my desk, IDE open, a sensation of terror slowly rising from my gut through my chest and into my mouth. I was looking at a small, fairly simple C# challenge on a coding website, and I was petrified. I had no idea how to even get started on the task, let alone what single thing I could do as a step towards a solution.

The interview later that day was to be a pair-programming exercise; you sit with one or two other devs from your potential new employer, you consider a task they describe and then set about working towards a solution together, all the while they are assessing your approach and way of thinking. I hadn't really done much pair-programming for my day job; my employers up until that point had never really been sold on it, and every time I had ever coded with anyone looking over my shoulder, my fingers (normal top speed of 60+ wpm) turned into frozen sausages.

I'm a self-taught dev; as a kid we always had a BBC model B/Vic 20/Spectrum machine in the house because both my parents were programmers, starting their jobs in the days when that meant arranging holes in punched tape. Lacking any kind of hand-eye coordination I never really enjoyed playing games on computers so I mainly wrote small programs. 8-bit machines became PCs; BASIC became VB6 became OOP and finally C# and .NET. I never, ever thought I'd make a living out of it, and that developing software would feed and clothe me very satisfactorily for nearly 20 years. I truly have fallen on my feet, and I am terrifically grateful for everyone who has placed trust in me despite having absolutely no qualifications for the work I do.

Not having any kind of degree, let alone at CS degree, I feel I have missed out on much of the academic approach to the subject that my formally-educated colleagues have. Without referring to a model implementation, I cannot write a binary search method, complete the tenpin bowling game TDD kata or any of the other bread-and-butter tasks you'd expect from someone with nearly 20 years in the biz. I wasn't even sure what bits, bytes, unsigned integers and floating point numbers meant until (relatively) recently. This is like a bricklayer not knowing what a trowel is, or a doctor not knowing what a bone is.

I'm also ham-strung by how learning resources have changed utterly; when I was learning on the job there was no Stackoverflow and very few online code examples. The only resources were books; great clumsy hunks of dead tree, containing wisdom that was probably correct at the time of printing, but whose subject matter evolves every single day. Nowadays, model implementations and example code is EVERYWHERE - you only have to type a few keywords of an exception message or method signature into Google, and up comes the wisdom of those kind souls who've already been there, done it and left a breadcrumb for the next traveler. This leads to an existence that feels almost parasitic; I take other people's code, adapt it to my own ends and chuck it in the pot. This isn't learning as we used to know it, and certainly it isn't personally satisfying.

That's not to say I've learned nothing over my career; I have a deep reverence for clean, simple, object-oriented code. I believe passionately that the value of quality code is not just to "MAKE COMPUTER DO STUFF" but also as a matter of courtesy to the next girl/guy who has to take it forward, or indeed to myself six months down the road. I believe TDD is the key to "just enough" development and therefore to reduce waste and Vanity Monuments. I believe learning is the only way to get to be a more confident person, let alone a developer, and as much as I want to learn from those who've been down this road before, I want to be that person for those that come after me as well.

What I need to learn is the very act of learning, not just finding. I need to practice these simple exercises and respect them as a journey, rather than dismiss the destination itself as trivial. I need to learn not to be phased or panicked or bored because I can't work it out for myself. I need to learn how to think slowly, one step at a time, and forget the rest of the complexity until we get there.

Hi, I'm Matt Jones

Matt Jones — Wed, 19 Jul 2017 11:46:27 +0000

I have been coding for money for 18 years.

You can find me on GitHub as jonesm13

I live in London.

I mostly program in these languages: c#/js/html/sql.

I am currently learning more about functional programming/f#.

Nice to meet you.