3

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.

  • I don't know if it would do what you are after (I'll dig into it a bit more), but you might want to post a sample code bit (what it was, what it should be - not necessarily your code but just something as an example) and flag this for migration to Software Recommendations.SE where tool recommendations are on topic. – user40980 Dec 10 '14 at 1:50
  • @MichaelT Good idea, it might be better there. I don't see a migration option to rec in the flags though – Yamikuronue Dec 10 '14 at 1:53
  • We cannot migrate to a beta site. It might be better to remove verbiage related to the tool recommendation and ask "how do I do this?" on Stack Overflow. Personally, I would ask if there is a regular expression that can do this. Most developer tools I have used offer a way to use regex to search and replace over multiple files. I would also include examples of some tricky areas that might trip up a regex (you will get better quality answers that way). Plus, it never hurts to take a stab at it yourself and explain what you tried. – user22815 Dec 10 '14 at 5:13
  • @Snowman a mod can (see example). The key is to have a sufficiently high quality answer to migrate in the first place. That said, it can be tailored to a number of different ways to make it most appropriate for each site. – user40980 Dec 10 '14 at 5:54
  • I'm open to moving this wherever it makes sense. – Yamikuronue Dec 10 '14 at 12:29
10

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.

  • Eh, that's out of my hands. The team wants to have a standard quoting rule, and I'm looking for possibilities to make that not painful. If they change their minds and want to remove the rule, that's totally fine by me, but it's not my call to make decisions like that for the whole team, that's on the team leads. – Yamikuronue Dec 10 '14 at 12:30
  • @Yamikuronue: the fact you don't like my answer does not make it a bad answer. Since the technical problem is not to be solved so easily, at least not with a certain risk of introducing some unwanted bugs somewhere in your code base, you should consider to discuss with your superiors if it is really worth the effort. My answer might give you some arguments for this discussion. – Doc Brown Dec 10 '14 at 13:38
  • 1
    I find answers that offer no solutions but instead challenge the frame of the question are rarely useful. This is one of many avenues I'm pursuing; what I need is information on how plausible this would be, to weigh against other options. Your answer gives me no useful information, and feels like a rant instead. Perhaps I shouldn't have asked at all. – Yamikuronue Dec 10 '14 at 15:20
  • 1
    @Yamikuronue: edited my answer to make it sound less than a rant. – Doc Brown Dec 10 '14 at 15:45
  • Downvote revoked; it's still not the answer I'd hoped for but at least it's answering the question more now. Thanks – Yamikuronue Dec 10 '14 at 15:48
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.

1

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.

-1

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.

  • Three weeks is almost a whole sprint in some shops, and the team would do nothing else. Not a good option. – Yamikuronue Jul 5 '16 at 11:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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