Skip to content
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

[Fix #7705] Fix problem of Style/OneLineConditional cop with elsif. #7710

Closed
wants to merge 1 commit into from

Conversation

Lykos
Copy link

@Lykos Lykos commented Feb 12, 2020

One line conditionals with elsif branches are now transformed into multiline versions. Before this change, they were broken and autocorrect produced code that resulted in a syntax error. See Issue #7705 for more details.

One line conditionals with elsif branches are now transformed into
multiline versions. Before this change, they were broken and autocorrect
produced code that resulted in a syntax error. See Issue rubocop#7705 for more
details.
@Lykos Lykos requested a review from koic February 14, 2020 01:12
@Lykos Lykos changed the title [Fix #7705] Fix problem of one_line_conditional cop with elsif. [Fix #7705] Fix problem of Style/OneLineConditional cop with elsif. Feb 21, 2020
@Lykos
Copy link
Author

Lykos commented Feb 21, 2020

Friendly ping?

@@ -350,7 +350,7 @@ This cop can be configured with the EnforcedStyleForLeadingUnderscores
directive. It can be configured to allow for memoized instance variables
prefixed with an underscore. Prefixing ivars with an underscore is a
convention that is used to implicitly indicate that an ivar should not
be set or referenced outside of the memoization method.
be set or referencd outside of the memoization method.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems you unfixed a typo. :-)

'over `%<keyword>s/then/else/end` constructs.'
MSG_USE_TERNARY = 'Favor the ternary operator (`?:`) ' \
'over `%<keyword>s/then/else/end` constructs.'
MSG_USE_MULTILINE = 'Use multiple lines for ' \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to me that this change is more than a bugfix - it actually changes the behaviour of the cop. Why would we want to treat this case differently?

@bbatsov
Copy link
Collaborator

bbatsov commented Feb 29, 2020

Sorry for the slow response. I've added one question, as I'm not sure that this is exactly a bugfix. Also - when doing functional changes you always have to update the cop documentation as well, but let's first agree on what exactly do we want to do.

@Lykos
Copy link
Author

Lykos commented Feb 29, 2020

I agree about having to update the description.

But note that this is really a bugfix even though it introduces new behavior. But it introduces new behavior only in the case that was previously broken.

One line conditionals with an elsif were previously broken and autocorrect created a syntax error. To fix it, we have to make a choice on what should happen with them. I went with putting one line conditionals with elsif to multiple lines. Of course there are other options.

See the discussion on #7705. But since nobody reacted, I decided to just go ahead with the version that I considered most reasonable.

@bbatsov
Copy link
Collaborator

bbatsov commented Mar 1, 2020

But note that this is really a bugfix even though it introduces new behavior. But it introduces new behavior only in the case that was previously broken.

Fair enough.

One line conditionals with an elsif were previously broken and autocorrect created a syntax error. To fix it, we have to make a choice on what should happen with them. I went with putting one line conditionals with elsif to multiple lines. Of course there are other options.

I think the fundamental problem was that we tried to make those ternary conditions instead of just make them multi-line, which is obviously a more generic solution to the problem. I'm wondering if by default we shouldn't just make everything multiline and have an additional flag to convert one line conditions to ternary ops only when feasible. I think that's going to make the cop way more consistent.

See the discussion on #7705. But since nobody reacted, I decided to just go ahead with the version that I considered most reasonable.

Sorry about this. Unfortunately there are many open tickets and we don't have the time to respond to all of them in a timely fashion. Overall I think your direction makes sense, but we need to make the cop's behaviour more uniform as stated above.

@bbatsov
Copy link
Collaborator

bbatsov commented Mar 21, 2020

@Lykos ping :-)

@Lykos
Copy link
Author

Lykos commented Apr 15, 2020

I think I won't have time to do this any more, so consider this stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants