5 ms·

> I'm guessing that you two are having a communication problem as it is highly unlikely that a "senior colleague" can't understand simple logic. I've seen code

by LandR 8y ago

> I'm guessing that you two are having a communication problem as it is highly unlikely that a "senior colleague" can't understand simple logic. I've seen code written by a senior developer who writes if some-predicate // left blank. else // do something end if Because it's apparently too hard to work out how to invert logic. It's a pattern I've seen in our code base enough that I've started calling it 'if-meh-else'

dsego 8y ago
That could be for readability or some weird convention to make the code more streamlined? I've also seen it done that way so there could be a reason behind it.
- Insanity 8y ago
  something I can think of is that at first the if-branch did do something, then later it got commented out. And later again someone deleted the commented-out code instead of rewriting it. That'd be something pretty silly to do. But sadly I've seen enough bad code that this would not surprise me.
jcims 8y ago
Do you really think they don't know how to do one of the most basic logical operations in all of computing? It could be a convention to maintain semantic consistency in the predicate so you don't have to randomly flip your brain each time you encounter a new conditional statement. Ask around. Could at least be a funny story behind it. The great not not of 2014.
jinglebells 8y ago
I've written logic like to draw attention to the fact that the ELSE block is the exception. Semantically you're not saying "if X is true" you're saying "if X doesn't happen". It's a subtle difference and this format draws attention to it for the Next Developer.
- C1sc0cat 8y ago
  That how I would read it too.
csixty4 8y ago
Often when I use this, it's to make it explicit that the normal/common case is met and the other clause is truly exceptional. It's also a stub where you can add logging or similar along the normal path without touching the conditional and risking introducing bugs by accident. Depending on the language or runtime the empty clause will likely be factored out by the optimizer so there's no cost for extra readability and flexibility.
- eps 8y ago
  Precisely. This construct is used to indicate likely vs unlikely branches in code. It's a pretty common pattern.
profalseidol 8y ago
Personally, for readability purpose, this sounds a like a good idea. It is indeed (at least for me) harder to read a condition that has negation: if(!some-predicate) Maybe it's because you have to do the negation mentally. But more ideally, it should be done with polymorphism or similar rather than using if..else.
manigandham 8y ago
> Because it's apparently too hard to work out how to invert logic. This is almost never the case. Please don't assume people don't know what they're doing, especially to such an extent. I would actually recommend attributing expertise and wisdom to their decisions until proven otherwise. This particular construct is not a lack of understanding but often used to improve readability, transition code that may be in that block in the past or future, denote the normal vs exception branch, and several other scenarios. Did you ever ask why this person wrote it this way?
p2t2p 8y ago
I don't know if you have read Code Complete. They kinda explain there why such a code would make sense. I've written constructs resembling this many times and got them through rigorous PRs with quite experienced and senior people. One must remember that code is not a paint and a canvas for you to feel like an artist but a documentation for for Next Developer to comprehend. One must write it like a book or some sort of navigation manual, drawing attention of the reader to the important parts and guiding them through intricacies of the requirements and logic.
- jerf 8y ago
  When I have an if clause that is too complicated to work out how to correctly invert it (because while I understand de Morgan's just fine, it can get very detailed), I find it far preferable to start factoring out the expression, e.g. if I need to invert, if ((a and b) or (a and c and not d)) and not e) should be something more like orderSubmitted = a and b orderValid = a and c and not d orderNotYetFulfilled = (orderSubmitted or orderValid) and not e if not orderNotYetFulfilled { # code here } Ideally, a through e are also named something reasonable enough that the variable declarations read cleanly. The raw de Morgan's transform is only necessary if it's a performance optimization, and in 2019 the conditions for that to be an issue are very, very precise.
  - rowanG077 8y ago
    I assume the compiler can easily optimize something like that similar to constant folding. Isn't that the case?
    - jerf 8y ago
      In most cases I'd expect so. The rare cases I was thinking of was on the order of "I'm on an embedded system using a crappy compiler and I can't change it and I literally can't afford extra bytes for boolean values the compiler won't optimize away", and on the other end, "I'm in the cloud and my code has confused the optimizer and I have to code this inner loop incredibly carefully because it's going to be called several billion times per second". Maybe the odd other corner case here or there. There shouldn't be much in-between in 2019 where writing the clauses out this way will have a materially negative impact on one's code, and it should have a generally very positive one.
KeenFox 8y ago
You already have ample examples of how this could make sense, so here's a mental model that will serve you well in life. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence >> 'In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."'
rightbyte 8y ago
Sometimes I do that when negating would be unintutive or more verbose with regards to the else and if else statement.
darepublic 8y ago
How about if(expression) foo = true else foo = false

by LandR 8y ago

dsego 8y ago

That could be for readability or some weird convention to make the code more streamlined? I've also seen it done that way so there could be a reason behind it.

Insanity 8y ago
something I can think of is that at first the if-branch did do something, then later it got commented out. And later again someone deleted the commented-out code instead of rewriting it. That'd be something pretty silly to do. But sadly I've seen enough bad code that this would not surprise me.

jcims 8y ago

Do you really think they don't know how to do one of the most basic logical operations in all of computing? It could be a convention to maintain semantic consistency in the predicate so you don't have to randomly flip your brain each time you encounter a new conditional statement. Ask around. Could at least be a funny story behind it. The great not not of 2014.

jinglebells 8y ago

I've written logic like to draw attention to the fact that the ELSE block is the exception. Semantically you're not saying "if X is true" you're saying "if X doesn't happen". It's a subtle difference and this format draws attention to it for the Next Developer.

C1sc0cat 8y ago
That how I would read it too.

csixty4 8y ago

Often when I use this, it's to make it explicit that the normal/common case is met and the other clause is truly exceptional. It's also a stub where you can add logging or similar along the normal path without touching the conditional and risking introducing bugs by accident. Depending on the language or runtime the empty clause will likely be factored out by the optimizer so there's no cost for extra readability and flexibility.

eps 8y ago
Precisely. This construct is used to indicate likely vs unlikely branches in code. It's a pretty common pattern.

profalseidol 8y ago

Personally, for readability purpose, this sounds a like a good idea. It is indeed (at least for me) harder to read a condition that has negation: if(!some-predicate) Maybe it's because you have to do the negation mentally. But more ideally, it should be done with polymorphism or similar rather than using if..else.

manigandham 8y ago

> Because it's apparently too hard to work out how to invert logic. This is almost never the case. Please don't assume people don't know what they're doing, especially to such an extent. I would actually recommend attributing expertise and wisdom to their decisions until proven otherwise. This particular construct is not a lack of understanding but often used to improve readability, transition code that may be in that block in the past or future, denote the normal vs exception branch, and several other scenarios. Did you ever ask why this person wrote it this way?

p2t2p 8y ago

I don't know if you have read Code Complete. They kinda explain there why such a code would make sense. I've written constructs resembling this many times and got them through rigorous PRs with quite experienced and senior people. One must remember that code is not a paint and a canvas for you to feel like an artist but a documentation for for Next Developer to comprehend. One must write it like a book or some sort of navigation manual, drawing attention of the reader to the important parts and guiding them through intricacies of the requirements and logic.

jerf 8y ago
When I have an if clause that is too complicated to work out how to correctly invert it (because while I understand de Morgan's just fine, it can get very detailed), I find it far preferable to start factoring out the expression, e.g. if I need to invert, if ((a and b) or (a and c and not d)) and not e) should be something more like orderSubmitted = a and b orderValid = a and c and not d orderNotYetFulfilled = (orderSubmitted or orderValid) and not e if not orderNotYetFulfilled { # code here } Ideally, a through e are also named something reasonable enough that the variable declarations read cleanly. The raw de Morgan's transform is only necessary if it's a performance optimization, and in 2019 the conditions for that to be an issue are very, very precise.
- rowanG077 8y ago
  I assume the compiler can easily optimize something like that similar to constant folding. Isn't that the case?
  - jerf 8y ago
    In most cases I'd expect so. The rare cases I was thinking of was on the order of "I'm on an embedded system using a crappy compiler and I can't change it and I literally can't afford extra bytes for boolean values the compiler won't optimize away", and on the other end, "I'm in the cloud and my code has confused the optimizer and I have to code this inner loop incredibly carefully because it's going to be called several billion times per second". Maybe the odd other corner case here or there. There shouldn't be much in-between in 2019 where writing the clauses out this way will have a materially negative impact on one's code, and it should have a generally very positive one.

KeenFox 8y ago

You already have ample examples of how this could make sense, so here's a mental model that will serve you well in life. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence >> 'In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."'

rightbyte 8y ago

Sometimes I do that when negating would be unintutive or more verbose with regards to the else and if else statement.

darepublic 8y ago

How about if(expression) foo = true else foo = false