Live data from Hacker News

This Code Is CRAP (2011)

testing.googleblog.com

11–20 of 55 posts

Re: This Code Is CRAP (2011)

#11

>Note: This post is rated PG-13 for use of a mild expletive. If you are likely to be offended by the repeated use a word commonly heard in elementary school playgrounds, please don’t read any further. Mild as this ironic passive aggressiveness is, can't imagine something like this in modern sterile corporate messaging.

There's a good chance it'll be scrubbed now that it's frontpaged here

Re: This Code Is CRAP (2011)

#12
I have a goal to make the codebase at work cargo-crap compliant and enforce it with CI. I let an agent run overnight with it once and the diff touched like 40% of our codebase which is untenable for a single merge. So for now I’m doing it piecemeal as the opportunity presents itself.

Re: This Code Is CRAP (2011)

#14

The pendulum has swung too far in the direction of class, function, cyclomatic complexity (and here, CRAP) and similar idiotic metrics. This reminds me of a talk Sandi Metz did called "All the Little Things" where she covers the Gilded Rose kata. In the talk, she reworks her solution until there's almost nothing left showing the essence of the problem being solved. The cyclomatic complexity metric is touted at each s…

I suspect that we could bring this measure into the modern world with a little help from either DFS or ai.

Something like abstractions traversed during interpretation, lines of abstraction v.s. functional implementation, or logic statement dispersion.

It was hard to pin down what was abstraction vs. implementation, but it's much easier now.

Re: This Code Is CRAP (2011)

#16
post #10

Earlier quoted context omitted.

I believe the "This" might have gotten swallowed by HN's title normalizer.

This title normalizer is crap.

In its (admittedly weak) defense, if the submitter edits the title back during the few-minute window after submitting where this is possible, the normalizer does not kick back in. But it is a bit opaque, in the sense that the poster needs to: realize that the title has been changed; know that they can edit the title (but not too slow!); and know that it won't be filtered through again.

I have no idea what the website would look like without it, but I have a feeling it does more good than harm.

Re: This Code Is CRAP (2011)

#18
post #16

Earlier quoted context omitted.

This title normalizer is crap.

In its (admittedly weak) defense, if the submitter edits the title back during the few-minute window after submitting where this is possible, the normalizer does not kick back in. But it is a bit opaque, in the sense that the poster needs to: realize that the title has been changed; know that they can edit the title (but not too slow!); and know that it won't be filtered through again. I have no idea what the website…

What is the "good" when considering the lack of aggressive truncation/overflow concerns here?

Re: This Code Is CRAP (2011)

#19
post #10

Title is editorialized. Original: "This code is CRAP" referring to code in review as Change Risk Anti Pattern. Also, (2011)

I believe the "This" might have gotten swallowed by HN's title normalizer.

Submitters can rectify the title after submitting.

Re: This Code Is CRAP (2011)

#20

The pendulum has swung too far in the direction of class, function, cyclomatic complexity (and here, CRAP) and similar idiotic metrics. This reminds me of a talk Sandi Metz did called "All the Little Things" where she covers the Gilded Rose kata. In the talk, she reworks her solution until there's almost nothing left showing the essence of the problem being solved. The cyclomatic complexity metric is touted at each s…

A while back Hillel Wayne did a talk (whose name I forget) on what empirical evidence on software quality actually says.

As I recall, he concluded that there’s really no support for then-popular ideas like short functions, reducing cyclomatic complexity, avoiding explicit branch statements and loops, or TDD. (Tests yes, just not TDD.)

He made a pretty strong case that only two principles are particularly robust. One was that limiting code volume is good. The other is that working people too hard is bad.

Post reply on HN