The good thing about being relatively new to a specific area is that you ask a lot of "dumb questions" that make people think. It also means you are unemcumbered by tradition, less set in your ways and more willing to accept new ideas.

And so it goes with the software development industry. Some day I'll be a crusty stubborn old man no doubt, but until that day I'm ready to soak up new ways of doing things. Writing software can be a tedious exercise and making tedious exercises less tedious is something that computers are really good at. I'm all for letting computers do my job.

If you're wondering where this latest spout is coming from, the hamster wheel started turning when I read Brad Abram's post about case convention in the official guidelines. It's the same old endless argument that has probably happened a thousand times with a thousand different APIs, and it's obvious that no one has come up with a perfect solution. Regardless, it amazed me that developers get hung up over seemingly minor issues like naming conventions, bracketing and indenting. In the comments I said it wasn't a big deal if people sometimes deviated from the guidelines when it made sense to do so. I don't think anyone else agreed with me. :)

Then I realised that these developers are probably using their favourite text editor to code (like emacs and vi). They like everything just so, otherwise they have to think about formatting. Thinking about formatting is bad -- it distracts them from the real task: coding! So this causes developers to get all "religious" about these issues. Having a simple case guideline means that you can "code blind" for a bit without wondering if you typed a method name incorrectly.

Well I think maybe these developers should get out of the stone ages. Sorry boys and girls, but the days of the POTE (plain old text editor) are numbered. It's time to pick up a modern integrated development environment (IDE) ... it can actually help you code faster and free your mind.

For example, would people really care about naming case conventions as much as they do if they used Intellisense? I don't think so. You type the first two or three letters in any case and Intellisense brings up a list of member variables and methods starting with those letters. Pick the one you want and presto, the case is done for you automagically.

Indenting is really a simple problem that was solved by tabs. As long as the team uses tabs for indenting, any developer on the team can pick any number of spaces for the tab that they want. Simple text editors provide this too, yet people still argue about tab widths.

Bracketing is another thorny issue with C/C++/Java/C# developers. Do you like the opening { on the same line or on a new line? The team ends up choosing a convention and sticking with it. Shouldn't IDEs allow user-customization of bracketing, converting between the user's preference and the source control system's (the team's)?

Eclipse half solves this problem already because in the CVS view you can choose to see only logical differences in the code (not bracketing or spacing). Eclipse can also quickly format the code to the user's preference of bracketing and other formatting options. So in theory you could download the latest version of a file and format it the way you like (one keystroke) and still be able to tell if there was a logical diff even though the formatting is completely different. The only thing Eclipse needs to do now is have a place to set a preference for the CVS formatting and it could automagically convert back to that format before it checks in logical changes. Then voila, you have individual developer formatting and everyone on the team is happy as clams no matter what the "official convention" is.

Reducing these points of friction using tools can really simplify our lives as software developers. What's holding this stuff up from being adopted I wonder? Stagnation?

After watching the two managed code episodes of The .NET Show and hearing the all of the guys say "quicker time to market" over and over, you can bet that better tools will be created to increase development speed even more. Developers will have to keep up with the new technologies or be left in the dust by more efficient managed code and tool-using developers.