3 ms·

This is painfully presumptuous. Generalizing others' code and constructs as "probably complete garbage" and suggesting that a 120-character line implies a "nee

This is painfully presumptuous. Generalizing others' code and constructs as "probably complete garbage" and suggesting that a 120-character line implies a "need to refactor" is either profoundly naive or grotesquely smug. I love Python, but programming languages don't have "zen," and reality is never so ideal that an 80-character line -- in and of itself -- can ever be assumed to imply anything useful.

Chris_Newton 14y ago
Thank you for making that point. I used to work on some code that did a lot of subgraph matching. Subgraph matching in general is computationally expensive, so ideally you do it heuristically, searching for more likely elements of the subgraph you’re looking for first so you can skip over edges/vertices that have no potential as early as possible. Even then, if you’re looking for a complicated subgraph then you’re going to have a bunch of conditional logic that runs lots inside deeply nested loops one way or another. That kind of code is often unwieldy, simply because the algorithms it implements are unwieldy. However, arbitrarily factoring out some of the inner levels into separate functions, which might have little meaning in themselves and little potential for reuse out of context, just means when you’re trying to review/update the code you need to look in more than one place to find it. On top of that, you’re also incurring a bunch of relatively heavy function calls (many parameters might need to be passed in for context) right in the middle of deeply nested code or you’re trusting your optimiser to inline them reliably. So these days, whenever I see someone quoting dogma about how more than n levels of nesting are bad and your code needs refactoring if you hit their personal arbitrary limit, I cringe a little inside. Not all real world algorithms fit neatly into a dozen lines of code and a level or two of looping.

Chris_Newton 14y ago

Thank you for making that point. I used to work on some code that did a lot of subgraph matching. Subgraph matching in general is computationally expensive, so ideally you do it heuristically, searching for more likely elements of the subgraph you’re looking for first so you can skip over edges/vertices that have no potential as early as possible. Even then, if you’re looking for a complicated subgraph then you’re going to have a bunch of conditional logic that runs lots inside deeply nested loops one way or another. That kind of code is often unwieldy, simply because the algorithms it implements are unwieldy. However, arbitrarily factoring out some of the inner levels into separate functions, which might have little meaning in themselves and little potential for reuse out of context, just means when you’re trying to review/update the code you need to look in more than one place to find it. On top of that, you’re also incurring a bunch of relatively heavy function calls (many parameters might need to be passed in for context) right in the middle of deeply nested code or you’re trusting your optimiser to inline them reliably. So these days, whenever I see someone quoting dogma about how more than n levels of nesting are bad and your code needs refactoring if you hit their personal arbitrary limit, I cringe a little inside. Not all real world algorithms fit neatly into a dozen lines of code and a level or two of looping.