4 ms·
The obvious question a newcomer would have to that particular code is "Can't a color be bright and light at the same time? Why?". Those things are better expla
by xorcist 11y ago
The obvious question a newcomer would have to that particular code is "Can't a color be bright and light at the same time? Why?".
Those things are better explained in a comment, I'd think.
Comments are needed, but should not explain what the code does (as in "add 1 to n") and instead exaplin why it does it (as in "fn expects indices to start from 1").
- coldtea 11y ago>The obvious question a newcomer would have to that particular code is "Can't a color be bright and light at the same time? Why?". It can and the code in question will print both "bright" and "light" if passed a color that matches that. Where did you see that it's an either-or affair in the example? Besides, the key point, is that the code talks about luminocity and brightness levels, and the second example makes that explicit. No comments needed if you know what HSV is. And if you don't, comments are usually not the place to learn about it.
- berdario 11y agoif color.saturation > .5: print("bright!") elif color.luminosity > .5: print("light!") it's an `elif`... it will never print both "bright" and "light" This kind of mistake really detracts from the point that was argued here about code being "intelligible"
- jmartinpetersen 11y agoIn the presentation it was two if's, not an if and an elif. Someone up-thread misrepresented it. I didn't read it carefully here, as I had already seen the presentation and it wasn't until your disagreement I realized the code was different.
- berdario 11y agoYup... my comment about "detracting from the point" was about such an important semantic change to slip through unnoticed. (not about the points delivered in the talk itself or anything) There's nothing wrong with if/elses, but I strongly prefer pattern matching, where available. And even more, I think it's important to keep computation and presentation separate... that is, to not entagle IO with the rest of the code. (Unfortunately Haskell is the only language I know of that gives you a tool to tackle that) Obviously this was just a small example, but I've seen unintended IO byte back the developer in real world (Python) code. And another small comment: since I haven't bothered to comment on Hettinger's talk before now. I liked it (but played it back at 1.5x)... but since it's not first talk by Raymond Hettinger I saw, I knew that his delivery is good. Some of the stuff (should?) be obvious to every (Python) developer (but repetita juvant). I didn't like the jab at Java for the mistake of iterating over indexes: there's no excuse to writing that code not even there (look at the Iterator and Iterable interfaces)
- coldtea 11y agoThat's not his code.
- isp 11y agoIn Python, "elif" means "else if". At most one of "bright!" or "light!" will print. $ python >>> if True: ... print "First" ... elif True: ... print "Second" ... First >>>
- coldtea 11y agoI know what elif means in Python (been doing it since 1998 -- remember Zope?). That's not the code in his example. Here's that code: https://youtu.be/wf-BqAjZb8M?t=40m41s https://youtu.be/wf-BqAjZb8M?t=40m41s
- isp 11y agoApologies - I think we've been talking at cross purposes. I was referring to the code up-thread in https://news.ycombinator.com/item?id=10025412 https://news.ycombinator.com/item?id=10025412 , which (unlike the presentation) uses "elif".
- coldtea 11y ago>Apologies - I think we've been talking at cross purposes. Yeah, didn't pay close attention to it, thought it was the same as the one I saw in the presentation.
- azeirah 11y agoYeah sorry, that was my mistake in copying from the video. It was supposed to be an if statement. I'll leave it now because of the discussion on the issue