[priansh]

While I agree with the ternary linting, the while loop piece makes absolutely no sense. There are absolutely many, many use cases of while loops; in fact, many dynamic programming algorithms rely on them.

Could you write them as a for loop? Possibly, but why? Is the new 2021 programming fad hating on while loops? Who do I contact to exchange my "js bad" t-shirts for "while bad" laptop stickers?

The logic behind disapproving of while loops in the article seems to stem from the author assuming while loops are "unbounded." This is absolutely, completely, totally false and there are entire branches of reasoning dedicated towards observing the bounded-ness of while loops. Most colleges include this in their curriculums and you usually have to learn to prove (via induction) the variants and invariants surrounding your loop before you can pass basic classes. It's even more ridiculous that, in the same breath, the author assumes for loops are guaranteed to complete execution. I can disprove this in two lines of code and two braincells:

  for x in infinite_generator():
    do_something()

This is also the general structure that message-queue libraries like Kafka, RabbitMQ etc take with their python code. Not to mention that, in many programming languages, for-loops are actually implemented as while loops behind the scenes.

I'll cede that it's easier to write unbounded code with while loops than for loops, but this is programmer error that can be pretty easily avoided by simply being a teensy tiny bit careful (and can be easily corrected). I'd also argue that the majority of these cases where while loops can be substituted by for loops, are also cases where writing a while loop is much simpler than trying to convert into a for loop. (Besides, you could make any of these arguments about recursion.)

> You know what else doesn’t have unbounded loops? Excel.

This is also a lie, Excel absolutely has infinite loops, it just yells at you when you do it. The equivalent of this in programming is a linter. Instead of just screaming fire every time the user writes a perfectly fine while loop, why not concentrate your efforts on identifying unbounded loops and introducing a linter rule for that?

Honestly, it's absolutely terrifying to me that someone contributing to the predominant linter for a major programming language not only wholeheartedly believes while loops are always unbounded and usually evil, but also managed to get this introduced (and presumably approved) by reviewers of this linter, and then proceeded to gloat about it on HackerNews. It comes as no shock to me that most people I've worked with disable pylint in their editors if they're this unreliable with their review process.

[frosted-flakes]

Did you miss the fact that these rules are disabled by default?

[priansh]

It should never have been introduced or approved in the first place.

[chrismorgan]

I think there is a place for it, though it was poorly justified in the article.

It depends on the type of programming you’re doing.

Algorithmics routinely does stuff that matches while loops and C-style for loops while loops, but doesn’t match iterator for loops very well.

In most parts of line-of-business sort of software development (and that’s the significant majority of software development, frankly, certainly a lot bigger than algorithmics), I’d say it’s rare for a while loop to be desirable: it should almost always be iterator-powered instead.

I think the C-style for loop thing is a particularly interesting aspect to this: I suspect most code that uses while loops where an iterator would not be appropriate would actually be at least as well-served by a C-style for loop. But Python made a deliberate decision not to have C-style for loops, because most uses of them are better-served by iteration. And so this nudging from while to for is really a perfectly natural extension of that.

Still, all things being considered, it’s not the sort of lint that I would ever turn on for myself or for code that I review, because I know when to use each.