On 21/04/18 11:18, Chris Angelico wrote: >> But you haven't answered anything about what "readable" means. Does it >> mean "if I look at this code, I can predict what dis.dis() would >> output"? Or does it mean "this code clearly expresses an algorithm and >> the programmer's intent"? Frequently I hear people complain that >> something is unreadable because it fails the former check. I'm much >> more interested in the latter check. For instance, this line of code >> expresses the concept "generate the squares of odd numbers": >> >> [x*x for x in range(100) if x % 2] >> >> But it doesn't clearly express the disassembly. Is that a problem? Are >> list comprehensions a bad feature for that reason? I don't think so. >> >> ChrisA For what it worth - readability for me is all about understanding the intent. I don't care (most of the time) about how the particular code construct is actually implemented. When I am maintaining code (or trying to) I need to understand what the developer intended (or in the case of a bug, the gap between the outcome and the intention). One of the challenges about readability is it partially depends on skill level - for a beginner the comprehension may well be baffling where as someone with more skills would understand it - almost intuitively; as an example: I have been using Python for 7 years - and comprehensions with more than one for loop still are not intuitive for me, I can't read them without an amount of deep thought about how the loops work together. -- -- Anthony Flury email : *Anthony.flury at btinternet.com* Twitter : *@TonyFlury <https://twitter.com/TonyFlury/>*
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4