5 ms·

I think I might be in the minority here that I prefer the fully laid out statements. Sure in small cases this small ternary use is great! However too many time

by jackdh 5y ago

I think I might be in the minority here that I prefer the fully laid out statements. Sure in small cases this small ternary use is great! However too many times I've seen people chain them for far too many characters just to be "on one line". We don't use one letter variable names anymore, so in the same reasoning why should we do the same to our code?

Cthulhu_ 5y ago
Yup; the booleans are difficult enough from a logic point of view, don't need to make it more complicated by using syntactic sugar. I strongly disagree with the author's idea that shorter is better. Clarity trumps conciseness. I'll admit that not enough conciseness can impact clarity, but there's ways and means to clean that up that don't involve clever code.
- chriswarbo 5y ago
  I hypothesise that the actual meaning (possibly subconscious) underlying those uses of "complicated", "syntactic sugar", and "clever code" is 'not the way I'd write it'; and that "clarity" and "clean" actually mean 'the way I would write it'. To test whether those statements are guiding principles, or merely ad-hoc justifications, I propose the following pylint rules based on those principles: no-ternary-sugar: Replace 'x if y else z' with '{True: lambda: x, False: lambda: z}[y]()'. This is less concise, but improves clarity by using booleans explicitly, and making the delayed evaluation of the results clear; both of which are implicit in the 'if/else' syntactic sugar. no-elif-sugar: Replace: if foo: bar elif baz: quux ... else: foobar With: if foo: bar else: if baz: quux else: ... else: foobar This is less concise, but makes the branching structure clear, unlike the misleading "flat" appearance of the 'elif' syntactic sugar. no-special-case-patterns: Replace: if foo: bar else: baz With: match foo: case True: bar case False: baz 'if/else' is syntactic sugar for pattern-matching a boolean, which is left implicit. Explicit matching improves consistency with other use-cases, and makes the relationship between branches and boolean clear, at the expense of conciseness. (Also applies to single-armed 'if', which will only have a 'case True:'). Of course, the combination of no-elif-sugar and no-special-case-patterns would give extreme clarity like this: match foo: case True: bar case False: match baz: case True: quux case False: ... case False: foobar
sumtechguy 5y ago
I personally would have wrote the first one as a first pass, mostly so I could probably at some point put break points on what is going on. Then probably called it 'done'. I had actually forgot you could even do this thing in python. The highest complement I get from other programmers is 'your code is easy to read'. Everyone has their own 'style' they like. It is usually not that big of a deal. It becomes a big deal if you get someone on the team who becomes obsessed with it, or someone who is always sloppy. Compact styles tend to be harder to decipher than simple ones. As when you are reading them they usually are not the same style context as all the other code around it. So it causes your brain to have to stop and figure it out. With python sometimes those compact styles actually run faster, so they can be handy to know about (test it though). In java there is this thing where many will do things like blah = x().y().z(); Yet at any point in that chain something could crash out and return a null. It is compact for sure. But really is a pain to debug, but easy to read. Yet a lot of what is going on is burred in the 'middle' what if something in the middle is returning the wrong thing and the next thing in the chain happens to have the right method? Compact styles can be easy to read sometimes if you know what that style is. You can also very easily introduce very subtle bugs. You can also convey the wrong meaning to the next poor soul that has to look at your code 3 years from now, 2 years after you left the company. I use this style as sparingly as possible and fall towards verbose and spaced out code. I try to make it easy to read and broken down as best as possible. 6 months from now my tired brain will thank me. For something like this example if I ended up with an if tree like that I would look at the underlying data structures. There is a data problem here and there probably would be a better way to do it.
- chriswarbo 5y ago
  I get the sentiment, but I think it's a fundamental error to equate "verbose" with "clear"/"simple"/"readable"/etc. and "compact" with "clever"/"fast"/"difficult"/etc. I see this so often that I wrote a blog post about it http://chriswarbo.net/blog/2020-02-08-clever_code.html http://chriswarbo.net/blog/2020-02-08-clever_code.html tl;dr trying to make things smaller isn't "clever", it's code golf; often, "clever" solutions just-so-happen to end up small. Likewise, spreading logic over many lines can lose abstraction; we can end up lost in a tangle of bools, ints, etc. without seeing the bigger picture.
ItsMonkk 5y ago
An ideal that you want to try to attempt to work through is the Principle of Least Power[0]. While is strictly more powerful than for, for is strictly more powerful than foreach, foreach is strictly more powerful than map. And yet 95% of the time, the power in map is sufficient. Therefore 95% of the time you should use map. When you encounter a foreach, you should be expecting non-purity. When you encounter a while, you know that it's doing some recursive operation that requires that power. If you have junior members of the team writing while loops where maps would do the senior members of the team who understand the nuance will take 10x more time to understand that code. The same applies to statements/code blocks vs expressions. If all you are doing is assigning one value and have no other side effects, and you can do so in a way that's not overly nested, you should use an expression. If you can't, we have the more powerful statement/block structure to fall back on. [0]: https://blog.codinghorror.com/the-principle-of-least-power/ https://blog.codinghorror.com/the-principle-of-least-power/
- jackdh 5y ago
  Thank you for that link. I'd not seen it before but after reading the W3 article on it I wholeheartedly agree with it! It was interesting to find out how HTML was designed from the start to be simple and not a programming language on purpose for this reason!

by jackdh 5y ago

Cthulhu_ 5y ago

Yup; the booleans are difficult enough from a logic point of view, don't need to make it more complicated by using syntactic sugar. I strongly disagree with the author's idea that shorter is better. Clarity trumps conciseness. I'll admit that not enough conciseness can impact clarity, but there's ways and means to clean that up that don't involve clever code.

chriswarbo 5y ago
I hypothesise that the actual meaning (possibly subconscious) underlying those uses of "complicated", "syntactic sugar", and "clever code" is 'not the way I'd write it'; and that "clarity" and "clean" actually mean 'the way I would write it'. To test whether those statements are guiding principles, or merely ad-hoc justifications, I propose the following pylint rules based on those principles: no-ternary-sugar: Replace 'x if y else z' with '{True: lambda: x, False: lambda: z}[y]()'. This is less concise, but improves clarity by using booleans explicitly, and making the delayed evaluation of the results clear; both of which are implicit in the 'if/else' syntactic sugar. no-elif-sugar: Replace: if foo: bar elif baz: quux ... else: foobar With: if foo: bar else: if baz: quux else: ... else: foobar This is less concise, but makes the branching structure clear, unlike the misleading "flat" appearance of the 'elif' syntactic sugar. no-special-case-patterns: Replace: if foo: bar else: baz With: match foo: case True: bar case False: baz 'if/else' is syntactic sugar for pattern-matching a boolean, which is left implicit. Explicit matching improves consistency with other use-cases, and makes the relationship between branches and boolean clear, at the expense of conciseness. (Also applies to single-armed 'if', which will only have a 'case True:'). Of course, the combination of no-elif-sugar and no-special-case-patterns would give extreme clarity like this: match foo: case True: bar case False: match baz: case True: quux case False: ... case False: foobar

sumtechguy 5y ago

I personally would have wrote the first one as a first pass, mostly so I could probably at some point put break points on what is going on. Then probably called it 'done'. I had actually forgot you could even do this thing in python. The highest complement I get from other programmers is 'your code is easy to read'. Everyone has their own 'style' they like. It is usually not that big of a deal. It becomes a big deal if you get someone on the team who becomes obsessed with it, or someone who is always sloppy. Compact styles tend to be harder to decipher than simple ones. As when you are reading them they usually are not the same style context as all the other code around it. So it causes your brain to have to stop and figure it out. With python sometimes those compact styles actually run faster, so they can be handy to know about (test it though). In java there is this thing where many will do things like blah = x().y().z(); Yet at any point in that chain something could crash out and return a null. It is compact for sure. But really is a pain to debug, but easy to read. Yet a lot of what is going on is burred in the 'middle' what if something in the middle is returning the wrong thing and the next thing in the chain happens to have the right method? Compact styles can be easy to read sometimes if you know what that style is. You can also very easily introduce very subtle bugs. You can also convey the wrong meaning to the next poor soul that has to look at your code 3 years from now, 2 years after you left the company. I use this style as sparingly as possible and fall towards verbose and spaced out code. I try to make it easy to read and broken down as best as possible. 6 months from now my tired brain will thank me. For something like this example if I ended up with an if tree like that I would look at the underlying data structures. There is a data problem here and there probably would be a better way to do it.

chriswarbo 5y ago
I get the sentiment, but I think it's a fundamental error to equate "verbose" with "clear"/"simple"/"readable"/etc. and "compact" with "clever"/"fast"/"difficult"/etc. I see this so often that I wrote a blog post about it http://chriswarbo.net/blog/2020-02-08-clever_code.html http://chriswarbo.net/blog/2020-02-08-clever_code.html tl;dr trying to make things smaller isn't "clever", it's code golf; often, "clever" solutions just-so-happen to end up small. Likewise, spreading logic over many lines can lose abstraction; we can end up lost in a tangle of bools, ints, etc. without seeing the bigger picture.

ItsMonkk 5y ago

An ideal that you want to try to attempt to work through is the Principle of Least Power[0]. While is strictly more powerful than for, for is strictly more powerful than foreach, foreach is strictly more powerful than map. And yet 95% of the time, the power in map is sufficient. Therefore 95% of the time you should use map. When you encounter a foreach, you should be expecting non-purity. When you encounter a while, you know that it's doing some recursive operation that requires that power. If you have junior members of the team writing while loops where maps would do the senior members of the team who understand the nuance will take 10x more time to understand that code. The same applies to statements/code blocks vs expressions. If all you are doing is assigning one value and have no other side effects, and you can do so in a way that's not overly nested, you should use an expression. If you can't, we have the more powerful statement/block structure to fall back on. [0]: https://blog.codinghorror.com/the-principle-of-least-power/ https://blog.codinghorror.com/the-principle-of-least-power/

jackdh 5y ago
Thank you for that link. I'd not seen it before but after reading the W3 article on it I wholeheartedly agree with it! It was interesting to find out how HTML was designed from the start to be simple and not a programming language on purpose for this reason!