4 ms·

What?.could?.possibly?.go?.wrong?.

• esafak 1y ago
  if (This) { if (is) { if (much) { if (better) { println("I get paid by the brace") } } } }
  • muti 1y ago
    if (!same) { return; } if (!number) { return; } if (!of_braces) { return; } println("but easier to read")
    • esafak 1y ago
      Yes, you should definitely unnest functions and exit early. But the null-coalesced version is shorter still.
  • kazinator 1y ago
    False dichotomy. The problem is that the syntax implements a solution that is likely wrong in many situations and pairs with a bad program design. Maybe when we have this: what?.could?.possibly.go?.wrong = important_value() Maybe we want code like this: if (!what) what = new typeof(what); // default-construct representative instance if (!what.could) what.could = new typeof(what.could); if (!what.could.possibly.go) what.could.possibly.go = new typeof(what.could.posssibly.go) // now assignment can take place and actually retain the stored value // since we may have allocated what, we have to be sure // we propagate it out of here. what.could.possibly.go.wrong = important_value(); and not code which throws away the value (and possibly its calculation). Why would you ever write an assignment, but not expect that it "sticks"? Assignments are pretty important. What if someone doesn't notice the question marks and proceeds to read the rest of the code thinking that the assignment always takes effect? Is that still readable?
    • esafak 1y ago
      Just because you can't do assignments like that, it doesn't mean you shouldn't use null coalescing for reads. What exactly could go wrong?
      • arwhatever 1y ago
        Paranoid null checking of every property dereference everywhere (much?.like?.in ?.my?.joke) whether each is ever possibly null or not, usually combined with not thinking through what the code behavior should be for each null case. (Gets a lot better if you enable nullable references and upgrade the nullable reference warnings to errors.)
    • Quarrelsome 1y ago
      NullReferenceException, in line 7. you didn't null check possibly.go.
      • kazinator 1y ago
        Rather, what I didn't null check is "possibly". That's because it doesn't have a question mark in the original expression that I'm starting from.
    • Dylan16807 1y ago
      > Maybe we want code like this It should be clear enough that this operator isn't going to run 'new' on your behalf. For layers you want to leave missing, use "?.". For layers you want to construct, use "??=". > Why would you ever write an assignment, but not expect that it "sticks"? Assignments are pretty important. If you start with the assignment, then it's important and you want it to go somewhere. If you start with the variable, then if that variable doesn't have a home you don't need to assign it anything. So whether you want to skip it depends on the situation. > What if someone doesn't notice the question marks and proceeds to read the rest of the code thinking that the assignment always takes effect? Is that still readable? Do you have the same objection with the existing null-conditional operators? Looking at the operators is important and I don't think this makes the "I didn't notice that operator" problem worse in a significant way.
  • jayd16 1y ago
    if (Actually && Actually.you && Actually.you.would && Actually.you.would.write && Actually.you.would.write.it && Actually.you.would.write.it.like) { return this; }
    • esafak 1y ago
      Routinely dealing with that's enough to put you off programming altogether.
• kazinator 1y ago
  Nothing to worry about: What?.could?.possibly?.go?.wrong? Not so convinced: What?.could?.possibly?.go?.wrong = important_value() Maybe the design is wrong if the code is asked to store values into an incomplete skeleton, and it's just okay to discard them in that case.
  • huflungdung 1y ago
    [dead]