As someone who almost exclusively uses grep for finding what I need in codebases that are new to me and old to me, you can make whatever arbitrary rules you want, as long as you're consistent, I'll be pretty happy with it. If syntax is loose in some area (single vs double quotes, parens or braces or none), just do the same thing every time. Whitespace consistency isn't crucial, but it can't hurt (between function name and parens, for example).
I'm also thinking long-context LLMs are going to make this advice seem pretty archaic in a few years. They're so good at reading code and extremely useful for asking questions of a code base.
That said, I completely agree with the author on not using clever string tricks to compose identifiers. That makes code both harder to search and to read.
Agreed. So long as the code hits performance and business goals, there doesn't need to be an emphasis put on "newness" or any other sort of vanity metric - make the code obvious, searchable, and understandable so that in a time crunch or during an outage it's easy to search and find the culprit.
