Having a Complete Lack of Style is a Good Thing

In this era of open source projects I’m more than a little surprised that official code styles still exist at companies. After all, on any given day I or any developer could find themselves diving into company code, AngularJS’s code, Bootstrap’s code, or any one of the innumerable third party libraries that end up in code bases these days. With all these differing contributors we developers can and do end up plumbing through a wide array of code styles thereby making adhering to one style for one part of the code nothing more than busy work. With consequences.

Through the ether I can hear an argument for, “I can tell what code base I’m in by how it’s written,” and I don’t care about that. I also think we’d be better off as teams if no one cared. Remember, all code in your project is you and your team’s responsibility whether it came from someone in house or is something off of GitHub or even if it came from a StackOverflow post. I would hope and expect a professional developer to be able to read the code where ever it came from and the casing of variables or where they are placed will be of no consequence to their ability to perform their job.

In all my 12 years of doing professional development, the only thing that style guides have ever really been good for taking the teeth out of code reviews. With style guides, the focus of code review observations often become about how something is or isn’t commented per the style, or variables don’t have the right naming convention per the style or something else inconsequential is out of place per the style and what’s missed is (true story) the code itself doesn’t even compile because the author coded foo(“bar”, , 42);. That function with a missing parameter made it through review I’m sure in part because the code around it looked up to style. Company style guides are a distraction of low hanging fruit for developers to grab and “contribute” to the project instead of doing a service to the code by picking it apart and looking for actual problems.

Then there’s blindly following the guide because “That’s what we do” and at this time I find myself at a great point to bring up goto. Early on in my computer science education I learned we don’t use goto. It’s bad bad bad and so we just don’t don’t don’t. I followed that guidance blindly for years until rather recently I saw some sample code from Microsoft. In it goto was used to skip creating additional COM objects when the initialization of one of the required objects failed. By skipping, the goto brought the flow to the cleanup of the objects that had been made. Well that’s a great use! Why run code that doesn’t have a chance at succeeding anyway? Sure there’s other ways to deal with this type of failure but my point here is, the goto based solution was valid.

Edit 5/27/16: I had something here about just needing well organized code but I’ve had to admit to myself that my motivations for well organized code were misguided. I had also said you didn’t need meaningful variable names cause I was waxing academic so I’m going to change that stance to for corporate code, ya need rare strings for quick grepping. Origination to the point where a rare string can be searched for in 1 second or so affords decent productivity. With as fast as machines are today, that leaves a lot of latitude to conduct development which remains good cause in doing so, you may find yourself learning new tricks from others by way of freedom of expression! 🙂