Inform or Accommodate?

Should you stop the build when someone breaks your formatting rules? Should you detect and fix them? There were two comments on the previous post: Oliver agreed, and Will didn’t:

Instead of raising errors when things like whitespace or tabs occur, why not just modify the file to correct it?

After some reflection I decided that you shouldn’t clean up on behalf of others. At best, you take away their feedback loop, at worst you compound the error. They need to know that something is wrong, so they have a chance to improve. But you can make tools to help them clean up their mess:

desc "Turn crap into gold"
task :midas do
  Dir["public/**/*.js"].each do |f|
    next if f.match(/^lib|resources/)
    sh "sed -i '' 's/  /  /g' #{f}"
    sh "sed -i '' 's/ $//' #{f}"

One thought on “Inform or Accommodate?

  1. Will says:

    The feedback loop is an important point, and I recall a usability lesson about auto-correct in word processors. If you’re always automatically correcting typos, the user never gets a chance to a) notice the problem and b) take steps to correct it.

    Instead of auto-correcting, most word processors unobtrusively highlight the problem (e.g a red squiggle underline), allowing the user to notice and correct in their own time without interruption from their current task.

    Taking this metaphor onboard, I think that the solution to the formatting rules problem should be solved in a more unobtrusive way, allowing the user to be aware of the problem, but not be a deal breaker for their commit.. Build sub-tasks and notification methods could be used in such a way (I have a couple of ideas).

    Just my opinion. Of course its different if you’re on an individual or small team. I just am recalling nightmares from a previous life..

Comments are closed.

%d bloggers like this: