Easy way to make old javascript files conform to new quoting standard?

Question

We've just started putting linting in place at my workplace, and a lot of the devs didn't realize our standards called for double-quotes everywhere. About 50% of the codebase uses single-quotes, so it's no easier to change the rule than to make the older code conform. Is there a tool or utility we could use to automatically fix older files? It's fine if we have to verify the output after, it's a lot easier to find problems in a few edge cases than to open and adjust every single file in a large codebase.

Before:

var foo = 'bar'
var bat = 'baz: "stuff"'

After:

var foo = "bar"
var bat = 'baz: "stuff"' //allowed

I'm open to any method, including using an existing tool, using regex in some kind of perl or batch file, anything to avoid spending large amounts of human time fixing what is ultimately a minor problem writ large across multiple code bases. The sheer magnitude of the problem dissuades people from attempting to fix it, and I'd like a way to help with that. Please leave discussion about the wisdom of this option out of it, as this is just one of many options I'm looking into -- if there's a nice easy way to deal with it, then the team leads will want to know about it, and if there's not, that will factor into the discussion as well.

Also keep in mind that this is just the rule that's most obvious now that the linting standards are in effect. Anything that can fix other errors as well (double equals where triple was needed also comes to mind) would be useful as well.

Answer 1

As @MainMa has well pointed out, the technical problem might can be solved with a certain effort, but not easily without the risk of introducing some hidden bugs into your codebase (and the risk is high if the codebase is large, and you would probably not have asked such a question for a small codebase).

See this in contrast with the fact that this coding standard rule seems to serve only some formal criteria, but it does not really improve readability. In such a situation I think you should actually discuss this with your team and ask if the rule is really so important, since

• with or without the rule, everyone of your team must know that string literals in javascript can be created either with single or double quotes (your own example shows this clearly)

• you have a lot of hassle for no benefit with your existing code

• whenever you copy/paste some code from somewhere else, you will encounter the same hassle

I suggest you ask your team to remove that rule from your standard - coding standards should serve you, not vice versa. Maybe they leave it in as a recommendation for new written code, but not mandatory.

Answer 2

Given your example, specifically the part where single quotes are not replaced, I don't think any off-the-shelf solution will do the job for you. I imagine that writing a custom tool which uses a JavaScript tokenizer would be too complicated as well.

On the other hand, you may replace automatically single quotes by double quotes. With regular expressions, you may go far enough to handle cases where single quoted string contains double quotes. Of course, there may be cases [practically] impossible to handle with regular expressions, such as:

var a = "'Hello \\\"World's.'"

The problem which remains is to avoid regressions while replacing the characters.

• If you have unit tests with enough coverage, you're probably fine. Just run those tests very frequently during the procedure to pinpoint the location of a mistake, if any.

• If not, one of the ways to find regressions is to use Closure Compiler. It will generate consistent results independently of the quotes you use (all single quotes are replaced by double quotes). During the replacement of single quotes by double quotes, run Closure Compiler regularly and verify that its output is exactly the same as the one you had at the beginning.

Answer 3

I've done some similar things (migrating a VB3 app to VB4, for example) with some perl scripts. The scripts would take the original file and produce two new files: one the output file (with the corrections) and the other a list of the changes/substitutions performed, as well as messages indicating that something unusual was seen and wasn't changed. I found this easier to read than a diff (which you can easily generate if you prefer that). The key seems to be to create a sample file with every permutation you can think of and run your script against that until you have it right. Then run it against your biggest/most-challenging file and hand-check the output to make sure everything looks right. If your code is under source control, then you can easily revert to the original version if things aren't working right, but for a well-defined problem a good script should get you 99% of the way there.

Answer 4

As pointed out by others, doing the whole thing automatically could introduce bugs. Software development is often about weighing up automating a process with just doing it manually; it often ends up a bit of both. I would recommend doing this particular task manually, perhaps with some search and replace, each file one by one.

1. Get a list of files to change.
2. Each coder can perform the changes to 1-2 files per day. With the oversight of changing the quotes, they can fix other non standard code as well.
3. Mark them off as they are changed.

I have no idea how many files there are but if there are 100 files, it would take less than 3 weeks to change them all with 5 coders working on them.