101–110 of 116 posts
Yoda conditionals are still very popular in the PHP/Wordpress space. I never got used to using them personally.
They're required per the WordPress PHP Coding Standards and flagged by the WordPress rules for PHPLint. Lots of WordPress developers stick to those standards, so that's why you see it everywhere.
All linters and C compilers emit a warning when an assignment is made in a condition. There are zero reasons to use that ugly and unnatural Yoda notation in 2019.
Furthermore, when we have a problem, if our solution is to have human beings simply remember to do it a different way, we then have two problems.
Earlier quoted context omitted.
I find this quote very powerful. I'm thinking I could re-use it. Is it yours or if it's sourced from somewhere could you share the source?
It seems like an intentional reference to this quote (Jamie Zawinski): "Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems."
Earlier quoted context omitted.
By that logic, shouldn't you be creating a var for the expression_argument() return?
Indeed I probably would, just didn't want to distract from the central point in that post.
Did you compare writing in different ways and reading it later? This specific style confuses me the most, because I have to mentally connect an assignment with a flow control, because there is no guarantee that a following if() will not use a different variable or it was not shadowed, misnamed, etc. And given that, at once I see x2-3 lines less than usual.
I once worked for a place that explicitly told me not to do this. They also told me to test booleans with if( booleanVariable == true ) ... This was also the place that ordered me not to use LINQ statements because, and I quote, "you need to write code that someone fresh out of high school could understand". I don't work there any more.
Earlier quoted context omitted.
You must be young, friend. The holy wars that used to rage over just where to put curly brackets... (And then Python came along and was like, "U wot mate?", and there were had little wars over "syntactically-significant indentation" and tabs vs. spaces, and how many spaces ... And on, and on...)
Oh no, I'm not young. I just find this particular argument makes less sense than all the other types of arguments like this. Bracket placement in some languages is necessary to not have unintended effect. Tabs vs spaces can cause problems with certain ides/editors. I can somewhat understand most justifications as to why people have a certain reason for formatting code in their particular way. You want me to indent 3…
I got lucky I think. The first time I saw "yoda" conditions I had an abreaction. But then I realized the programmer who wrote it was "a foreigner, with ways different than our own." That somehow made it alright again.
Virginia Satir said that people would choose the familiar even over death. She said the strongest human drive is for the familiar.
Jef Raskin pointed out that the way we use the word "intuitive" it really means "familiar". The first time he handed a mouse to someone to try, who hadn't previously seen it in use, she turned it over and used it like a little trackball.
I'm pretty sure the only reason we don't all use Lisp is just human drive for what's already familiar.
Earlier quoted context omitted.
Not all languages allows chained assignment (a=b=c) like c++ does, which is why we have this problem (and probably does not automatically cast them to bool either)
Chained assignment isn't the reason. The similarity of the "=" and "==" operators is. Specifically, it's both (1) easy to make a typo where you meant "==" but typed "=" and (2) not easy to visually distinguish the two.
Java for example expects a bool for for if(). if(a=b) is only valid when they are, which is relatively rare. So it is mostly a compile error.
I once worked for a place that explicitly told me not to do this. They also told me to test booleans with if( booleanVariable == true ) ... This was also the place that ordered me not to use LINQ statements because, and I quote, "you need to write code that someone fresh out of high school could understand". I don't work there any more.
We actually have to write boolean checks like that in Kotlin nowadays in modern Android development. If your variable type is Boolean? instead of Boolean, it is needed to both check if it is non-null and true.
if( nullableBooleanVariable ?? false )
Earlier quoted context omitted.
if (systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT) != 0) if (0 != systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)) One may find it easier to read/navigate flow control in C code that returns status codes, when these codes are stated beforehand. When there are series of long lines and a mix of 0==success and 0==false, it is easy to get lost, at least…
I'd break this up by lines, every time. int result = systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)) if (result != 0) Separation of concerns. Each line does one thing. Making a system call and branching on its result are two separate tasks.
In the past, I've done things like this:
#define TRY(exp) \
do { \
int TRY_result = exp; \
if (TRY_result != 0) \
return TRY_result; \
} while (0)
TRY(systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)));