4 ms·
Because there's a threshold of where you know how things will be parsed. You wouldn't write: a=(b+c) Because you know it's not necessary. But we're human a
by viraptor 3y ago
Because there's a threshold of where you know how things will be parsed. You wouldn't write:
a=(b+c)
Because you know it's not necessary. But we're human and sometimes make mistakes when we're sure we didn't.
That's also why we allow for some misunderstanding, (rather than (writing (using) (sentence trees))).
- kmoser 3y agoAgreed, that would be one level too far, and thus unnecessary. I'm not arguing that every operator should be parenthesized, but I think parens should be used more than most programmers tend to do. On a related note, I occasionally write expressions that both assign and test, e.g. if ( ( a = b ) == c ) and in those cases I parenthesize liberally and always write a comment that indicates yes, I intend to make an assignment in the middle of a test for equality.
- demondemidi 3y agoOof really? That’s a horrible pattern! In my professional opinion of course. Separation of causes, man! :)
- porridgeraisin 3y agoIt's very common in C while((buf = resultofstreamingoperation() != null) { } The ` != null ` is redundant here but you can imagine where it'd be required.
- sweetjuly 3y agoA more common form (and slightly less evil) is for error checking: if ((error = do_a_thing())) { // some error happened, good thing we saved the error code } Given the standard "zero is success" paradigm, handling errors is very succinct.
- demondemidi 3y agoYou are arguing "common" == "good". That's not true.
- kmoser 3y agoYeah, but separation of causes then violates the DRY principle because you have to repeat the 'a' expression twice: a = b if ( a == c ) ... The repetition is even worse if you replace 'a' or 'b' with a more complex expression: a[foo/bar] = b[baz/bat] if (a[foo/bar] == c) ... Oof indeed! Just rewrite it as: if ( ( a[foo/bar] = b[baz/bat] ) == c ) ... // Yes, assign and test!
- iamflimflam1 3y agoWow - I’ve been coding for a long time and find your assign and test really hard to parse. In a code review I would definitely reject this.
- kmoser 3y agoJust curious, do you also find the ternary operator hard to parse? This is a serious question: I've found some programmers tend to avoid it entirely, while I think there are some clear cases where it's advantageous to use. What I'm getting at is one person's "easy to parse" is another person's "difficult to parse", and there may be no objective answer which makes one any better than the other.
- iamflimflam1 3y agoTo be honest I think it really depends. And in some contexts it is unavoidable. I would think to myself if I was writing one “have I made a mistake somewhere that means I have to use this?” I don’t think it’s necessarily about “can I parse this”, it’s much more about will all the devs on the team be able to parse this. To me, code is all about communication - to myself, but also to an audience I haven’t met with varying skill, knowledge and context levels. I’ve been bitten too many times with code that only one or two people can work on.
- nickthesick 3y agoI hope this is satire, DRY is more about extraction of shared function not about individual expressions. You write code once, no need to save yourself typing time at the expense of you and other peoples ability to read and understand the code afterward.
- jug 3y agoAlso it’s easy to make assumptions and have them slip by when more experienced. Like how the ?? operator works in C# or even just the bitshift or logical operator order which is pretty much standardized across languages by now. But still, this can confuse readers or even yourself on a tired day.