It has been emphasized many times over many years the importance of well crafted code. Much better developers than I have written books on object-oriented principles, design patterns, clean code, and test-driven development. The language of how to build better software has become almost ubiquitous. There is little question about the value of separating concerns or loosely coupling dependencies. We don’t hear a lot of buzz around why huge methods are better than smaller ones with fewer branches of execution.

However, much less emphasis is placed on how our code looks. How important is it to have strict naming conventions or consistent indent spacing? Does it really matter if we mix snake-case and camel-case when naming our methods, as long as they are only a few lines long and are responsible for only one thing? Who cares if our methods or variables contain misspellings? These conversations tend to be cast aside as philosophical debates, mostly considered a matter of preference or taste. However, how our code looks can have some very deep and powerful effects.

Developers are human and, therefore, not immune to the power of context. We are deliberate, precise, and acutely aware of simple, even if subtle, signals. When looking at code for the first time, we pick up very quickly and subconsciously on many hints about the application and its authors. The file structure speaks to the level of emphasis on organization. Method size reveals adherence to clean coding practices. The presence of unit tests tells us that quality matters.

But what does it say when method names contain misspellings, or variable names cycle between camel-case, title-case, and snake-case? What message is received when we see unnecessary white space and inconsistently indented code? What does it matter that our log messages are wildly different from each other in form and style? These deficiencies send a subtle, yet powerful and destructive message: We don’t care. Anything goes here.

The Broken Windows Theory was introduced by social scientists in the 1980’s to describe the effect that small, seemingly unimportant details have on the prevalence of crime. A building with broken windows has the tendency to encourage vandals to break more windows, break into the building, or even light fires inside. In other words, broken windows are a subtle hint to vandals that there is an absence of order or caretakers.

Introducing a developer to a code base with such a message plants a seed that can spread quickly like an epidemic. With unclear patterns or conventions, a developer feels free to introduce his own style, which could be even more inconsistent itself than the code it is being introduced into. The code base grows, and so does the chaos.

Don’t allow your code to be vandalized. Fix your broken windows. Is one case better than another? Are spaces better than tabs? No. These debates truly are philosophical and purely preferential in nature. What matters most is consistency. Consistency declares loudly and proudly that there is law and order here. There are rules that are meant to be enforced. Pick a style and stick to it. Enforce it. Hold everyone responsible and accountable for abiding by and enforcing the rules.

By the way, use spaces, not tabs.