« Considering a Digital SLR | Home | Weird comment behavior »
Holy Wars and Heavyweight Choices
By Jacob Cohen | April 16, 2007
There are a variety of holy wars out there in the computer world, particularly among those who would consider themselves “power users.” There are many well-known versions of the holy war, such as text editors (vi vs Emacs), or posting styles for e-mail and forum messages (Top-posting vs Bottom-posting), or using tabs vs using spaces to indent lines of code.
I think part of the problem is that the choice is quite heavyweight. It is often either intrinsic to the application (Microsoft Outlook, for example, will always top-post replies to e-mail messages), or is a configuration setting that you have to change every time you want to switch behavior (such as using tabs or spaces to indent).
A mess often arises from trying to support a heterogeneous set of these choices across a set of applications that assume a homogenous set of choices in the data and files they manipulate. For example, if some people in an e-mail discussion use top posting, and others use bottom posting, and yet others use inline replying, you get this unreadable mess of nested replies that is quite difficult to follow. If you use tabs to indent, and someone else modifies the file and uses spaces, it looks very poor in an editor that assigns a different width to the tabs than the space-indenter used.
I think these clashes would seem greatly diminished if the applications were a little more flexible in terms of the conventions they use. E-mail clients should be able to detect the reply structure being used, and either continue using that same style, or modify the existing text to conform to the style used for the reply. Text editors should be able to determine if code was indented using spaces or tabs, and either continue using the same approach, or modify the code to conform to the style used in the current editor.
It might irritate you that your co-workers use tabs when you like to use spaces, or reply using top-posting instead of inline replying, but it shouldn’t be such a hassle to convert from one to the other. Indeed, some people have gone as far as to write scripts that convert from tabs to spaces and back as code is checked in and out of a source control system. If all applications were inherently this flexible, everyone would be able to locally view and manipulate text and data in the format they prefer, while not forcing the repercussions of that preference on future consumers of the same text and data.
Topics: General |
