The example for "Don't split up identifiers" is impractical when you need to construct a string on the fly. Author's example might work for the simple case of two potential values, but as soon as addressType can take on more than a trivial number of values, the code becomes very non-DRY.
Also, the example completely glosses over the egregious use of magic constants. Wouldn't it be better to declare addressType an enum?
The example for "Use the same names for things across the stack" only works if you control the whole stack. Sometimes you have to get fetch data from a 3rd party. And even if you do own the whole stack, sometimes it's nice to be able to search for 'streetName' when you're looking for the JS symbol, and 'street_name' when you're looking for the DB column. So I don't think this rule is always beneficial.
At the end of the day, if you really want to make your code grepable, add some verbose comments that include useful keywords. (I've found it useful to include keywords that aren't even in the code but which devs may search for.) This lets you grep regardless of how the code is written or formatted.
Also, the example completely glosses over the egregious use of magic constants. Wouldn't it be better to declare addressType an enum?
The example for "Use the same names for things across the stack" only works if you control the whole stack. Sometimes you have to get fetch data from a 3rd party. And even if you do own the whole stack, sometimes it's nice to be able to search for 'streetName' when you're looking for the JS symbol, and 'street_name' when you're looking for the DB column. So I don't think this rule is always beneficial.
At the end of the day, if you really want to make your code grepable, add some verbose comments that include useful keywords. (I've found it useful to include keywords that aren't even in the code but which devs may search for.) This lets you grep regardless of how the code is written or formatted.