The first person to create some kind of lint tool for Smile will be shot.
I understand the “desire” to have code be “uniform,” but linting tools, automatic-formatting tools, and other such ilk are an excellent example of not understanding the problem.
There is no “one correct formatting” for source code — in any language! — and style guides just make the problem worse by making you think there is such a thing. The goal of well-written source code is to communicate to other human beings — not the computer — the intent of the program. But intent is art, not science, and like all arts, it’s subjective. And la forme suit le fond, as the French say.
For comparison, the A.P. style guide, or the Chicago Manual of Style, tell you how you should write prose. They also disagree on really basic things. Should you use an Oxford comma, or not? Should you or shouldn’t you use contractions? Are sentence fragments ever acceptable? How long a sentence or paragraph is too long? Or too short?
e e cummings wrote his famous poetry — and his name — in all lowercase. Jesus wept is both the shortest and one of the most meaningful sentences in the Bible. Shakespeare’s most famous sonnet’s first four lines are loaded with what modern authors would consider spelling errors and a sentence fragment — “Shall I compare thee to a Summers day? / Thou art more louely and more temperate: / Rough windes to fhake the darling buds of Maie, / And Sommers leafe hath all to fhort a date…“
The point is that language changes, and language is mutable. You can freely alter it to serve your purposes. Writers always have, and always will.
The same is true in programming languages, especially in a language like Smile that is itself designed to be mutated. There’s no one correct way to write anything — in any programming language. There are only ways that are easier to read than other ways — and what’s easy and pleasant to read depends heavily on your experience and background. To many inexperienced programmers, the formatting below is confusing and heresy; to more experienced programmers, this code reads like art:
switch (field.Kind) {
case FieldKind_Primary: flags |= INITIALIZED | BOLD; break;
case FieldKind_Secondary: flags |= INITIALIZED; break;
case FieldKind_Disabled: flags |= INITIALIZED | GRAYED; break;
case FieldKind_Password: flags |= HIDDEN_TEXT; break;
case FieldKind_Hidden: break;
default: throw new InvalidFieldError(field.Name);
}I could show you what that looks like after it has been through a code-formatter that would put those switch cases on three lines each, with fixed indentation, but I’m not a big fan of ruining beautiful things. Which is exactly what a linter or code-formatter would do to it.
In literature, as in any of the arts, there are always exceptions to every rule. There are reasons not just to break every rule but to beat it to a brutal, bloody death with heavy bats and spiked shoes. Of course, to break the rules properly, you must first know them, and know when to apply them, and when not to. But Picasso didn’t become famous by painting still-lifes of fruit. Monet didn’t become famous through photographic precision of people’s faces. O’Keefe didn’t become famous by painting romantic landscapes. The best artists know the rules, and then break them, establishing new rules that are then broken by the next generation.
Well-designed source code in the 1960s left extra un-punched holes on the punch card between words and numbers to make it easier to fix errors. Well-designed source code in the 1970s put broken while statements inside switch cases because of how much more efficiently it ran. Well-designed source code in the 1980s made sure to write char *x, not char* x, because of how dangerous the “more obvious” form could be. Fashions change, as requirements change, and as preferences change. Today’s “perfect formatting” is tomorrow’s “ugly punch cards.”
So stop with the linters. Stop with the code formatters. Stop making prescriptive software that exists just to enforce your opinion. Because the best code is art, and the best art could care less about your rules.
