When should code be tweaked to comply with Clippy lints?

Moderator note: This topic was separated from New format! syntax has rough edges - #13 by yuriy0

Woah. "Don't use Clippy" is not great advice, and "often makes bad suggestions" is a stretch, to put it mildly. Yes, Clippy isn't perfect, but the default settings have very few false positives, and it makes your code objectively better. I use it with a very pedantic configuration, and even then it hardly ever requires more than, say, one #[allow] per kLOC.

You should really just fix your code rather than blaming Clippy in such an unfair way and dissuading others from using it. That's absolutely not helpful.

It's a matter of majority opinion of experienced or at least regular users, so it's positively far more objective than the picture you are painting here.

12 Likes

I think you're the one being opinionated here. There are reasons for Clippy's existence, one of which is that it's really useful for many people, including me.

5 Likes

I think clippy is great. I don't always agree with it's suggestions but I feel that if everyone does similar things in similar ways that is going to make the global pool of Rust code quicker and easier for people to understand in a more fluid way. Rather than constantly stumbling into "odd" phrases and constructs in code.

That is the thing about idioms. They are commonly known terms and phrases in languages that users of the language immediately recognize.

5 Likes

Ouch, my head. I know what you mean but that is an interesting concept. That a subjective opinion can be turned into an objective opinion by having more people hold that opinion. Having more people believe a wrong conclusion does not make it more right. Sounds like consensus science or Russian propaganda.

5 Likes

Yes, that's what "idiomatic" means...?

Idiomatic doesn't mean "most correct", it means the usual, common way of expressing something in a language. If the majority of people using the language prefer to use Y to accomplish X, well, it's hard to argue that Y is unidiomatic even though the reasons for doing so in the first place may be subjective.

7 Likes

This is quite the claim, and I think unsubstantiated. Objectively by which metrics? Performance? Readability? Count of Sources Line of Code (and is it higher count or lower count)? Keep in mind also that every org places different weights on these different concerns.
The only truly objective metric you can apply to code is correctness. I admit that I think that some of the 'correctness' clippy lints are potentially useful, but mostly catch cases which are simply typos, or obvious things to do with unsafe code, so aren't broadly applicable enough to tolerate the rest of clippy. Having to go through hundreds of lints to decide which are useful is problematic in its own way!

At the very least, for the lint in the OP, I would say the discussion in this thread shows there are arguments being made for a large variety of format! formats. Then surely clippy should not give this lint, as it's clearly overly opinionated and there isn't an obvious, "objectively best" method to write it?

If clippy works for you, that's great, but my suggestion to not use it/use it sparingly is not directed at you. It's directed at the OP and others like them who find lints like in the OP to be counterproductive. My suggestion is simply: this is not a problem with the particular lint, it's a problem with the generally opinionated nature of clippy.


Meta: I'm not sure what the etiquette on this forum is as to replying to hidden posts. If its considered bad etiquette here, I apologize in advance.

4 Likes

If I understand correctly, this lint is in group pedantic - that is, explicitly marked as "opinionated" - and allow-by-default, so the problem is likely not so large.

1 Like

To get the obvious out of the way: SLoC is not a good code quality metric.

As for "Performance? Readability?" (and the later mentioned correctness aspect as well), the answer is "yes, both". Clippy lints always exist for a reason, performance and readability are two of the big ones, but feel free to google the "All the Clippy Lints" site to learn more about the individual categories and the reasoning behind every single lint (which are thoroughly explained along with the honest description of exceptional cases when you might want to turn them off).

This is the exact opposite of the truth, sorry. If you think that code quality improvements are merely an annoyance arising out of "opinionated" tools, then (a) you are wrong, because 70 years of software engineering experience empirically proves the opposite, and (b) Rust as a language and community might not be the right place for you, and you might want to consider not trying to convince a whole industry about an opinion of yours that explicitly contradicts its core values.


I am not going to reply to you any more, because I have said what I have to say, and I see no point in re-iterating the same ideas further.

5 Likes

It’s still in “style” (warn-by-default) on stable and beta though.

Edit: And apparently, the downgrade is so far only supposed to be temporary…? (https://github.com/rust-lang/rust-clippy/issues/10087) and (Mark uninlined_format_args as pedantic by Manishearth · Pull Request #10265 · rust-lang/rust-clippy · GitHub)

1 Like

Let me try to substantiate it. By way of analogy let's think about driving cars. If there were only one driver in one car on the road it really would not matter which side of the road he chose to drive on. Both sides of the road work equally well. The driver can choose what he likes best. A purely subjective choice.

Of course when there are many drivers on the road it's better they all agree to drive on the same side. Else things are going to get very confusing and dangerous. At least slowing everyone down as they constantly negotiates which side to pass each other on. Seems objectively better we all agree on which side of the road to use, even if it's not our subjectively preferred side. Then get on with driving rather than arguing about choice of road side.

I suggest it goes the same with code. If there are 10 ways to do the same thing, all of equal metrics like performance, LOC, etc. Subjectively a person will prefer one of those ways. Likely people will choose differently. The is fine for one person working on one program. But when many people will be reading and/or working a global pool of code it must be objectively better that everyone does similar things in similar ways. That makes everything habitual for the readers and writers of code, removes the need to stop and think a bit every time they see something unusual going on. Regularity minimises the chances of mistakes.

Typically such subjective "style" choices were made by one person for his personal creations. When it comes to teams working on code they reach agreement over style choice, draw up coding guidelines and such.

Now days with open source code the team is the entire world!

Rather than waste our time drawing up coding guidelines and reviewing code for adherence we just let clippy loose on it. Easy, quick, nothing to think about or argue about with those who feel differently.

What's not to like about that?

5 Likes

Yes, you're absolutely right. Following this analogy it makes sense.

But I don't think this analogy is exact. In particular, many different authors (which could be individuals or orgs) could work together (i.e. share code) without all having to follow the same style conventions. This is made possible by crates and strong guarantees of the rust type system. Certainly it's not obligatory for me to read the source code of crate X in order to use it.

Keeping with analogy, we should account for the case where many nations sharing a border have different traffic laws. Each of these nations don't insist that their neighbours change the particularities of their traffic laws to correspond to their own; they find a way to cooperate on the border to make things work, and within the interior of each nation, visitors from other nations are expected to follow the traffic laws of that nation.

Again, keeping with the analogy, different nations do try to find some sort of standardization for the size, shape, wheel width, etc., of vehicles which can legally drive in those nations. It would very confusing if you crossed the border and suddenly your car can't even fit in the lanes there. This is analogous to how e.g. type signatures, traits, functions, are the universal standard language for different rust lbraries to communicate. For the human authors, the naming conventions of types vs. functions vs. modules are very valuable as a method of discovery of functionality within a library (among other things).

This presupposes that everyone is reading everyone elses code, and writing everyone elses code. Maybe I'm wrong, but I don't think that's true. At least the 100s of crates which I use as dependencies (most transitive ones) - I have never read the source code or cared to even think about, did the maintainer run clippy or some other linter? do they follow what I believe are style best practices?

Is the overwhelming majority of rust programs/crates open source? Is the majority? I would be interested to know, but of course, we cannot know such metrics.

Yes, the ease of use and integration with automated processes are huge advantages of a linter tool over simply created "style guidelines" and communicating them within the org (enforcing those sorts of guidelines is nearly impossible for larger orgs without a linter).

The problem is the "nothing to argue about" part. This seems to presuppose that - either everybodies needs are identical, or that through enough iteration we will eventually converge to some "best", or "most standardized" way of writing things (or alternatively, maybe by "nothing to argue about" you mean that nobody could possibly disagree, or there are mechanisms in place to silence dissenters, but I don't think many people actually think this way...).

I would reject both of those claims. In my experience, claims like "I know the best way to do X" are typically untrue. I prefer collaboration on the level of, "you have your way, I have mine, we can come together and understand these different methods, and go back and do things our own way".

This all very abstract.. on the specific topic of Clippy: whereas some other linters (for other languages) are designed to allow high customizability to suit the needs of the project/org, it seems to me that Clippy is (intentionally!) very opinionated. It doesn't deal well with customization. Its purpose is to provide a large "library" of lints, not a configurable linting framework. I could certainly be wrong, I admit I'm not super familiar with it. But this is where I take issue with it, and why I don't use it, and why I would suggest to other people to not use it, if they have questions like "why does Clippy give this lint? - I think the original version is better".

However I'm not claiming that Clippy contributors should change their whole philosophy, and rewrite the tool with a totally different goal. They wrote something that they themselves find useful, and clearly others do as well. This is an achievement for themselves and the community! I'm only saying, it isn't for me, it isn't for everyone. And claiming that all Clippy lints will necessarily make your code objectively "best" or "better", or that everyone must use Clippy; or they are doing something wrong if they don't use it, is at best simply untrue and at worst hostile.

1 Like

Generally, that's a signal that that part of the discussion should be dropped, especially if it's getting heated and off-topic. It may not have reached moderator-level filtering yet though.

3 Likes

I did not understand why those posts were flagged as "off topic". They were about syntax and style. Which seems to fit the threads title just fine. All be it not directly related to format!

1 Like

My argument was not about code bing objectively best or better. It was a claim that it would be objectively better if we all used the same style and idioms all the time everywhere. Thus reducing cognitive load on everyone reading and writing the code.

Every now and then somebody posts a question here asking like "what is the idiomatic way to do X is Rust?". Then comes twenty replies demonstrating 20 different ways to do it. Maybe I'm slow but typically I find most of the suggestions not immediately obvious or down right obscure. That is cognitive load I don't need and wastes time. Example: Idiomatic way to avoid match - #13 by arnie

Then I think it, would it not be great if everyone did that kind of thing the same kind of way? Then, even if I don't like how it looks I only have to get my head around it once. Less fuss less muss.

Which is why I campaign for everyone biting the bullet and doing as clippy suggests.

Far from hostile, the intent is to make life easy for everyone. Especially those new to Rust that won't immediately be familiar with every obscure way a thing can be done. Like me. Still after two years.

4 Likes

The title and initial post are explicity about format!, and not about code style in general. The whole discussion about whether or not Clippy is a valuable tool feels off-topic to me, and I note that @scouten seems to not be participating in the thread that they started— That’s often a warning sign that the discussion might be coming off the rails.

NB: I originally flagged those posts hoping to keep the interesting discussion about stylistic choices around format use going, but it didn’t work and now we have yet another “Clippy in general” thread in its place.

2 Likes

Can we please do less flagging and hiding of posts? I want to see what people say — even if they say off-topic or stupid things :slightly_smiling_face:

Put differently, I don't like the idea that someone tries to decide what people should discuss on a discussion forum. Let people talk and if people repeatedly say boring, incoherent, or irrelevant things, well then I'll probably remember that for the future and quickly scroll by their posts.

I know you try all try to do good, but to me, the flags on this forum come across as unnecessary.

At this point, the Clippy topic has been moved into its own thread, separate from the format! discussion.

2 Likes

Yes, for sure! I completely agree with this statement, in theory. It is certainly a noble goal to try to find such a style.

However, in practice, what I have found is people will not agree on such a style. Reasonable people even sometimes cannot agree. When you massive organizations into the mix, disagreement is guaranteed. Even your own description of the issue - "Then comes twenty replies demonstrating 20 different ways to do it." would seem to support this.

Then, lets say we accept that we will disagree on the particulars of the style, but we agree that we want some consistent style. How do we pick who will choose this style? Should we resolve to find some totally equitable and representative method? Or accept that many voices will get left behind? In the real world, this usually ends up being "the org with the most money" - google, ms, whomever.(And I'm not saying these orgs are necessarily bad or good, just that that is how it ends up happening.)

Or should we instead endeavor to build tools which let everyone configure them to their own style/idioms and enforce them in CI/code review/editor automation (or not! if they so decide)? And of course, doing it this way does not preclude the creation of consistent style! I think it's just a more practical viewpoint if you factor in the paradox of human behaviour. I think fighting typical desires to express individuality or to explore (perhaps ill-conceived) novel directions, in the end, ends up being harmful. But I also accept that Rust is a much more opinionated language than most, and perhaps expectations of Rust tooling should be to be opinionated like the language itself. Maybe my desires here are not realistic, but I suppose one can dream...

I'm sure this is the intent. But for some reason my opinion of "don't use clippy" has attracted down right hostility. Not from you personally but if you read the other thread, this made people downright angry. I'm not sure why, other than it's presupposed that "Clippy is good" and "if you don't use it, you're bad" - and this is a typical response when dogmatic behaviors or opinions are being challenged.

Anyways, I appreciate your time discussing this topic with me.


Meta: thanks mods for moving this into its own thread. I'll try not to derail in the future and just make a new thread..

1 Like

While I do think that a tool like clippy is generally a useful companion to a programming language — making the code ecosystem more homogeneous and therefore more widely accessible — it is a delicate balance that needs to be struck just right. Unfortunately the incentives for those developing clippy are lopsided towards adding more lints, with no natural opposing force, which over the years has led to too fast growth, at least for my taste.

The first negative point that is not widely enough appreciated is that there are many projects (at least in my personal selection) that fail CI based on clippy warnings, which together with rampant rule growth leads to a lot of code churn for no good reason. A bit of churn would be the price of keeping things generally moving in the same direction, but what we’re seeing is too much.

The second negative point is that “fearless concurrency” (which was always wrong!) is made even more wrong by clippy. On multiple occasions I had to keep clippy from changing object lifetimes (e.g. by way of removing “needless collect”) in order to avoid deadlocks at runtime. Clippy is simply not smart enough to figure out these issues, and with the current state of type theory for concurrent systems I’m sure that this situation will remain dissatisfactory for quite a while still.

So, to my mind, clippy should be more conservative and more humble. As a psychological note, I felt bullied many times, which is the ONLY negative experience I had so far in the whole Rust ecosystem.

1 Like

I'm very curious to know in which way wrong exactly?

Interesting. I like to think a tool like Clippy should never be changing program behaviour. This sounds like a bug to me.