[henrikn]

> They're wrong: it's the smallest it can possibly be while still correctly performing the necessary goal; any smaller, and you have to break it into multiple smaller methods that provide no value except keeping Code Climate happy.

Wrong? Smallest it can possibly be? Those are strong claims.

I definitely disagree with Code Climate from time to time. But I try to keep an open mind.

I've found that trying to follow dumb rules can be enlightening, even when my first reaction is that I disagree. This goes for Code Climate as well as arbitrary rules, such as Sandi Metz': https://gist.github.com/henrik/4509394

I looked at your `priority_compare`, for example. As someone who did not write that code, I find it a little hard to follow. It has conditionals four levels deep (counting the ternaries). Your `Mime::TYPE` class is quite long, as is its test.

I would let the Code Climate feedback inspire me to attempt to extract a method object in this case, along these lines: https://gist.github.com/henrik/9355101

That would result in more code overall, but smaller objects on average, and to my eyes readability is improved because the complexity is a little abstracted. Do you truly feel it provides no value?

[halostatue]

Your extraction attempt actually proves my point: your code is more complex, is less readable, is demonstrably wrong, and destroys performance in at least two ways (I’d benchmark my “ugly” code against yours every time and win).

More complex and less readable: you’ve taken the comparison out of context of the class which is being used for comparison and put it in a different class and file that has to be opened for understanding a priority comparison. Worse, that separate class and file isn’t going to be reusable for anything else, because it depends heavily on the (admittedly large, but justifiably so) public interface of MIME::Type. So, readability is made worse for the sake of a dubious improvement in testability and no value in reuse.

If your editor supports code folding (it should, and you should be using it), then you don’t even have to see the implementation of `priority_compare` if you don’t need it.

Demonstrably wrong: you’re calling `#simplified_value` twice. You could make that not as ugly by caching, but that’s already known to be a waste of time because your extraction…

Destroys performance: `priority_compare` is used for sorting (as the code comment states outright). Creating a new object for each and every comparison is going to send sort performance to hell in a handbasket with rockets on it. It’s the same problem that plagues people who use decoration heavily: performance sucks and memory use gets ugly quick. The calling of `#simplified_value` twice doesn’t help here, and caching the value only makes memory use worse.

The code comment on `priority_compare` is clear: it’s a specialized implementation of `<=>` used for sorting from MIME::Types#[]. That should immediately halt any consideration of extracting the code into an object that needs creation, and continuing on with that is a failure of good software development in favour of purity suggested by stupid rules. Even extracting it into a class method is of highly questionable value, because now you have to (as you do with your extraction) know the left and right comparison objects, rather than (safely) assuming that the undecorated version is the object itself. It’s rather the difference between operators overloading in C++ where you need to provide both left and right values vs only providing the right value because the left value is the object itself.

I considered separating the if/elsif conditions to separate methods, but you still need the if/elsif conditions, and all you’re doing is pushing code around in ways that, once again, will not be used outside of `priority_compare`.

I had considered implementing `priority_compare` at the call-site, but it’s used at two places in MIME::Types. So, the `priority_compare` is reused, but the component parts aren’t, really.

I will admit to laying a trap with `priority_compare`: I’ve worked on this code off and on for ten years. Code Climate, being a naïve program, cannot understand how the code is going to be used, but only understands how it’s defined and measures it against some fairly simplistic and stupid metrics. They can be interesting when you are first approaching a program to understand hotspots, but their value drops to zero very quickly compared to the understanding you have from working with the code regularly.

Where I think Code Climate (and similar tools; they just happen to be fairly high-profile in the Ruby community) goes wrong is that a lot of inexperienced and naïve developers tend to treat it as Truth that Must Be Followed. Many of these folks are also fans of so-called “Clean Code” techniques and otherwise lack the experience necessary to know when not to follow these sorts of rules and assume that Code Climate is good becaus it simplifies the score to a GPA/grade.

[henrikn]

Wrong: I'm sure it is. I did it without tests and didn't go through the logic carefully since that wasn't at all the point. The design was.

Performance: could be. If your context is one where performance is paramount and trumps readability/maintainability, that may certainly be easier to achieve with less factored code. I spent zero time trying to optimize the code.

I suspect this design doesn't make that as hard as you make it sound, though. My team writes code in the style of my example, and we don't have problems optimizing when it's called for. Though we avoid optimizing at the expense of readability unless we see a real problem.

I find it interesting that you think my example is clearly "more complex" and "less readable". I, of course, feel it is the other way around.

The fact that you've worked (mostly on your own, going by the contributor stats) on this library for ten years will of course mean that you know your way around it.

As a visitor to the codebase, I see big classes and big chunks of code that require me to load a lot into my head and digest it before I can make sense of it. Breaking that up a little means I can make sense of a smaller piece of more self-documenting logic, then dig down to lower abstractions as needed.

If you're saying that you find your way around your code better than my refactored code, I believe you.

If you're saying you think the refactored code would be harder to understand for the average developer, I think you're dead wrong.

[halostatue]

Re: wrong: it's not only wrong, but your admission that you didn't go through the logic carefully (that is, you didn't pay attention to the comments, you didn't pay attention to the spots where it was called, etc.) says that you didn't actually pay attention to the design of the system. You refactored for a nonsensical version of “object purity” (trying to satisfy for those metrics) instead of correctness. You claim to have tried to make a point about the design and failed, because your refactoring at best did not help readability, didn't actually improve any of the metrics that Code Climate reports about, and objectively made the code perform worse in the context of how it's called.

This is what happens when you refactor in a vacuum, and the danger of following tools like CC or even the “advice” given in the article at the top of this chain. I would never let a developer who works with me get away with the sort of refactoring attempt you did.

As far as your code being more complex and less readable, you have traded minor depth complexity for greater breadth complexity without simplifying the main comparison at all, and (as I keep pointing out) made the performance worse, to boot. Your code is less readable because now I've got some kind of comparison object that I have to instantiate—and it takes two objects called “one” and “two”. Now, when looking at your priority comparison object, I have to jump between mime/type.rb and mime/type/priority_comparison.rb to understand the data values that are being compared.

The reality is that the MIME::Type class is dead simple: it's a validated data object with the self-documenting descriptive properties. MIME::Types is even simpler: it's a container that knows how to search for its contained class. I've done some fairly aggressive refactoring (it just used to be two files) to extract parsing and file interaction from the main classes, and what's left is just what's required to interact with the data provided by a MIME::Type and to work with a MIME::Type collection (although some of it is going away because the previous on-disk data representation was too anemic, and the current on-disk data representation provides just what's needed in a fairly efficient manner).

That you look at these and say “big classes!” says much more about your own biases than about the code. mime-types provides very little deep functionality, but a lot of documented and self-documented code. It just happens that the data included has a lot of attributes, and I'm a big believer in backwards compatibility. Next year, when I release mime-types 3.0, I'll be removing the deprecated functionality—and it'll cut the code in MIME::Type by about 35-40%, but it will still leave things that will trip up naïve complexity advice and refactorers.

I misspoke, though, about improvements to priority_compare: when I feel comfortable making mime-types use refinements, then I would probably make an in-place refinement of Nil to support #<=>. That probably won't happen until 2015 or 2016, though—I have to keep supporting versions of Ruby that don't support refinements until after the interpreter version EOLs.