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