If you write code, one of the things you discover quickly is that there is a significant amount of personal style that goes into your code. Most of the time it’s pedantic, a matter of a few spaces or parentheses; but more often than you might expect, it can play a significant role in code clarity, to the point of interfering with understanding what the code is doing.
Imagine, to give an analogy, if someone insisted on WRITING EVERY SINGLE THING THEY EVER WROTE IN CAPS AND ONLY IN CAPS, NO MATTER WHAT IT WAS, AND INSISTED THAT IF YOU WROTE ANYTHING TO THEM, THEY WOULD REWRITE WHAT YOU WROTE TO BE ALL IN CAPS TOO. Sure, you’d be able to understand what they’re saying, but all of those caps hinder the message they’re conveying. Or imagine if someone were to write everything with no punctuation and as a single sentence even when ending the sentence or putting in some punctuation marks was necessary wouldnt that be annoying after a while you would lose track of what they were saying and there would even be some grammatical ambiguities and then it would be even worse if they decided that every time you wrote something they had to rewrite it so that it didnt have any punctuation in it. So you can see how simple things like bracket placement, parenthetical styling, and indentation can interfere with interpretation of code.
But, you ask, is it really so important? Isn’t it more important that code run and give correct answers, than for it to be understandable? True, if you’re an end-user who never touches the source code, you don’t care how it looks. But for research codes or scientific codes, for open-source or collaborative software projects, code readability is a big deal. Imagine if you were on a team where everyone dealt with Microsoft Word documents, and there was one pinhead who insisted on putting everything in HTML format. Or imagine if everyone on your team used Macs, except for one pinhead who used a WIndows machine. These incongruencies caused by a single individual can cause headaches for everybody else.
Enter Artistic Style.
Artistic Style is a program that scripts the pedantic, OCD grooming that would otherwise be required to keep the code clean, consistent, and clear. Via the documentation, Artistic Style takes care of bracket styles, tab options, indentation (horizontal white space), padding (vertical white space), and line/block formatting.
My only wish, for Artistic Style, is that they would do better marketing: I wish I had learned about it before I finished grad school.
Postscript: How to Screw People Over With Artistic Style
There’s a sinister side to Artistic Style, for those users who have a mean streak. It involves Artistic Style used in conjunction with version control. Here it is: applying Artistic Style to a huge source code tree will touch every single code file. If someone has a version of the tree checked out, with significant modifications, then reconciling their changes with the new, artistically-styled code will create a huge number of inconsistencies.
Now, if the “target” of such a move does not know about Artistic Style, this can potentially render entire branches of code, or modifications representing months of work, unusable in a single fell swoop. Such changes can be “held hostage,” so to speak.
But if they do know about Artistic Style – well, in that case, keep looking for another way to outfox them.