New Ways to Be Told That Your Python Code Is Bad • Hacker News Board

Re: New Ways to Be Told That Your Python Code Is Bad

#11

Post by makeitdouble » Fri, Sep 03, 2021, 1:25 AM UTC

SkipperCat wrote: post #5

Tools that enforce "expert level" coding standards do make code more concise, but also less comprehendible for the less experienced developers. I never saw the harm in four lines of code instead of one, especially when it's much more readable.

I am not a fan of the examples in the article, but for tools like rubocop in ruby, I am pretty glad it sometimes uses semi-obscure but more "correct" forms.

When I started learning ruby a bunch of the changes flew over my head, but it is also an excellent entry point to look further into best practices, and concrete examples of how my code could be better.

The condition is of course the tool being itself extremely good, otherwise it's just everyday hell (looking at you, phpstan...)

Re: New Ways to Be Told That Your Python Code Is Bad

#12

Post by juanci_to » Fri, Sep 03, 2021, 1:27 AM UTC

zootboy wrote: post #4

> less code is better than more code Not when it's at the cost of readability. The example "better" code fails my readability test horribly. I'd gladly take C's ternary operator over this monstrosity: > x = 4 if condition() else 5

Exactly. I prefer this a lot more to at least avoid using else:

  x = 5
  if condition():
      x = 4

Re: New Ways to Be Told That Your Python Code Is Bad

#13

Post by Spivak » Fri, Sep 03, 2021, 1:37 AM UTC

zootboy wrote: post #4

> less code is better than more code Not when it's at the cost of readability. The example "better" code fails my readability test horribly. I'd gladly take C's ternary operator over this monstrosity: > x = 4 if condition() else 5

I don’t think this criticism is valid for Python specifically where the most Pythonic expressions, generators of all forms, are read front to back like this.

    [ x.attr for x in list if x in someset]

There are languages where this kind of thing would be considered ugly and you’re supposed to use map/filter but in Python they’re the best practice. Every Python programmer is already trained to read expressions like this.

Re: New Ways to Be Told That Your Python Code Is Bad

#14

Post by throwaway81523 » Fri, Sep 03, 2021, 1:37 AM UTC

https://xkcd.com/1833/ has some good ones.

Re: New Ways to Be Told That Your Python Code Is Bad

#15

Post by 29athrowaway » Fri, Sep 03, 2021, 1:38 AM UTC

SkipperCat wrote: post #5

Tools that enforce "expert level" coding standards do make code more concise, but also less comprehendible for the less experienced developers. I never saw the harm in four lines of code instead of one, especially when it's much more readable.

Python is a sane language that you can master in a reasonable amount of time.

If you think expecting people to achieve Python mastery is unreasonable, wait until I tell you about language called C++.

Re: New Ways to Be Told That Your Python Code Is Bad

#16

Post by chriswarbo » Fri, Sep 03, 2021, 1:40 AM UTC

> Anyway, this is just a style thing. It doesn’t affect program correctness or structure in a meaningful way.

The nice thing about ternaries is that they're expressions, so they don't "infect" our code like statements (e.g. 'if'). For example:

    if xCond:
      x = x1
    else:
      x = x2
    if yCond:
      y = y1
    else:
      y = y2
    if zCond:
      z = z1
    else:
      z = z2
    foo(x, y, z)

This lint rule will tell us to do the following instead:

    x = x1 if xCond else x2
    y = y1 if yCond else y2
    z = z1 if zCond else z2
    foo(x, y, z)

Now that our branching is done with expressions rather than statements, we can actually in-line them, which seems much nicer (less chance to get them mixed up; no need to invent new names; no side-effects, e.g. accidentally overwriting an existing variable; etc.)

    foo(
      x1 if xCond else x2,
      y1 if yCond else y2,
      z1 if zCond else z2,
    )

If we really want the names, we could define them using the 'walrus operator':

    foo(
      x := (x1 if xCond else x2),
      y := (y1 if yCond else y2),
      z := (z1 if zCond else z2),
    )

Personally I would use separate 'x = ...' statements rather than :=, since we want to explicitly perform effects (binding names).

Re: New Ways to Be Told That Your Python Code Is Bad

#17

Post by jimmaswell » Fri, Sep 03, 2021, 1:40 AM UTC

I have a much better time with Python just doing what I want instead of following the Python community's sometimes arbitrary and capricious standards.

Re: New Ways to Be Told That Your Python Code Is Bad

#18

Post by PEJOE » Fri, Sep 03, 2021, 1:41 AM UTC

mfgs wrote: post #3

"it unconditionally flags every use of while expressions." I'd find that pretty annoying. Consider a while loop in a thread: while not quit_thread_requested: # do threaded task

I agree, but to fair to the author I do not think the vast majority of people are implementing thread pools in python.

I also think there were good reasons the author's linters were left as optional, and its probably not because everyone thought they were great ideas.

Re: New Ways to Be Told That Your Python Code Is Bad

#19

Post by chrismarlow9 » Fri, Sep 03, 2021, 1:42 AM UTC

zootboy wrote: post #4

> less code is better than more code Not when it's at the cost of readability. The example "better" code fails my readability test horribly. I'd gladly take C's ternary operator over this monstrosity: > x = 4 if condition() else 5

Helper variables have a serious place in growth phase, when you typically have lots of new devs and lots of bad code.

$user_authenticated = hmac_auth($_get['token']) === true || ldap_check($username, $config['ldap_restrictions']) || verify_credentials($_post['user'], $_post['pass']) === true;

Sorry for the php pseudo code, I'm on mobile. And this is a very friendly example of what I'm trying to get across. It's self documenting code and worth the extra bytes.

I've seen way too many insane conditionals to agree that less code is better.

Re: New Ways to Be Told That Your Python Code Is Bad

#20

Post by [deleted] » Fri, Sep 03, 2021, 1:42 AM UTC

version_five wrote: post #8

k_sze wrote: post #6

Earlier quoted context omitted.

Exactly. I pretty much love everything about Python except its ternary operator. I also prefer C’s.

When I first started using python, I assumed it had a normal (c-like) ternary operator and was a little surprised to discover the syntax we're talking about. But after some time, it actually feels very natural to me, and is arguably more intuitive than ?: syntax. I assume this is where the author is coming from.

[deleted]