I typically do too, or userIndex or something for nested loops, but I will accept i and j for the first two levels of nesting when reviewing a PR because they’re such a convention. I wouldn’t accept variable names like that anywhere else though and try and avoid them myself.

Outside of the for loop counters i and j, short variable names are awful. Coming back to old code written with abr var nams is like talking to someone in the military who just constantly throws out jargon and acronyms that they know you don’t know.

But so are Java style ObserverFactoryManagerTemplateMachinistTemplater names.

There’s a sweet middle ground of short, but actually descriptive name. Sometimes it’s not possible but that’s usually a code organization / language / framework smell.

Too short variable names is usually a sign that you need to use a proper ide, with auto complete, or that you need to use a proper build process that will minify your code after the fact.

Too long names are usually a sign that your module of code (function, class, namespace, etc) is too large, or that your language/framework naming conventions are too strict, or the language doesn’t encapsulate scope properly.

If you want a heavy brick that doesn’t need to move around, then buy a desktop for the power.

If you want a heavy brick that does need to move around, then buy a Think Book so that it can survive a fall.

And if you want a light laptop that’s easy to carry around, then buy a Gram so that it can survive a fall and do basic 2007 things like include a numpad.

MacBooks heavy feel is literally just them overcharging you for something brittle. It’s like being charged more for furniture because it’s heavy only to find outs it’s made with MDF.

Macbooks have decent chips that are limited by Apple’s crappy software, a flat out badly designed OS, nice screens, and way too much weight for their utility.