We have a large team comprising of developers, interns who write rails and backbone js code with large codebase.

We already have tools like JSCS and code climate to analyze the code and report errors to the developers so that they fix it.

I tried to introduce fixmyjs, tool which corrects silly syntax errors automatically. One other senior developer suggested to hold on to this since we are still in transition of team of developers who write code, to team of developers who understands what writing good code means.

I understand the concern that, if this is introduced, developers might find it easy to get their code approved without understanding how to write good code, since the tool will be doing that for them.

My argument is that ultimate aim of any organization/team is to deliver products as soon as possible without compromising on quality. And this tool helps us to do that.

Educating someone is not the primary concern when you are doing business. There should be equal responsibility on the developer to educate himself to understand what needs to be done.

I feel not using a tool, because that will make developers not learn what needs to be done is not correct.

Your thoughts please.

closed as primarily opinion-based by user22815, gnat, user53019, user40980, durron597 Jun 28 '15 at 0:46

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


we are still in transition of team of developers who write code, to team of developers who understands what writing good code means.

Guess what - you will never leave that transition path (because even if you do programming for more than a decade, you can still learn something about better coding)! So do your team a favor, let them use your tool now, but make sure the people make a diff comparison of how the code looks before and afterwards to learn something from this. It might be also a good idea to introduce your team to the tool by explaining each type of code improvement it does, and the reasoning behind it.

When you wait introducing that tool until your devs come to the point where they write only "perfect" code, they will probably do not need your tool any more.

  • 1
    I purposely avoided adding your answer in my question, so that someone else says it without me leading them there. Thanks for the answer. – vishwanath Jun 26 '15 at 12:04

I would argue: Probably good for your business's productivity; but potentially bad for your developers' careers.

It's probably good for your business's productivity because, in some respect, all code is "rewritten" before it's executed. Adding another layer of rewrites can be considered a language mutation or extension. And if the extensions help productivity, that's good. In fact, congrats, you've created a new dialect. (hooray...)

But, it's only probably good for your business's productivity because certain "language extensions" can promote sloppiness or even just "a different mode of thinking" that extends into areas of that code that aren't being rewritten, or possibly can't be rewritten.

It's potentially bad for your developers' careers because they could become accustomed to writing a sub-language that only your organization uses. If your developers aren't encouraged to just "write it right" according to predominating standards, you are potentially harming their future careers -- oh so slightly.

That said, I would encourage the incorporation of extensions that your developers are fully aware of, and which rewrite code only for the purpose of increasing productivity by expanding on condensed code. Extensions shouldn't "correct" broken code, allowing developers to be blissfully ignorant that their code is wrong; extensions should warn about or fail broken code.

To be clear: your extensions should be called extensions, and they should only be in the business of taking well-documented "short things" and expanding them out "somewhat longer things."


Code correction is like auto-complete or auto-format, a tool that helps devs not worry about the minutiae of the code and focus more on what it should be doing.

However giving code correction to a dev that doesn't understand the syntax is like giving autocorrect to beginning English speakers, the result will often be readable/understandable but rarely correct. (Resulting in the now popular substitution of "ratchet" for "wretched")

  • Difference with the code correction is, it is independent of the user/developer and relies solely on parsing of the file done by the tool. So it's less prone to human error as mentioned in your case. (Trusting a tool completely might be a problem though) – vishwanath Jun 26 '15 at 11:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.