6 ms·

Like often with this kind of article it barely scratches the surface. "null != variable" will confuse people is downright silly. People confused by this won't

by norswap 11y ago

Like often with this kind of article it barely scratches the surface. "null != variable" will confuse people is downright silly. People confused by this won't have an inkling of what any non-hello-world program does. The rest has some validity, but it focuses on syntax and programming in the very small. It might take a bit of effort, but I can make sense of a tangled function (that's not an excuse to code sloppily though). The real challenges are architectural: understanding how an application is structured is often a daunting task, and yet there are some very simple things one can do to combat this, starting with grouping things thoughtfully, generous pointers in the documentation, and a few paragraphs of architecture overview in the readme file.

njharman 11y ago
yeah, I'm not even sure what's suppose to be confusing? That the "constant" comes first, before the comparison operator?
- mikekchar 11y ago
  I think he's complaining that it doesn't read like English. You aren't testing null, you are testing the variable. There is an implication that the subject of the "sentence" will come first. Of course English order is idiomatic in most programming languages, but I don't think that means you can't have other idioms if there is a reason. I find it amusing that he complains about abusing fluent interfaces (making it read like English for no real benefit), but doesn't realize that he's doing the same thing here. That's why you have coding standards on your team. People agree on the idioms they use. Some people need to be told that it isn't an idiom if only one person likes it, though ;-)
- mc808 11y ago
  Yoda speak, it is confusing like. Most people think "if the variable is not null" rather than "if null, the variable is not". It's easy enough to adapt to the style if it's used consistently throughout a code base, but that effort yields no benefits in most languages.
  - JustSomeNobody 11y ago
    Most people think "if the variable is not null" Only because this is how people are traditionally taught to think. This can be untaught easily enough.
    - firethief 11y ago
      So you can unteach your developers to think... for what purpose?
- jpfed 11y ago
  I am not sure, but here's my guess. If I say (A != B), people may think of this as being equivalent to saying that there's a property we care about- being not equal to B- and we are checking whether A has that property. If I say (Joe != null), then we are saying that there is a property "being not null" and we are checking whether Joe has that property. Feels pretty natural. If I say (null != Joe), then we are saying that there is a property "being not Joe" and we are checking whether null has that property. This is pretty amusing way to think. In the lines after one says something like if (null == myArgument) throw new ArgumentNullException("myArgument") one may proceed with assurance that some properties of null must hold :-) The distinction between null and not-null is so generally useful that I could imagine making a partially-applied function like NotNull, and applying that to Joe (and many other objects). Would NotJoe get much use other than applying it to null? Probably not.
- kilink 11y ago
  For me it's not that it's confusing, it's annoying to read because it indicates that the programmer didn't actually take the time to learn the language, and is instead writing it as C/PHP something else where expressions in if statements don't need to be explicitly boolean (the examples in the article are Java). If they wrote that, what else do they not understand about the language?
  - rileymat2 11y ago
    What if it is 0 but not null? I write in a few different languages throughout a typical week. It is nice to have some explicit statements when juggling between them. I know them very well, but it is still tricky when going back and forth.
    - kilink 11y ago
      That also wouldn't even compile. I also write in multiple languages, and for languages for which this is an issue I use a linter. This isn't even an issue in C if you compile everything with the appropriate flags (-Wall or -Wparentheses).
msluyter 11y ago
Re: "null != variable": I don't think it's necessarily confusing, it's just that usually we tend to think of the elements we're working with (variables, objects, functions, etc...) as taking on values, and so linguistically, we ask "is my thing null?" Not, "is nullness something that applies to my thing?" Hence "thing operation value" is arguably cognitively cheaper than "value operation thing." So you could argue that it's one of those things that increases cognitive load if you're not used to it. That last bit is important because almost anything no matter how convoluted can become acceptable once it becomes a convention. In java I used to wonder why people did this: if ("".equals(str)) {... rather than if (str.equals("")) {... until I got more familiar with NPEs. Now the former seems quite natural.
- gknoy 11y ago
  I think the point was, that as soon as you are aware that typos of "=" and "==" are common, and hard to catch mechanically, the _habit_ of using the (constant == myvar) pattern can suddenly be seen as having more value as a hedge against human error. I'd rather write it that way, and then later change it in code review to `(myvar == constant)`, than risk writing it as `(myvar = constant)` and have it sneak through. Granted unit tests might catch this, but perhaps the error is in the unit test. ;)
  - vitd 11y ago
    For me the _habit_ of using (constant == mylar) is way harder to get used to than using "=" vs "==", which the compiler will warn me about if I mess it up.
  - kilink 11y ago
    Java if statements only allow boolean expressions, so the thing that the Yoda condition is supposed to protect against isn't even possible. I think this is precisely what the author is talking about, as this style is a totally unnecessary holdover from C.
  - MereInterest 11y ago
    I would disagree that they are hard to catch mechanically. GCC will warn about it with -Wparentheses, which is included in -Wall.
matthewtoast 11y ago
I agree that big, deep stuff like architecture and abstractions can be daunting, but I wouldn't be quick to dismiss style and formatting as mere nitpicks. Code clutter can have an outsize effect downwind of those who create it. A codebase is like a home. We all have to live in it. Architecture and abstractions are like the furniture and appliances. Code formatting and syntax are the nicknacks, paper bills, decorations, cat toys, board games etc. Does the toaster really belong on top of that highly flammable mattress? This is a big, deep question about the overall functioning of the home. But throw a pile of ratty blankets on top, put some boxes of moldy half-eaten pizza around the floor, and maybe wind that kite string over the doorknob and around the teetering bookcase. Can you still see the toaster? How do you plan to get in there to move it to a proper place? Small issues can block, conceal, misrepresent, and make big issues even more dangerous. Which why I say: fix all the small things first and stop new clutter from appearing (lint your code), then talk about rearranging the furniture.
- norswap 11y ago
  Oh yes, I agree. But it's a shame it's all people ever talk about, when there's this much bigger thing that looms beneath the surface.
jauco 11y ago
Slightly harder to understand, it is. But incomprehensible, it is not.
JustSomeNobody 11y ago
"null != variable" will confuse people is downright silly. People confused by this won't have an inkling of what any non-hello-world program does. I feel this is one of those things someone new might get confused about the first time they read it. After that, no. IOW, understanding this is part of learning and once it is learned, it is OK.
pyrextamer 11y ago
What if the order depended on the check condition? `if (null == variable) or if (false == variable)` reads well that you are checking for null/false. `if (variable != null) or if (variable != false)` reads well that you want non-null/false conditions.
lostcolony 11y ago
I think you're reading too much into 'confusing'. It won't leave someone without understanding; it -may- cause them to momentarily pause, going "WTF?...uh...probably does ~this~. But why would someone do things this way?" That's still delaying them, that's still distracting them, that's still putting up an obstacle. Not one a future maintainer can't overcome, but -why do it-? That's the point.
- the_af 11y ago
  It seems like a reading micro-optimization to me, though. Surely most of the delays in understanding code lie in things other than "Yoda" conditionals. I'm going to guess complexity elsewhere in the code (even conceptual difficulties, such as "what is the purpose of this at all?") dwarf minor details like how one writes conditionals. If so, what is the point of this piece of advice?
  - mreiland 11y ago
    > It seems like a reading micro-optimization to me, though. It's a "reading micro-optimization" in the same way that not littering your code with comments is a "reading micro-optimization". It makes you pause and interrupts your flow of thought as you contemplate something not directly related to what you were modeling in your head 2 seconds ago.
    - the_af 11y ago
      I don't think it's the same. I'm not arguing against code cleanliness or good practices. Code readability matters. I favor concise, expressive languages over verbose ones for precisely this reason. Littering your code with comments IS a huge readability problem. You are forced to filter them out to find the real code, since they are mostly garbage, but you can never be sure you aren't skipping some vital bit of information. Likewise, boilerplate and needless ceremony obscure the intent of the code, so they are obstacles to be reduced in good, clean code. Contrast this with writing Yoda conditions. They are no big deal. They interrupt your flow of thought exactly once: the first time you encounter them. If your train of thought is interrupted every time you encounter them, you are way too novice a programmer. So I think this is a really minor issue in the sea of software complexity; so minor, in fact, that it seems bizarre to me to mention it. I think whether to use Yoda conditions, much like the placement of braces or the number of whitespaces for indentation, are the stuff of flamewars and endless argument because they are the kind of things we programmers love to obsess about, but they are really not very important.
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
collyw 11y ago
I completely agree. While the small things do make things easier or more difficult, the architecture can make an order of magnitude more difference. The last two applications I have inherited are horrendously over complex and they are performing relatively simple tasks. Far too many joins done at the application level. The front page of the current application I am working on makes over 1000 calls to the database. I don't think it needs more than one for the main part. (And if the logic is really so complex that it can't be done in the database, that's a sign that the database schema probably needs updated.)
jernfrost 11y ago
Yeah that struck me as an exceptionally minor thing to care about. Seriously we got way bigger problems than this in most code: reams of code duplication, 10 classes deep inheritance hierarchies, monster classes, 2 pages long methods. In fact one of the most counterproductive things I have seen at work is people arguing at length about tiny details in the code standard and wasting hours work and goodwill. My take on this is, you give people advice on why a code standard is good to follow. But if they insist on tiny little quirk, let it be. It is not worth fighting over. The whole development community is full of people with all sort of little quirks. At the end of the day we got to get stuff done, and you have to weigh the benefits of stepping on somebody's toes against what you gain from it.
norswap 11y ago
Replying to myself, to say that it is interesting how must people replied to this to comment about the "null != variable" thing. Kinda makes my point. I suppose it could be explained by the fact that it's much easier to say something about the intuition of "null != variable" than to share some architectural insight.

by norswap 11y ago

njharman 11y ago

yeah, I'm not even sure what's suppose to be confusing? That the "constant" comes first, before the comparison operator?

mikekchar 11y ago
I think he's complaining that it doesn't read like English. You aren't testing null, you are testing the variable. There is an implication that the subject of the "sentence" will come first. Of course English order is idiomatic in most programming languages, but I don't think that means you can't have other idioms if there is a reason. I find it amusing that he complains about abusing fluent interfaces (making it read like English for no real benefit), but doesn't realize that he's doing the same thing here. That's why you have coding standards on your team. People agree on the idioms they use. Some people need to be told that it isn't an idiom if only one person likes it, though ;-)
mc808 11y ago
Yoda speak, it is confusing like. Most people think "if the variable is not null" rather than "if null, the variable is not". It's easy enough to adapt to the style if it's used consistently throughout a code base, but that effort yields no benefits in most languages.
- JustSomeNobody 11y ago
  Most people think "if the variable is not null" Only because this is how people are traditionally taught to think. This can be untaught easily enough.
  - firethief 11y ago
    So you can unteach your developers to think... for what purpose?
jpfed 11y ago
I am not sure, but here's my guess. If I say (A != B), people may think of this as being equivalent to saying that there's a property we care about- being not equal to B- and we are checking whether A has that property. If I say (Joe != null), then we are saying that there is a property "being not null" and we are checking whether Joe has that property. Feels pretty natural. If I say (null != Joe), then we are saying that there is a property "being not Joe" and we are checking whether null has that property. This is pretty amusing way to think. In the lines after one says something like if (null == myArgument) throw new ArgumentNullException("myArgument") one may proceed with assurance that some properties of null must hold :-) The distinction between null and not-null is so generally useful that I could imagine making a partially-applied function like NotNull, and applying that to Joe (and many other objects). Would NotJoe get much use other than applying it to null? Probably not.
kilink 11y ago
For me it's not that it's confusing, it's annoying to read because it indicates that the programmer didn't actually take the time to learn the language, and is instead writing it as C/PHP something else where expressions in if statements don't need to be explicitly boolean (the examples in the article are Java). If they wrote that, what else do they not understand about the language?
- rileymat2 11y ago
  What if it is 0 but not null? I write in a few different languages throughout a typical week. It is nice to have some explicit statements when juggling between them. I know them very well, but it is still tricky when going back and forth.
  - kilink 11y ago
    That also wouldn't even compile. I also write in multiple languages, and for languages for which this is an issue I use a linter. This isn't even an issue in C if you compile everything with the appropriate flags (-Wall or -Wparentheses).

msluyter 11y ago

Re: "null != variable": I don't think it's necessarily confusing, it's just that usually we tend to think of the elements we're working with (variables, objects, functions, etc...) as taking on values, and so linguistically, we ask "is my thing null?" Not, "is nullness something that applies to my thing?" Hence "thing operation value" is arguably cognitively cheaper than "value operation thing." So you could argue that it's one of those things that increases cognitive load if you're not used to it. That last bit is important because almost anything no matter how convoluted can become acceptable once it becomes a convention. In java I used to wonder why people did this: if ("".equals(str)) {... rather than if (str.equals("")) {... until I got more familiar with NPEs. Now the former seems quite natural.

gknoy 11y ago
I think the point was, that as soon as you are aware that typos of "=" and "==" are common, and hard to catch mechanically, the _habit_ of using the (constant == myvar) pattern can suddenly be seen as having more value as a hedge against human error. I'd rather write it that way, and then later change it in code review to `(myvar == constant)`, than risk writing it as `(myvar = constant)` and have it sneak through. Granted unit tests might catch this, but perhaps the error is in the unit test. ;)
- vitd 11y ago
  For me the _habit_ of using (constant == mylar) is way harder to get used to than using "=" vs "==", which the compiler will warn me about if I mess it up.
- kilink 11y ago
  Java if statements only allow boolean expressions, so the thing that the Yoda condition is supposed to protect against isn't even possible. I think this is precisely what the author is talking about, as this style is a totally unnecessary holdover from C.
- MereInterest 11y ago
  I would disagree that they are hard to catch mechanically. GCC will warn about it with -Wparentheses, which is included in -Wall.

matthewtoast 11y ago

I agree that big, deep stuff like architecture and abstractions can be daunting, but I wouldn't be quick to dismiss style and formatting as mere nitpicks. Code clutter can have an outsize effect downwind of those who create it. A codebase is like a home. We all have to live in it. Architecture and abstractions are like the furniture and appliances. Code formatting and syntax are the nicknacks, paper bills, decorations, cat toys, board games etc. Does the toaster really belong on top of that highly flammable mattress? This is a big, deep question about the overall functioning of the home. But throw a pile of ratty blankets on top, put some boxes of moldy half-eaten pizza around the floor, and maybe wind that kite string over the doorknob and around the teetering bookcase. Can you still see the toaster? How do you plan to get in there to move it to a proper place? Small issues can block, conceal, misrepresent, and make big issues even more dangerous. Which why I say: fix all the small things first and stop new clutter from appearing (lint your code), then talk about rearranging the furniture.

norswap 11y ago
Oh yes, I agree. But it's a shame it's all people ever talk about, when there's this much bigger thing that looms beneath the surface.

jauco 11y ago

Slightly harder to understand, it is. But incomprehensible, it is not.

JustSomeNobody 11y ago

"null != variable" will confuse people is downright silly. People confused by this won't have an inkling of what any non-hello-world program does. I feel this is one of those things someone new might get confused about the first time they read it. After that, no. IOW, understanding this is part of learning and once it is learned, it is OK.

pyrextamer 11y ago

What if the order depended on the check condition? `if (null == variable) or if (false == variable)` reads well that you are checking for null/false. `if (variable != null) or if (variable != false)` reads well that you want non-null/false conditions.

lostcolony 11y ago

I think you're reading too much into 'confusing'. It won't leave someone without understanding; it -may- cause them to momentarily pause, going "WTF?...uh...probably does ~this~. But why would someone do things this way?" That's still delaying them, that's still distracting them, that's still putting up an obstacle. Not one a future maintainer can't overcome, but -why do it-? That's the point.

the_af 11y ago
It seems like a reading micro-optimization to me, though. Surely most of the delays in understanding code lie in things other than "Yoda" conditionals. I'm going to guess complexity elsewhere in the code (even conceptual difficulties, such as "what is the purpose of this at all?") dwarf minor details like how one writes conditionals. If so, what is the point of this piece of advice?
- mreiland 11y ago
  > It seems like a reading micro-optimization to me, though. It's a "reading micro-optimization" in the same way that not littering your code with comments is a "reading micro-optimization". It makes you pause and interrupts your flow of thought as you contemplate something not directly related to what you were modeling in your head 2 seconds ago.
  - the_af 11y ago
    I don't think it's the same. I'm not arguing against code cleanliness or good practices. Code readability matters. I favor concise, expressive languages over verbose ones for precisely this reason. Littering your code with comments IS a huge readability problem. You are forced to filter them out to find the real code, since they are mostly garbage, but you can never be sure you aren't skipping some vital bit of information. Likewise, boilerplate and needless ceremony obscure the intent of the code, so they are obstacles to be reduced in good, clean code. Contrast this with writing Yoda conditions. They are no big deal. They interrupt your flow of thought exactly once: the first time you encounter them. If your train of thought is interrupted every time you encounter them, you are way too novice a programmer. So I think this is a really minor issue in the sea of software complexity; so minor, in fact, that it seems bizarre to me to mention it. I think whether to use Yoda conditions, much like the placement of braces or the number of whitespaces for indentation, are the stuff of flamewars and endless argument because they are the kind of things we programmers love to obsess about, but they are really not very important.

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

collyw 11y ago

I completely agree. While the small things do make things easier or more difficult, the architecture can make an order of magnitude more difference. The last two applications I have inherited are horrendously over complex and they are performing relatively simple tasks. Far too many joins done at the application level. The front page of the current application I am working on makes over 1000 calls to the database. I don't think it needs more than one for the main part. (And if the logic is really so complex that it can't be done in the database, that's a sign that the database schema probably needs updated.)

jernfrost 11y ago

Yeah that struck me as an exceptionally minor thing to care about. Seriously we got way bigger problems than this in most code: reams of code duplication, 10 classes deep inheritance hierarchies, monster classes, 2 pages long methods. In fact one of the most counterproductive things I have seen at work is people arguing at length about tiny details in the code standard and wasting hours work and goodwill. My take on this is, you give people advice on why a code standard is good to follow. But if they insist on tiny little quirk, let it be. It is not worth fighting over. The whole development community is full of people with all sort of little quirks. At the end of the day we got to get stuff done, and you have to weigh the benefits of stepping on somebody's toes against what you gain from it.

norswap 11y ago

Replying to myself, to say that it is interesting how must people replied to this to comment about the "null != variable" thing. Kinda makes my point. I suppose it could be explained by the fact that it's much easier to say something about the intuition of "null != variable" than to share some architectural insight.