+1 for avoiding dynamically constructed identifiers when possible. Fulltext search across multiple files is available in most tools, let it be useful. It sucks having to search for a substring, hoping you guessed the way it gets constructed. Plus, it might not even occur to you that this is what you need to try.

No, no, one of the main benefits of OOP is information hiding. If your code is too greppable, developers can circumvent the information hiding.

(Sarcasm)

Very good points. A codebase that gets this VERY wrong is Gitlab. I think it might be a dumb characteristic of Ruby programs, but they generate identifiers all over the place. I once had to literally give up following some code because I could not find what it was calling anywhere. Insanity.

Another point: don’t use - in names. Eventually you’ll have to write them down in a programming language, at which point you have to change the name. CSS made this mistake. foo-bar in CSS maps to fooBar in Javascript. Rust also made this mistake with crate names. A crate called foo-bar magically becomes foo_bar in Rust code.

This is one of the reasons why I don’t like short variable names, especially single letters (unless for very narrow use and obvious like i).

I sort of agree with some points, especially the ones about dynamic identifier creation and renaming identifiers, but those last 2 to me sounds a lot like you don’t know how to search beyond the really basic “I want this string here”, I’m assuming that it’s an effort to enable whoever comes next to search and find everything they should find mindlessly, not knowing the project, since the author talks about navigating foreign code bases, but I think compromises can be made when you should expect just a bit more effort from contributors for the sake of a more rationally organised code base

Greppability also contributed to this thingy

int
main()
{
  // dam
}

in Mozilla C-style and GNU C-style projects. Of course, it’s a remnant of the past (grep ^main), but kgmgaehgka.

I agree with the first point. Always go for clarity over cleverness.

I somewhat disagree with the second point. Consistency is important. Stick with the same name when possible. But I think mixing camel case and snake case should be avoided. It can make the code less ”greppable” IMO, because now you need to remember which casing was used for each variable.

Kind of agree on the third point. I think flatness should be preferred when possible and when it makes sense. Easier to find the variables with the eyes rather than having to search through nested structures.

I am not a big fan of the first example. If all that a function is doing is pasting its argument into a template string, then I’d rather see that pattern expressed explicitly in a single line of code than have to mentally infer this pattern myself by reading two separately expressed cases in six lines of code.

(It’s not that big of a deal, but when reading through a lot of code to figure out what is going on, these little extra mental exertions start to really add up.)