In January I was lucky enough to participate in a project review session for General Assembly a programmer bootcamp here in Austin, TX. I was one of three professional software devs brought in to provide feedback on the students’ projects. The feedback can be on anything, from how they approached the UX, their data models, how they used git… anything.

During each presentation each team had a set of topics that they had to talk about, one of them being “rose, bud, thorn” or “what was great about this project/experience”, “what will you take on to your next project(s)”, and “what sucked”.

One team of students began a demo of their search filters for a recipe site they had built. It had a great amazon-esque checkbox filter system where you could pick recipe ingredients to filter the list of recipes on the site. It worked really well.

For their “what sucked” part, one of the team members brought up the code for the checkbox filtering and showed how it worked. There was a collection of around twenty if statements that controlled what happened when one of the recipe filters was chosen.

So for each checkbox there was a matching hidden field in a form so the selected search filters could be sent to the server and the search could be carried out. A truly righteous hack, if I may say so.

When the rest of the reviewers and I saw this we kinda chuckled a bit - which to be honest, probably wasn’t the best response - but I explained that we were all chuckling because hacks are a common thing in software development and we’d all done hacks like that (or in worse) to make something work to meet a deadline. It’s a fact of life. And it’s a friggin’ important one too.

We should create hacks more often. Don’t kill yourself for 2-3 hours to try to find the best/most correct way to do something immediately. If you meet resistance, do the simplest thing that could possibly work - make a hack - and move on. Come back to it - or even better get someone to pair or code review what you’ve done - and refactor it when you know the better way to do it. Bad code is… well, yeah, bad… but it’s also super important since it helps us grow and become better.

You won’t forget your hacks easily. They’ll stay with you for a while; they will keep you up at night. In fact, one night, you’ll probably refactor them into as few lines of code as possible.

And one day you’ll come back to those hacks, years from now and chuckle too.

Lately, I’ve beeen working on a lot of projects with different people/languages/editors, most of us were new git’ers and each project had a real problem with trailing whitespace.

Fred and Tim

It all starts out innocently enough. Fred, a mid-level developer at InfoTech Systems opens up his IM client and fires off a chat to a co-worker: “Hey Tim, can you check out my pull request? I’m done with the ratings feature and think we should merge it in”.

Tim, a Senior Software Developer, has been writing code since the mid 80’s. He originally started out contributing to the Gnome project and then bounced around the corporate world, Lotus, Microsoft, Oracle but now works with Fred at a small startup where they and five other developers are trying to build the next great cat-picture rating website - CatR.

“Ok, let me CR it”, CR is the teams short-hand for Code Review. Even though most of the team are experienced programmers every feature and bug fix commit must be reviewed by another developer.

Fred is the “new guy” on the team, this is his third day at InfoTech and he’s submitting his first feature enhancement. Even though Fred has 8 years of coding under his belt, he still gets a little nervous when someone reviews his code.

“Hmmmmm” Tim types back. Ugh, This can’t be good Fred thinks.

“This git diff looks weird. How many lines did you change in the main stylesheet?”

“Only 2 why?” Fred types back, starting to get a bit defensive. He takes a few quick, deep breaths and calms down.

“The diff is lighting up like a christmas tree. Check your diff locally.”

Fred opens up a terminal and does a quick check to see what Tim is talking about:

git diff master product-ratings-feature

“Crap!” the word jumps instantly into Freds mind. He can see immediately what Tims talking about. There a bunch of lines where the only thing different is the whitespace at the beginning or end of the line.

“Ugh, yeah I see it” Fred types back.

“Well, we can’t pull this in yet dude, we only want to have diffs show what we actually changed so if something goes south in the future we’re not scratching our heads looking at a all whitespace commit. Go back and check your whitespace settings, re-save and let me know when I can review it again.”

“Great, guess I’ve got some more work to do” Fred says to himself. He lets out a fairly audible sigh, opens up Visual Studio and starts typing away at the keyboard.

The moral of the story

Trailing whitespace issues can cause a lot of problems when they get into your repository. It leads to falsey diffs which claim lines have been changed when in fact the only thing that changed was spacing.

This can make finding what actually changed in a file later on in the development cycle next to impossible. Most open source project leads know this and a lot of them will reject pull requests that fail to trim whitespace (or have other

A lot of IDEs and text editors have options to configure trailing whitespace (SublimeText make this insanely easy) but Visual Studio, amazingly, has no option for this.

Now save your new macro and whenever you save a file in Visual Studio this will run and trim all the trailing whitespace.

How to Remove trailing whitespace on save in Sublime Text 2

In Sublime Text, open up the preferences menu and select “File Settings - User”

this is important because if you use the “Default” settings, they may be overwritten when you update Sublime Text to a new version.

Scroll down until you see "trim_trailing_white_space_on_save", set this option to true

Save

Profit

Get Git to help you out

In the example above Fred could have saved himself a lot of time if he ran one command:

mv .git/hooks/pre-commit.sample .git/hooks/pre-commit

This file has a check (on the last line) that will fail any commit when there are whitespace errors. It’s not enabled by default so you have to remove the .sample from the file name to get git to run it.