Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: comp.lang.javascript Subject: Re: Understanding && Date: Sun, 18 Apr 2021 23:59:28 +0100 Organization: A noiseless patient Spider Lines: 87 Message-ID: <87mttv42sv.fsf@bsb.me.uk> References: <87wnt2e06e.fsf@bsb.me.uk> <87mttydm95.fsf@bsb.me.uk> <87o8edd8qk.fsf@bsb.me.uk> <87zgxwa5sg.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="d80a767a035369f2ba4fbb5c271696c3"; logging-data="25532"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/WaiLGPqn1DpeulIS02GWJoG2iiINBa2A=" Cancel-Lock: sha1:Ms8Y8X4LxUP1IxwAcSIW29tHI+4= sha1:Ffg1+JtXobsBXIlr1ibAhYmeJFo= X-BSB-Auth: 1.37f4afac538ed577217f.20210418235928BST.87mttv42sv.fsf@bsb.me.uk Xref: csiph.com comp.lang.javascript:39980 Jon Ribbens writes: > On 2021-04-17, Ben Bacarisse wrote: >> Jon Ribbens writes: >>> I don't mean as a rule that's written down, I mean as in 99% of >>> programmers do not write code that looks like this. I don't consciously >>> have it as a "rule" either except inasmuch as it is a consequence of >>> "readability matters". >> >> I read too much into some very strong words. > > I did say "abuse", which can be a very strong word in some contexts but > isn't really in when talking about software programming. You introduced > the word "rule". Oh, please! I /asked/ if it was a rule as far you were concerned, so, yes, I typed the word first, but your reply was to claim it was an almost universal rule. That's the strong language! >> Your view is much more moderate than I thought it was from some of the >> words used, but I did get that you were making balanced judgement. When >> I said I don't have a problem with the readability I was suggesting that >> nothing is last so there is no need for any balancing gain, but I think >> you see readability through the eyes of the least skilled reader who >> might have to look at the code. I find that hard. How low should one >> go... > > It depends on the context I suppose. Some companies hire expensive DBAs, > so that they can hire cheap programmers. Some companies don't. > > I would expect a moderately competent programmer to know immediately > what's going on with something like "a && (b = c)" but at the same time > it would require more intellectual effort expended (I think, for most > people) to verify its correctness than "if (a) b = c", Interesting. I would not have thought so, but I have no data. Code verification seems to be a lost art these days so my main reaction is delight that it's still considered important! > and the > complexity basically goes up exponentially the more branches you put > into the expression. Ack. I'm sure that this is true. > I use "JavaScript Standard Style", and so I must admit I am sometimes > tempted when I have something like: > > if (complex_expression) complex_conditional > > and it doesn't fit on one line, to use: > > complex_expression && > complex_conditional > > because the linter won't object to that, but it will object to: > > if (complex_expression) > complex_conditional > > but almost always I will end up using instead: > > if (complex_expression) { > complex_conditional > } > > because it is probably easier for others to read ("others" perhaps > including me a year later...) And by "easier" I don't mean incompetent > programmers can't understand it, I just mean it will take most people > slightly longer to understand / have a slightly higher percentage chance > of being misunderstood. That's another interesting perspective. When I look back on old code, it's never things like this that take any time at all. I often wish there were a large block comment explaining the algorithm or method being used, and sometimes I just wish for a comment explaining /why/ count is being set to i + j, but I never lose even a moment over /what/ the code is doing (in the sense of what the syntax means). Another attraction of '&&' is that it chains in a natural way whereas 'if' nests. Sometimes (as in the example of mine that you'd reject immediately) you can negate the tests and use early returns to avoid the nesting, but I don't like doiing either very much. There are studies that have shown that nesting is harder to follow that chaining. -- Ben.