Flexibility and coding Standards
Richard Rodger recently wrote a post about how he has given up coding standards and gives some reasons why. If you haven’t read it take a moment to do it now, it think it’s worth it.
I agree that enforcing coding standards inside a company usually has some drawbacks. However, I think that a certain level of cleanliness and use of good practices is mandatory. I don’t care that much about putting the curly braces in the same line or the next but I do care about naming methods and variables coherently and making sure your code is readable and understandable by others.
Of course some proof-of-concept projects and prototypes can be almost butchered just to make it in time for the presentation but when you find yourself patching a project started this way you will agree with me on this: that idea should be refactored into something clean and easily maintainable. Of course you shouldn’t do it if you’re going to dispose of it but we’ve all had projects that started with some quick n’ dirty code and evolved into key projects in our company’s portfolio. In my opinion, the key is to be flexible, known when to allow some room for breathing and creativity and when to demand a minimum of clarity and care for the code.
You wouldn’t want junior developers spending most of their time thinking about how pretty their code looks or how are they going to be bashed in a peer review. We have tools that take care of the basic details like tabs/spaces, indentation, auto-formatting and auto-completing, refactoring methods and variables, we can focus on the task instead of the coding standard. There are plenty of excellent IDEs out there that will happily take care of those things for you. Just sit back, think, and start coding. The rest will come to you.





Leave a Reply
Want to join the discussion?Feel free to contribute!