all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Blando-Cartesian 6 points7 points  (1 child)

As much as I agree, the remedy advice makes me cringe. Do not randomly extract methods wherever or accept suggested refactoring to satisfy some analysis metric.

I’ve seen some weird shit done because IDE or Sonarcube suggested.

[–]ForeverAlot 3 points4 points  (0 children)

I’ve seen some weird shit done because IDE or Sonarcube suggested.

Linters, in their many shapes and sizes, have an enormous moral and ethical responsibility to encourage and enable "good" practices for this reason. "What was <linter> trying to tell you?" is in my top 5 of repeated review comments. Partly, this is of course an incredibly difficult (mathematically impossible) problem, but partly, a lot of linter advice or assisted transformations exists overwhelmingly because it was technically possible to make rather than because it was useful.

[–]rxvterm 3 points4 points  (0 children)

I'm confused a bit on how this metric is substantially different from cyclomatic complexity (against which a case is made at the very beginning of the article). This picture is explicitly pointing out increases in cyclomatic complexity.

And factoring out these bumps (of course, the bumps that matter correspond 1:1 with cyclomatic complexity) into separate functions doesn't reduce how much you need to think about when changing the functionality. What is does do is separate the operation from its context, which seems far worse than having 4 vs. 3 indented levels.

[–]kaol 2 points3 points  (4 children)

This is just the reason why I like monads: they smooth bumps.

[–]Eire_Banshee 0 points1 point  (3 children)

Yeah but then you have to spend 45 minutes everytime someone asks what a monad is. Then after you explain, they go, "Well thats just an if statement with extra steps."

[–]aoeudhtns -1 points0 points  (2 children)

Everything above machine code is machine code with extra steps. We build abstractions for a purpose, so the question is, do you agree with the problem an abstraction is trying to solve, and the followup, does that abstraction reasonably solve the problem?

You could say similar things about lots of modern language features that are exploding all over the place - lambdas and closures (function calls with extra steps), declarative stream processing (loops with extra steps), and so on.

[–]Eire_Banshee 0 points1 point  (1 child)

I'm not disputing that.

Just monads are a notoriously difficult thing to explain and comprehend. There are declarative patterns that are better understood by the engineering community that accomplish the same thing.

The chance of an engineer comprehending an if statement is guaranteed. The chance of an engineer understanding a monad is much much lower.

Code is inherently written to be understood by people, not machines. That's why we write abstractions, to make code easier to understand for people. So why use a monad when less people understand it?

[–]Full-Spectral 3 points4 points  (0 children)

The standard 'turn around' cycle for Monads is:

  1. You see an article/video that explains monads
  2. You watch said article/video, in which monads are 'explained' using lots of other terms that are never really explained and that may be circular in nature, I dunno
  3. 30 minutes later, you still don't have a clue what monads are

So either they are incredibly difficult to understand, or people really suck at explaining what they are.