the art of the grep

At my dayjob they've started enforcing ESLint rules. One of those is that all js strings should be in single quotes, not double.

This seems to be like maybe the wrong standard; for example, assuming your product owner isn't pedantic about "smart" single quotes vs straight quotes, than if you have a string with a word using a contraction, you 'mustn\'t' fail to escape it. (Also I noticed when we grab AJAX payload data from Firefox inspector to shove into a mock, we have to change the double quotes - JSON isn't allowed to use single quotes, only double.)

On the other hand, there's an old tradition where html tends to use " for attributes, so then ' would be safer for javascript that might be in there (err, not that you should be doing that much these days, probably.)

Also, I think single quotes just 'feels cooler' to some engineers. As much as any of those arguments, that's probably why they chose what they did.

And that's fine. The critical thing is to have a standard, since when we adhere to that standard we can do simple cross-file searches 'like this' and not have to re-run them for double quotes, or finagle a regular expression.

The dayjob also use angular translate for localization. It's pretty good, but I've come hate our translation file format, which uses JSON-y hierarchy like this:
{
 SOMEPAGE: {
   FORM1:{
     CAPTION1:'This is form one caption one',
     CAPTION2:'This is form two caption two',
     ERROR:'This is an error message.'
    }

 }

Those are then referenced in the angular html via something like 

{{ 'SOMPAGE.FORM1.CAPTION1' | translate }} 

and in the code something like  

$translate.instant('SOMEPAGE.FORM1.ERROR');

So I think one problem is obvious; once that .js file gets big, it's tough to cross reference 'SOMPAGE.FORM1.CAPTION1' and find it in the file, you have to manually walk down the hierarchy, you can't just do a simple cross-file search for it (some properly configured editors will jump you there though.)

The other problem is: merges can be rather nightmarish. If something happens and curly braces and/or indentation start to get junked up, unwinding that is a laborious task.

The old barbaric way of doing it would be like

SOMEPAGE.FORM1.CAPTION1=This is form one caption one

SOMEPAGE.FORM1.CAPTION2=This is form one caption two

SOMEPAGE.FORM1.ERROR=This is an error message.

So that looks kind of ugly and redundant, but it's ton easier to grep and merge. 

The hierarchy has some advantages, like it does make sure things are grouped pretty well, but mostly I think coders went that way because it's cool, and doesn't look as clunky as the old "properties file" format, or its JSON-ish equivalent. 

Actually the hierarchy thing reminds me a bit of why JSON beat XML... to quote the old Coding Horror blog:

Wouldn't it be nice to have easily readable, understandable data and configuration files, without all those sharp, pointy angle brackets jabbing you directly in your ever-lovin' eyeballs?

In this case, wanting to enforce hierarchy seems pretty parallel to the structure enforcement XML purists crave.