I think this depends on the crowd. Unfortunately, the intelligent crowd and the crowd with money and power is not exactly the same. Though hopefully there is overlap.

I think this points to a large problem in our society is how we train and pick our managers. Oh wait we don’t. They pick us.

Which distro?

This. Especially if your team does not follow SOLID principles (as then someone fixes a bug in a base class method that shouldn’t be shared. This fixes an issue in a subclass but introduces one in another. Rinse, repeat.

Yes and no. I mean sure, if you are going to leverage this to gain a significant edge in the market, that works.

If you add a tool to the project, that you need to understand to maintain some parts of it, which adds to the learning curve of someone joining said team, then the gains have best be worth the effort.

We adopt so many librairies/plugins/tools over time that adding more complexity than you need this way is just terrible.

Yeah, but it’s easy to overuse it. If your for loop is much longer. For a few lines I’d agree, don’t bother using something longer.

Code should scream out it’s intent for the reader to see. It’s why you are doing something that needs to be communicated, not what you are doing. “i”, “counter” or “index” all scream out what you are doing, not why. This is more important than the name being short (but for equal explanations of intent, go with the shorter name). The for loop does that already.

If you can’t do that, be more precise. At the least make it “cardIndex”, or “searchIndex”. It makes it easier to connect the dots.

Being facts does not prevent them from being non sequiturs.