- Jun 18, 2012
0- by A2 Dev Team
Do you write code differently when you’re working on a personal project versus when you’re writing for work or another project that may one day be someone else’s responsibility? If you don’t, have you considered if you should? Because the answer is probably yes, you should.
We all have code idiosyncracies, habits, odd patterns or even non-standard tools that we like to use. For personal projects that aren’t going anywhere, that’s fine. In fact it’s good and healthy to play around with new, up and coming tools. But when you’re working in a production environment, especially developing a codebase that is meant to last for years, adhering to standards and prioritizing readability is a must.
Douglas Crockford (author of “JavaScript: the Good Parts”) recently said during a Q&A that he would advise against using CoffeeScript in production. He thought it was a solid utiltiy, and even went so far as to say that he would like JavaScript to be more like CoffeeScript. However, he also said that because CoffeeScript was not a standard, it was unreasonable to develop production code under it and expect future developers to know or learn CoffeeScript just to be able to maintain your code. This is solid advice. But how far should it go? Should you also avoid jQuery for production? After all, who knows if jQuery will still be popular in 10 years; maybe your jQuery laden code will look like nonsense to a junior developer in 10 years, and require him to look up documentation for a long gone library. At this point jQuery is probably pretty safe to use, being very popular and widely supported. But it’s still a valid question.
The real answer is your codebase should be consistent. If you choose to use jQuery (or choose not to), be consistent throughout your codebase. As long as you’re only asking future developers to learn and work with a standardized set of tools, it’s not an onerous proposition. As much as possible, make sure those tools are also industry standards as well. This will not only improve the day to day life of your developers, but make hiring and training less daunting as well.
