Ramblings of Narc

Okay, call me slow, but I’ve only just discovered the post Style Is Substance by Ken Arnold, and I had an epiphany (nor was I the first to have it, as evidenced by the attached comment thread): coding style (i.e. the rules of whitespace, formatting, and whatever) should be IDE-specific.

Wait, let me backtrack a minute first: the post in question specified that a language’s syntax should be standardized in the official language documentation, and that any deviation from it should be flagged as a compiler/interpreter error. Forcibly. With no way to relax the setting.

I’m going to let you digest that for a second.

Ready? Okay, here’s the next interesting part:

In the end, this requires only that editors and IDEs used by coders will let the user type stuff and it will make it look right. This is basically just reformatting on the fly, which many editors already do. We don’t need you to type zero, one or seventeen spaces between an if and its open paren, we just need the editor (assuming K&R C) to put exactly one space there. And getting even this right will be easier if there is only one style to worry about. It’s one of those things that those reformatting or style adapting cycles can go to.

(emphasis mine)

Now my epiphany: if the IDE could do this (and there’s absolutely no reason why it couldn’t), why can’t it also do the reverse, i.e. translate the standard form into something you like? And if everyone’s IDEs did that, it would finally let Billy code in his personal style, old timer Gabe in his, and have the assurance that the result won’t have several formatting styles because there is only one style!

Where does all this break down? Well, there are a few things, such as:

• whitespace for emphasis — in the comments thread, there is an example of a tic-tac-toe game board expressed as a continuous array, C-style, formatted into “lines” and “columns”, making it infinitely more readable than the equivalent all-on-one-line version.
• whitespace for emphasis, again — another example was of vertical whitespace (and comments) used as a delimiter for important code, making it stand out.
• uncheckables are given in the article — namely, Hungarian notation, and {get,set} method prefixes.
• IDE standardization was also put forward as a possible bad idea, but I personally fail to see the issue — it’s not standardization, but rather adding to a common feature set requirement.
• On that same point, though, I’d like to add in the inability to edit in Notepad, at least, not with ease. Maybe you have two or three IDEs to choose from, but you will have to use an IDE — Notepad just won’t cut it anymore. Not that it really does nowadays, what with the lack of syntax highlighting, but it’s still a valid point.

For some of these, I can envision some creative solutions, such as some (hopefully standard) special comments used as “hints” for extra whitespace or special formatting for display, while still forcing the generated code to adhere to the standard style — but once we do that, we’re back to square one since all the current style problems will get pushed into the comment hints instead. Maybe there’s a midway point there where we could (at least theoretically) have our cake and eat it, too. Maybe not. Any ideas?