Google is crap
Are we just writing tautologies now?
This Code Is CRAP (2011)
21–30 of 55 posts
Re: This Code Is CRAP (2011)
#22Re: This Code Is CRAP (2011)
#23Earlier 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…
Maybe it's invisible when it works as intended, but the only times I notice a title has been changed, is when it's changed back to the original title, stripping most of the valuable context in the process. De-editorialization, I suppose.
(Or when the auto-renamer does a funny!)
Re: This Code Is CRAP (2011)
#24>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.
funny enough, the disclaimer comes after the term is used in the title and url.
"repeated use" seems to be doing the mitigation work here, though it does seem unusual that someone offended by the repetition would be unoffended by a one-off.
Re: This Code Is CRAP (2011)
#25I'm sure this method has evolved and/or been supplanted over the last 15 years, but one thing that struck me reading this is how much the dynamics of unit test coverage have changed in recent history, with AI-generated commits containing 10x as many unit tests (many of them kind of silly and tautological) as in the olden days. Gonna need to update some of those coefficients in their CRAP1 formula... Or maybe test coverage has/will become too noisy a parameter to use at all.
Re: This Code Is CRAP (2011)
#26I'm sure this method has evolved and/or been supplanted over the last 15 years, but one thing that struck me reading this is how much the dynamics of unit test coverage have changed in recent history, with AI-generated commits containing 10x as many unit tests (many of them kind of silly and tautological) as in the olden days. Gonna need to update some of those coefficients in their CRAP1 formula... Or maybe test cov…
> Or maybe test coverage has/will become too noisy a parameter to use at all.
It already is, ive banned unit tests via ci checks from our codebases, they were not particularly useful before LLMs and now they are a net negative.
We require int and some e2es and that does all that units do and more.
Re: This Code Is CRAP (2011)
#27Earlier quoted context omitted.
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?
Neutering Popular Science clickbait titles like “This Koala has a Secret Trick!”
Re: This Code Is CRAP (2011)
#28Earlier quoted context omitted.
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?
It's more of a gut feeling than anything else. I don't know what the normalization rules are, but I think we mostly notice the normalizer when it mangles something [1], and not when it's just quietly humming along. Someone with more spare time could probably figure out a dataset of original to normalized titles and measure that.
[1]: Example from the frontpage right now: "How Big Are Factorials?" probably got normalized to "Big Are Factorials?" originally, based off other previous manglings I have seen previously.
Re: This Code Is CRAP (2011)
#29The 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…
>cyclomatic complexity metric is touted at each step as a proxy for goodness of design and removal of complexity. However, a weakness of the measure itself
Amen, it’s hard to push back against an opaque term (cyclomatic!) when it isn’t really a measure of goodness, it’s a measure of branching, kind of a normal thing in code.
Early on I found that code with low cyclomatic complexity was just usually extremely verbose, lots of passing this to that while avoiding the branching necessary to get something done.
And yes, you can game the metric by hiding the complexity among the confusion of objects and components.
Re: This Code Is CRAP (2011)
#30The 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.
The thing is, AI has no idea when an abstraction is good or not.
The reductio ad absurdum here is that, if abstraction can just be assumed to be bad for quality and maintainability, then perhaps we should go back to hand writing machine code for non-microcoded sequential execution CPU architectures. Conversely, if that idea sounds as preposterous to you as it does to me, then you’re stuck conceding that at least some abstractions are mostly good. So then, before you can automate deciding which ones should and should not count against a code quality metric that’s computed automatically, you need to find an operational definition that can be applied deterministically.