I think the 3 points are decent guidance in general but I feel you probably should have included some examples of when it doesn’t make sense to follow them. Like everything in life, the actual realization of something is more complicated and we should provide guidance that speaks to nuances that might affect design/implementation decisions. It’s something I think we lost (or the loss accelerated) within the last 15-20 years. Now everything is “you have to do this or you’re terrible at programming” and the nuances are lost as the entire thing is framed in a way to try to grab attention/views. I don’t mean to imply you’re doing that here, just a general observation that articles and videos on programming rarely include more nuanced things.

Anyways, I agree with the overall content of the post but felt I’d provide some counter examples for each point. Admittedly they may not be the best but calling out something like them I think would be worth doing so readers have a wider view of the topic and can make more informed decisions.

Point 1: This is great general advice; be consistent with your names. However, it’s simply not feasible in certain situations. Are you building a data access library? You’re going to need dynamically named things. Maybe your system has thousands of tables (yes it happens, the real world is messy). I would much rather work on a system that uses dynamic names which enforces naming consistency than deal with some switch statement covering hundreds/thousands of things. Not only would the code be cleaner and easier to deal with that way but it would have the added benefit of running everything through the same naming logic and therefore helping with name consistencies.

Point 2: Name consistency is important (see end of above) but don’t force it when it doesn’t make sense. If you have two distinct systems/services that each operate in different domains but share some underlying data source. Maybe the enrollment service calls something an enrollment but the billing system calls it a line item. The freedom to name things appropriately for how they’re used is important and should be another tool in your belt. It also helps business users/managers/etc… and programmers have a shared understanding of domain terminology/requirements/etc…

Point 3: I’d agree for the most part and this is generally great advice. Sometimes it makes sense to go hierarchical. For example human readable configs can benefit from hierarchical structures since we like to process information by grouping things. I’d rather just have a json or yaml section called DataSources than have to repeat the “datasources.datasource1.name”, “datasources.datasource2.name” and so forth for every single datasource defined in the config.

I think the points you made are great. We should use them when appropriate though and knowing when it’s appropriate or not is something we should try to teach along with the rules themselves.

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.)

Using git grep os one of the most practical things I do. Whether to look for definitions, usages, or getting a list or overview of endpoints on an api, I use it for all. It’s ubiquitous, works everywhere.

Yes, other tools exist that give you this information in a clear way. But the practicality of grep is amazing.

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.