[dwh452]

This sounds like the advice to prefer the variable name 'ii' over 'i' because you can easily search for it. I loath such advice because it causes the code to become ugly. Similarly, there are 'YODA Conditions' which make code hard to comprehend which solves an insignificant error that is easily caught with tooling. The problem with advice like these is you will encounter deranged developers that become obsessive about such things and make the code base ugly trying to implement dozens of style rules. Code should look good. Making a piece of text look good for other humans to comprehend I consider to be job #1 or #2 for a good developer.

[ajuc]

> 'ii' over 'i'

You don't need to search for local variables, nobody names global variables "i" - so the "ii" advice is pointless.

You often do need to search for places where global stuff is referenced, and while IDEs can help with that - the same things that break grepability often break "find references" in IDE. For example if you dynamically construct function names to call, play with reflections, preproccessor, macros, etc.

So it's a good advice to avoid these things.

> you will encounter deranged developers that become obsessive about such things and make the code base ugly

You can abuse any rule, including

> Code should look good.

and I'd argue the more general a rule is - the more likely it is to be abused. So I prefer specific rules like "don't construct identifiers dynamically" to general "be good" rules.

[moolcool]

> The problem with advice like these is you will encounter deranged developers that become obsessive about such things and make the code base ugly trying to implement dozens of style rules

That's more of a "deranged developer" problem than a problem with the guidelines themselves. E.g. I think his `getTableName` example is quite sensible, but also one which some dogmatic engineers would flag and code-golf down to the one-liner.

[Aachen]

> prefer the variable name 'ii' over 'i'

Vim users don't have this issue, where you can * a variable name you're looking for and that'll enforce word boundaries.

PHP developers also don't have this issue: the $ before is a pretty sure indicator you're working with a variable named i and not a random i in a word or comment somewhere

Y'all should just use proper tools. No newfangled Rust and Netbeans that the kids love these days, the 80s had it all!

(Note this is all in jest :) I do use vim and php but it's obviously not a reason to use a certain language or editor; I just wondered to myself why I don't have this problem and realised there's two reasons.)

[antifa]

> the advice to prefer the variable name 'ii' over 'i' because you can easily search for it

\bi\b is the easy way to search for i.

[marcosdumay]

Those things only make the codebase "ugly" until you learn how to read it.

[inetknght]

> This sounds like the advice to prefer the variable name 'ii' over 'i' because you can easily search for it

I've never heard of that advice. I honestly like algebraic names (singular digits) as long as they're well documented in a comment or aliasing another longer-name.

> there are 'YODA Conditions' which make code hard to comprehend which solves an insignificant error that is easily caught with tooling

Yoda conditions [0] are a useful defensive programming technique and does not reduce readability except to someone new to it. I argue it improves readability, particularly for myself.

As for tooling... it doesn't catch every case for every language.

> I loath such advice because it causes the code to become ugly.

Beauty is in the eye of the beholder. While I appreciate your opinion, I also reject it out of hand for professional developers. Instead of deciding whether code is "ugly" perhaps you should decide whether the code is useful. Feel free to keep your pretty code in your personal projects (and show them off so you can highlight how your style really comes together for that one really cool thing you're doing).

> you will encounter deranged developers that become obsessive about such things

I don't like being called deranged but I am definitely obsessed about eliminated whole classes of bugs just by the coding design and style not allowing them to happen. If safe code is "ugly" to you... well then I consider myself to be a better developer than you. I'd rather have ugly code that's easily testable instead of pretty code that's difficult to test in isolation which most developers end up writing.

> Code should look good. Making a piece of text look good for other humans to comprehend I consider to be job #1 or #2 for a good developer.

It depends on the project. Just remember that what looks good to you isn't what looks good to me. So if it's your personal project, then make it look good! If it's something we're both working on... then expect to defend your stylistic choices with numbers and logic instead of arguments about "pretty".

Then, from the article:

> Flat is better than nested

If I'm searching for something in JSON I'm going to use jq [1] instead of grep. Use the right tools for the right job after all. I definitely prefer much richer structured data instead of a flat list of key-value pairs.

[0] https://en.wikipedia.org/wiki/Yoda_conditions

[1] https://en.wikipedia.org/wiki/Jq_(programming_language)