New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Style/FormatStringToken false positive with formatted input and template style enforced #7900
Comments
Sorry for the multiple edits, the issue was sent by mistake before I had time to read me again. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding! |
If this is still valid, should definitely be fixed. |
This behaviour is still present. I've taken a bit of a look into it and a solution isn't too challenging. But is the proposed behaviour something Rubocop should support? @inkstak proposes that Style/FormatStringToken:
EnforcedStyle: template should not report offences for the following Ruby format('%<number>0.02f', number: 1)
format('%{number}', number: 1) } The current behaviour will report an offence on the first line (above) because it is not template format. It strikes me that this is not an issue with the Rubocop rule. If config enforces template style, a developer should remain consistent in all instances. In the scenario where a developer finds a need to apply type, width, precision, or flags formatting to their strings, they ought to opt for the less restrictive style in their configuration: Style/FormatStringToken:
EnforcedStyle: annotated and refactor away from any use of the template style. @marcandre, what do you think? |
My understanding is that this cop helps to choose between two alternatives with equivalent output. The case |
@marcandre I see your point in enforcing a style only in instances when there are alternatives. Then again, to me, mixing the use of template and annotated within the same project does feel like a bit of a code smell though. If a developer finds themselves making use of |
@samrjenkins: Some people will feel like you, and they have a setting for this. Others will feel like me that "%{expr}" is the natural, default, simplest and clearest way and prefer using that whenever possible. In the rare case where that's not sufficient, then we need to be able to use the other form. This has the advantage of highlighting the difference between a straight conversion to string and a more complex one. Similarly, some people prefer using double quotes everywhere. Others prefer that single quoted strings indicate a string without interpolations and double quotes are reserved for strings requiring interpolation. |
@marcandre, I too had thought about the quotes analogy. I think it is a good one 👍 Happy to roll with your suggested behaviour. Thanks for talking this over with me. To confirm, is the suggestion to never report an offence for strings of the form |
Yes |
…formatted input and `template` style enforced, and add autocorrection
@marcandre This PR(#10160) looks good for me. |
…ed input and `template` style enforced, and add autocorrection
Expected behavior
When enforcing the template style:
and with the following code:
Formatting input doesn't work with template style - source
The cop should not report offenses or accept an new configuration option for formatted input.
I guess this is a similar issue reported in this comment
Actual behavior
It returns the offense :
Steps to reproduce the problem
See examples above
RuboCop version
The text was updated successfully, but these errors were encountered: