Learn More
Resend Email
6
Liebranca
3d

So, I have a nested ternary, right, and that's not very readable:

(x <= y ? z : (x <= z ? y : x));

The linter points this out and I'm like yeah, valid point. So I inline-F[*0] it:

if (x <= y)
········return z;
else if (x <= z)
········return y;
else
········return x;

Clearer? Kinda. Oh, but the linter doesn't like this either, and to be fair, valid point once again; an else-after-return *can* be quite confusing if you have it in the __middle__ of the F body, catches you by suprise.

However, I'd like to take a brief moment to waggle your nutsack, if you please. Because this is C++ and I'm picking a reference from a list of values, so I can't simply assout[*1] within the switch.

So I'm at the crossroads of life once again, losing man's toughest struggle as I sit on a metaphorical cigar, squirming while I unclench my asshole slowly for strictly defecatory purposes. Allow me to illustrate:

- If I ignore the linter, and leave the rest of the code unchanged, the checks are going to fail and the bot is going to taint my pristine PR with automated comments.
- But if I take the linter's advice, I have to do a slight rewrite of the damn thing plus every F that calls it, which means touching shit that has nothing to do with this issue.

So what's it gonna be? Flushing or shoving my own excrement? Oh, the thrills of it being (literally) SOLID, ie not the acronym, but may the Almighty punish Uncle Bob regardless.

NOTES:
[*0]: It means 'function,' what else?
[*1]: ASS-ign OUT-put, where 'out' is just some var. You modify the var within the F body and return the final value.

rant

assout what out comes from the ass
Favorite
Ranter
Comments
  • 3
    3d
    That's high tide for a cheeky #pragma push(fuckyou) or #![alllow(fuck_you)] depending on your lang
  • 2
    2d
    I'm fairly sure that returning in an if-else-tree has some performance optimisations that can be applied that can't if you don't (e.g. tail call optimisation).

    I've never found if-return-else-return to be that difficult to read, and it's clearer to me that that is the intent and I can stop keeping those variables in memory. So I disagree with your linter
  • 7
    2d
    observe
  • 7
    2d
    you don't need else if you use return
  • 5
    2d
    I do exactly what @kiki does.

    But I'm totally fine with the ternary stuff. Only gets ugly when nested. But besides that it's very clear to me but not really in python tho. Hating ternary is just a thing people say because it's common or smth.

    Pony = x if a else b. I do "x or b". Had the same result, the first truthy get result.
  • 1
    2d
    @kiki Mother fucker, that's brilliant. Plusplus for everybody!
  • 4
    2d
    @retoor python's ternary is a nice but failed attempt at making code more readable.

    Mess around with established patterns you should not!
  • 0
    2d
    Didn't someone on here do it this way:

    x <= y ? z :

    x <= z ? y : x;

    Where each new ternary line is an implied else if.
  • 4
    2d
    @Demolishun nested if else is still much more readable :)

    And modern languages have "if else" as expressions rather than statements, just like with the ternary.
  • 4
    2d
    If you're going for readability, I like doing this:

    const condOne = x <= y;
    const condTwo = x <= z;

    if(condOne)
    return z;
    if(condTwo)
    return y;

    return x;

    This doesn't really apply well if the conditions above are only short binary like "x <= y", but they give you the ability to properly label and thus document the conditions by giving them proper names, such as "shouldExecSomething".
  • 2
    2d
    @Ranchonyx this is my favorite and a great example of self documenting code!
  • 1
    2d
    @Lensflare Thank you :)

    And yeah, that's why I do it as well.

    I've found I'm not that good at writing extensive code comments everywhere, and properly naming my variables really helps with the readability.

    I try avoiding ternary expressions unless it's absolutely trivial to comprehend.

    It's nice.
  • 2
    2d
    @Ranchonyx imo, you should avoid code comments.
    Whenever something needs clarification, it can almost always be done by proper naming and structuring.

    Introducing properly named variables for intermediate results is only one of the things that you can do. There are many others.

    Writing comments just introduces a second copy of your code which you will forget to update and sync when the code changes (and that’s assuming that it was initially correct, which is not aways the case)
  • 4
    2d
    @Lensflare in my opinion, both are needed. The code itself explains what happens, the comments explain WHY it happens. But the "second copy" antipattern you described is most certainly harmful.
  • 2
    2d
    @kiki I’d argue that the 'why' often can also be explained by proper naming.
    Also, I believe that for most of code, the 'why' is obvious.
    I agree that there are cases where a code comment is a perfect fit to explain the 'why', but it should really be seen as an exception.
  • 0
    2d
    @Ranchonyx If you have a large conditional, you should probably turn it into a function, but don't make have to memorize your expression 10 lines up, that uses 3 derived variables that now has 5 different expressions in between that is only used once because now I need to manually keep track of your dependencies and makes it harder to update
  • 2
    2d
    Aw shit, here we go again with the anti-commenting kink.

    If code can be self explanatory then why do man pages exist? Who needs docs, just go read the implementation!

    You kids have lost the fucking plot. At some point you have to communicate with *human* language to make the computerspeak abstraction easier to understand, and that's just that.
  • 2
    2d
    @Liebranca I think only inline comments are under attack here. If it's above the code, you can read the code yourself indeed. But comments became more important than ever! Now AI can learn from it :P
  • 1
    2d
    @retoor AI or not, stating the __intent__ of a block is, let's say "kind of", the best way to **EHEM** make the __intent__ of that block clear. Who would've thought?
  • 1
    1d
    @Liebranca And then it turns out that isn't exactly what the code does ;P, but I find the developers' intent to be equally important to understand the whole setup rather than the individual function - almost like it should be in some kind of manual or readme outside the code ;P (I'm mainly teasing, but comments can be good, but have the explanation be the code is better in my book)
  • 1
    17h
    @BordedDev A perfectly written block of text can appear to do something it isn't if you miss the tiniest, most miniscule of details. The reality is that comments themselves are part of the code, and you have to treat them as such.

    Furthermore, if we are arguing from the point of view of an ideal world: this discussion wouldn't even exist, yet the main reason any of us has a halfway decent salary to begin with is most production code is an unreadable piece of shit that no one wants to touch, so I rest my case.
  • 1
    7h
    @Liebranca From my experience upgrading "old" apps, I've found it's almost never worth trusting the comments - but worth reading them, since they often say something should do X but in reality it does X by doing Y and the issue is in the side effect Y.

    I'm not really arguing against adding them, I'm arguing against trusting them as a developer using someone else's code
  • 1
    3h
    @BordedDev Mmmh... well, when narrowing down where an issue is located, no block should be trusted until proven innocent, comments or no comments.
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment