If you're involved in the Rails community (don't worry, this isn't another pro-Rails post), then you're likely familiar with #sass and #haml. While these tools will try to initially sell you on their brevity and clarity, I think there is another important problem that they solve: the need to create those god-forsaken coding standards documents. You know the ones: "Thou shalt placeth thy braces upon a new line, and put spaces between 'if' and the opening parenthesis."<p>No one likes writing these style documents. No one likes following them. No one likes enforcing them.<p>And yet they are a reality. So, along came "code formatters" that allowed you to take the way someone formatted <i>their</i> code, and minify/re-expand the code to fit your coding style. You like tabs instead of spaces? Code formatters gave you the power to say, "Screw your style document!" to everyone on your team, if you so desired.<p>But code formatters didn't ultimately solve the problem of code needing to be nearly universally readable by other coders. Instead they avoided the problem by giving you a workaround. This was still an improvement in many cases, but not good enough.<p>Enter tools like #sass and #haml (any many others). The beauty of the approach of these tools is that the things that actually matter about code style (clarity of structure, reducing bugs arising from poor formatting, greasing the wheels of communication between developers) is enforced at the tool level. #haml simply <i>will not compile</i> into equivalent and proper HTML unless it's formatted and indented correctly. The tool itself not only helps improve code correctness, but actually enforces style that's "good enough" to be almost universally readable by all. No, it doesn't solve the problem of poorly chosen identifier names, but that's okay.<p>Now, before you go cry about "opinionated software" that borders on being Orwellian, and how you think your coding style is an extension of your creativity as a human being, just take a moment and think about how much you enjoy discussing and debating coding standards within your team. You hate it, don't you? It's a complete waste of your time, and the people who generally win the especially heated debates on this topic are often overbearing jerks, which makes you resent the standard even more.<p>Stop worrying about your style being a reflection of your creativity. It's not. Your best, most awesome creative power as a programmer is the ability to <i>create software</i>, not your ability to design indentaion schemes, which inevitably lead you to becoming defensive and dogmatic about said schemes (I exclude Robert C. Martin from the previous line: I am a fan of your work, generally speaking, and at least you tried to accomplish this on an industry-level where it really mattered, not just on an individual team level).<p>Whenever I can use a language or tool that enforces code style at the tool level (i.e. compilation doesn't happen until it's correct), I'm willing to give it a shot simply because it means it might grease the wheels of inter-developer communication. If it also solves the problem that I need solved at an engineering level, and doesn't create a new set of equally difficult formatting problems of its own, then I'm sold.<p>I think you should do the same, and forever abandon arguments about code style wherever you can. It's a waste of your time, your team's time, your management's time, and creates a needless debate in a place that's supposed to be about building great software. Except for the 1 in 1,000,000 people who actually want to debate code style for what they call "fun", I'm telling you, no one gives a crap. So long as we can all efficiently discuss the code itself, that's what we want.<p>P.S. I'm currently looking for a tool that does for Java, what #haml does for HTML. If you know of such a tool, please post it on this StackOverflow Question - and thank you!<p>http://stackoverflow.com/questions/8418416/html-haml-as-java