(Following the pattern of reporting my most frequent ReSharper quick actions with the goal of being able to use vanilla VS one day.)
If I Ctrl+. on the keyword if:
if (!string.IsNullOrWhiteSpace(recipient.Name))
return $"{recipient.Name} ({recipient.Address})";
return recipient.Address;
I would like to have the quick action 'Use ternary' which replaces with this:
return !string.IsNullOrWhiteSpace(recipient.Name)
? $"{recipient.Name} ({recipient.Address})"
: recipient.Address;
I also use the reverse.
@dotnet/roslyn-ide I would be willing to implement this. Also paging @alrz
One thing that held me off from this in the past was concerns about multiline statements and not producing good results. But if this is just a refactoring, it can always just be a helpful speedup tool.
Also, while we use the ?: pattern that @jnm2 shows heavily in roslyn, i know that lots of people put ?: at the end of the previous line. It feels like we'd need some sort of option in place to let people state what sort of pattern they wanted.
Also, while we use the ?: pattern that @jnm2 shows heavily in roslyn, i know that lots of people put ?: at the end of the previous line. It feels like we'd need some sort of option in place to let people state what sort of pattern they wanted.
Maybe, for now let's not add the formatting option. The beginning of the line is preferable for operators as it improves the ability of readers to quickly see what operations are taking place.
Yeah, I didn't make it clear that my ask isn't about formatting per se. If the choice is non-binary or feels inherently unbalanced, or one of the lines is much longer than the other, I usually switch to formatting this way:
return
x == 1 ? "One" :
x == 2 ? "Two" :
"Not one or two";
But I'm used to customizing formatting all the time.
Maybe, for now let's not add the formatting option. The beginning of the line is preferable for operators as it improves the ability of readers to quickly see what operations are taking place.
I think that's reasonable. At the very worst, this just means hte feature isn't great for some people. But for others, it would be fantastic.
as with the other issues @jnm2, PRs welcome here. :)
I think formatting issues comes down to the question "where to break?" Relates to https://github.com/dotnet/roslyn/issues/18282
(I mean we could just make it an inliner here and deal with formatting as part of the wrapping scenario)
@CyrusNajmabadi
Do we need a fix-all for this? according to your comment https://github.com/dotnet/roslyn/issues/14203#issuecomment-250840966 I think we can make this an analyzer.
I think fix all would be great for this. Are you comfortable with the SyntaxEditorBasedCodeFixProvider code? If so, it would be really easy to use that and get good fix all perf.
Replicating my comment from #23822 (regarding the FixAll, since some if/else combinations are not meant to become ternaries for readability reasons):
If considered, I'd also like to see the inverse to undo trigger-happy colleagues that apply this to each and every ternary regardless of their length and readability.
Also, perhaps a veto _against_ making it a FixAll provider since this should not be applied blindly to everything. I'm game for simple expressions as shown in the example though.
This has come up before with other refactoring providers and most have implemented some kind of line limit for the fix all provider. I have not seen an elegant way to specify what the limit should be. I have just hardcode if the "If Clause" or "Else Clause" is > 60 characters skip the refactoring. I would love to see something better in the infrastructure because this is not the only place where fixall options would be nice..
this is very helpful because when you are implementing, sometimes you realize you need extra statement for your ternary that you just wrote. then you have to convert to if-else. some times you remove an statement making it eligible for ternary operator usage.
very helpful for those who are not genius that write their code in one go, I think most type of programmers including me, will have to fix, iterate their implementation quite few times.
Fixed in #26236
Most helpful comment
Replicating my comment from #23822 (regarding the FixAll, since some if/else combinations are not meant to become ternaries for readability reasons):