-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Adding statement seperator to if-else
, for
, etc. clauses
#559
Comments
If there is more than one line, I think readability disappears without seeing the word |
public static bool operator ==(Fraction left, Fraction right)
=> (!left.IsValid ^ !right.IsValid)
? false
: left.value == right.value; |
@orthoxerox What if the method had no |
This is an interesting idea. But the problem, to me, is that if (x) => Foo()
else => Bar(); Why should this return if the user just wanted the different invocations to just execute. And if this really is only to make returning better, then why do we need this, when we also have the simpler: return x ? Foo() : Bar(); ? |
See #559 (comment).
That's what I meant by the question "Should it be allowed in void contexts as well?". It shall be a shorthand for Even when put in seperate lines, it reduces 4 lines of public static bool operator ==(Fraction left, Fraction right)
{
if (!left.IsValid ^ !right.IsValid)
=> false;
else
=> left.value == right.value;
} What's the point behind arrow expression syntax if not reducing lines or having a different (functional) "look"? |
Oh, and besides, maybe the programmer wants the explicit |
This proposal is incredibly unintuitive. An arrow expression syntax supported by If you want an expression, use the existing syntax. If you want statements, use the existing syntax. In neither case is the existing syntax onerously verbose. And when it comes to style rules, believe me that the same places that would demand blocks for |
@lachbaer For methods/lambdas/locals, there is a clear understanding of what "=>" should mean. That's because the => attaches directly to the thing which is either void or non-void. With 'if' statements you're now making things confusing because you can totally have an if-statement in a void or non-void member. But it would then be the member which affected how => was treated inside the if. That is not at all what i would expect. |
I'm confused. They won't have seen this syntax (despite it being in C# since 1.0), but they will have seen => (which we only added for lambdas in 3.0 and for other members much later) ? We already have syntax which is more concise and more uniform for this use case today. I would much rather people just use that :) |
But do you admit - without any prejudice! - that it looks "nice"?
|
They won't have seen this syntax (despite it being in C# since 1.0)
Yes, I'm talking about design team e.g. who just had rudimentary programming courses in school or college. Those people - design is art - have a completely different view on things. We learned that on university! For them the intend must be seen just by the looks of it. Too long and nested blocks are counter productive.
Anyway that is only one example. Please don't mind if my university was the only one on the world that teaches that.
|
so use |
so use ?:
Mr. Other Team Member That Is No Programmer But Has Access To My Code For What Ever Reason only nows *rudemantary* things about programming. Variables, method calls, if, else and while, maybe even switch.
What the hell is `? :`...?
(Before you get me wrong *again*, I'm talking about that other guy not me!)
And besides, do you really *always* directly use the expression that fits best? Wouldn't it be great to keep typing down your programmatic idea the shortest way possible to your thoughts, not the shortest written?
|
is going to be tripping on way more important, fundamental issues than this. |
Use this as a teaching opportunity. If devs on your team don't know about constructs in C# 1.0 then it's a good time to teach them. |
If I was writing the code from your example, my thoughts (admittedly influenced by knowing C#) would go something like:
That translates fairly nicely to: if (left.IsValid != right.IsValid)
return false;
else
return left.value == right.value; ( I don't see how does your proposal improve on that. (And if your coding style dictates braces, then presumably your company thinks some verbosity is worth it.) Also, I do no understand how did you arrive at the "not xor not" expression, especially considering that the two negations cancel each other out. |
The reason that even simple See the following example (no code formatting by purpose): if (left.IsValid != right.IsValid) if (left.IsValid != right.IsValid); With a symbolic representation however it is clear even without braces that it belongs to the previous statement, no matter where it stands. if (left.IsValid != right.IsValid) if (left.IsValid != right.IsValid); The last one would give a compile time error. So in the case of a symbolic |
if (left.IsValid != right.IsValid);
return false; C# intentionally warns you if you do that:
|
if (left.IsValid != right.IsValid)
return false;
else
return left.value == right.value; And i would simplify that further to: return left.IsValid == right.IsValid &&
left.value == right.value; Which, conveniently, is what our 'Generate-Equals' code helper will even generate for you here :D |
Yes, and that's why we start using braces again... 🙄 But that was not the point. I wanted to show why braces are better used in this case, something I try to avoid by this topic. Just another idea, that considers everything written above. When allowing a tiny, little if (left.IsValid != right.IsValid)
: return false; No braces needed any more. |
Sorry that I am soooo dumb! 😢 I have never heard of that one. Neither in books, nor before now. But probably every other one on the world knows, but me... |
That's what you came up with after thinking a bit. But do you instantaneously think that way when programming? If yes, good for you, if no, welcome to the ordinary folks. We cannot review every single line of the code to find a way that suits better. We need to keep the costs per line down. Especially when not being on a team and programming mainly alone. I have to focus on my algorithms, my class layout, etc. and I simply want the language to support me by not having to think about every single optimization. I'm putting all statements - yes, Before I write anything further, @CyrusNajmabadi do you understand my point? |
In my opinion, the less in the language, the more your goal is supported. Many of your suggestions have been about introducing many new ways to do things that are already possible and now idiomatic in the language now that it's been around 15+ years. When you introduce new ways to do things, it adds a mental tax to everyone as now there is a need for people to know and internalize all the different ways to do things. Conversely, if there are just a few ways to accomplish what you want, then it becomes clearer and easier to know what to write, and it becomes easier to review the code around you.
You're avoiding constrcts the language has, and the ecosystem and community use. But then you don't like the impact it has on your code. And then you propose new constructs to help address that :) Talking to you, it often feels as if you're fighting against what the language is, and you're really trying to get us to make the language into what you want it to be. But that's not really what we're going to do. IMO, if you're using a language, it's worthwhile to learn and embrace its idioms, and find good ways to use them to help support your programming goals, rather than work against them.
I think so. |
if (left.IsValid != right.IsValid)
: return false; I must say, that's my best idea up to now! Maybe I'm prototyping that and simply eat that colon token when present. For |
I have ideas that come from my everyday use. Those ideas may be really odd sometimes, but they often have a deeper lying reason. Discussing them may help to develop better ideas or to discard them for the better. The deeper lying reason for this topic is that I find that heavy bracing cumbersome (see above). That's most probably not my problem alone. But I don't want to omit them for the same reasons that many coding styles demand it. Another topic made me come up with this idea of arrow expressions for @CyrusNajmabadi will probably say "you can already write |
Is that |
Good point. But that may be just a matter of accustoming. // This is just a visual example
if (left.IsValid != right.IsValid): return false; Now it doesn't directly look like the else clause of a ternary. Also in other representations a Or do you have another idea or token that achieves the purpose? |
if (left.IsValid != right.IsValid)
^ return false; Looks like a error message on the command line. if (left.IsValid != right.IsValid)
-> return false; Pointer? Nah, looks ugly. if (left.IsValid != right.IsValid)
[ return false; ] Same as with braces, and may conflict with "attributes everywhere". if (left.IsValid != right.IsValid)
_ return false; Too small, not noticable enough if (left.IsValid != right.IsValid)
\ return false; Too much similarity to if (left.IsValid != right.IsValid)
:: return false; Well, this could be an alternative. |
"I want a syntax with a different optical apperance, like:" if (left.IsValid != right.IsValid)
<- false; And then another person comes along and says, " I simply want the language to support me ", and i don't like any of those, give me: => false when left.IsValid != right.IsValid; :) And so on, and so forth. Is there a point at which you don't do these? Or do we keep adding this stuff because the existing options are not sufficient for some customers? |
Because i don't want to see your change applied to part of the method. I want to see what the entire method would look like applying your code change. And i'm giving you the opportunity to do this, instead of me guessing at your language feature, potentially getting it wrong, and frustrating you because i'm now discussing something different than what's in your mind.
Fine. Here's what i think it would look like based on how you've described your language feature so far: {
Debug.Assert(left != null);
Debug.Assert(right != null);
if (left.HasAnyErrors || right.HasAnyErrors)
:: return null;
// SPEC VIOLATION: see method definition for details
ConstantValue nullableEqualityResult = TryFoldingNullableEquality(kind, left, right);
if (nullableEqualityResult != null)
:: return nullableEqualityResult;
var valueLeft = left.ConstantValue;
var valueRight = right.ConstantValue;
if (valueLeft == null || valueRight == null)
:: return null;
if (valueLeft.IsBad || valueRight.IsBad)
:: return ConstantValue.Bad;
if (kind.IsEnum() && !kind.IsLifted())
:: return FoldEnumBinaryOperator(syntax, kind, left, right, diagnostics);
// Divisions by zero on integral types and decimal always fail even in an unchecked context.
if (IsDivisionByZero(kind, valueRight))
{
Error(diagnostics, ErrorCode.ERR_IntDivByZero, syntax);
return ConstantValue.Bad;
}
object newValue = null;
// Certain binary operations never fail; bool & bool, for example. If we are in one of those
// cases, simply fold the operation and return.
//
// Although remainder and division always overflow at runtime with arguments int.MinValue/long.MinValue and -1
// (regardless of checked context) the constant folding behavior is different.
// Remainder never overflows at compile time while division does.
newValue = FoldNeverOverflowBinaryOperators(kind, valueLeft, valueRight);
if (newValue != null)
:: return ConstantValue.Create(newValue, resultType);
ConstantValue concatResult = FoldStringConcatenation(kind, valueLeft, valueRight, ref compoundStringLength);
if (concatResult != null)
{
if (concatResult.IsBad)
:: Error(diagnostics, ErrorCode.ERR_ConstantStringTooLong, syntax);
return concatResult;
}
// Certain binary operations always fail if they overflow even when in an unchecked context;
// decimal + decimal, for example. If we are in one of those cases, make the attempt. If it
// succeeds, return the result. If not, give a compile-time error regardless of context.
try
:: newValue = FoldDecimalBinaryOperators(kind, valueLeft, valueRight);
catch (OverflowException)
{
Error(diagnostics, ErrorCode.ERR_DecConstError, syntax);
return ConstantValue.Bad;
}
if (newValue != null)
:: return ConstantValue.Create(newValue, resultType);
if (CheckOverflowAtCompileTime)
:: try
:: newValue = FoldCheckedIntegralBinaryOperator(kind, valueLeft, valueRight);
catch (OverflowException)
{
Error(diagnostics, ErrorCode.ERR_CheckedOverflow, syntax);
return ConstantValue.Bad;
}
else
:: newValue = FoldUncheckedIntegralBinaryOperator(kind, valueLeft, valueRight);
if (newValue != null)
:: return ConstantValue.Create(newValue, resultType);
else
:: return null;
} If i got that wrong, then sorry. But that is why i asked if you could post it yourself :-/ Now, looking at that, it looks really wonky to me. It's a big mismatch of different styles and patterns for statements+embedded-statements. |
Or do we keep adding this stuff because the existing options are not sufficient for some customers?
Yes, they are currently not sufficient!
|
So as long as someone complains and feels that the existing solutions are insufficient to them... we should just keep adding alternative ways to do these things? If we added your approach, and someone says it's "currently not sufficient"... then we just add what they want as well? And so on and so forth? |
Boy, you're killing me! So I simply answer to that with a big *ironic* YES!
Am 9. Mai 2017 10:25:54 MESZ schrieb CyrusNajmabadi <notifications@github.com>:
…> Yes, they are currently not sufficient!
So as long as someone complains and feels that the existing solutions
are insufficient to them... we should just keep adding alternative ways
to do these things? If we added your approach, and someone says it's
"currently not sufficient"... then we just add what they want as well?
And so on and so forth?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#559 (comment)
|
Alright, at least you're consistent. :) I was hoping with this exercise that you would realize the problem inherent here. We simply are not going to take C# and keep adding redundant features just because someone wants it :) After even 2-3 versions it would be an absolute mess. And I imagine you'd be one of many asking "why are there 6+ ways to just pick between two values and return them?" As i mentioned before, any change to hte language has to be significantly valuable. And each time you introduce something redundant, you not only start out with your -1000 points, but you also have even more of a difficult time because a redundant feature weighs the language down even more by adding complexity, confusion, and bifurcation to the community. -- As such, for future proposals, i would recommend workign to present the value of the proposal as more than just something you want because "[you] simply want the language to support [you] by not having to think about every single optimization." That's not a sufficient reason for us to do something. And, as you've seen on many of your proposals, the community is not reacting to it well. Proposals should ideally be able to demonstrate their worth against the language as it exists today. Not against the subset of hte language you use because you've decided not to use certain parts of it. If the feature has value whne compared to the entire language we have, i think you'll see a highly positive reaction from the community. However, if the feature just replicates what is already there, but which you don't like using, then i think you'll see little interest. |
@CyrusNajmabadi Do you know what "ironic" means? Meanwhile I have my doubts a bit.
I wouldn't do it for Anyhow, I think we must completely start over the discussion! Because you still haven't got the essence of it. First: I don't want the syntax to be how I want it only!!!!!!! Never ever! Period!If you still believe that then you are completely mistaken! You must break loose from that idea! I see a problem from a users perspective and I am making suggestions on how that could be resolved. The suggestion is and shall be a starter for the discussion. The word "Proposal" does not occur in the topic.This is a discussion about a concept. There is no concrete syntax that is proposed as being without any alternative. You keep stating that there is already valid syntax. But if that is the last word from the team since 15 years, then why have you introduced expression bodies?Why writing int Age
=> CalculateAge(_dayOfBirth); if you could already have that done by int Age
{
get
{
return CalculateAge(_dayOfBirth);
}
} Why introducing int GetAge() =>
CalculateAge(_dayOfBirth); if there already was a valid syntax int GetAge()
{
return CalculateAge(_dayOfBirth);
} It only saves two mostly empty lines, one keyword and adds two further characters. Why do people want to shorten their code?I made my point above already in several places (e.g. less scrolling). What's your answer? Why is the current syntax not sufficientI wrote that already many times, but, whew, again:
BUT, curly braces blow up the length of the code and produce unproductive and actual unneccessary space. They are only there to protrude the statement. Alternative to current syntaxIt would be great to have any way to protrude the statement without the surrounding braced block. The initial idea was to add The second idea was to add New ideaThe third (new) idea to achieve the goal of protruding the single statement without a braced block is to introduce a "blank token", that is composed of only one, two tops, characters. This token has no meaning and is simply eaten while parsing. It is a bit like the underscores in numbers ( To go with ASCII I'm using the backtick ` character if (left.IsValid != right.IsValid)
` return false; (Also, the backtick could just make the following character be ignored. @CyrusNajmabadi Then everybody can use their own character, when that's what you want. 😀) The highlight color should stay the standard color. It shall not be green like comments, so that the protruding character of that construct is preserved. With this third idea no syntax change to the Addendum: the backtick should be allowed in places where other statements and maybe start of expressions are allowed. |
How shall I know that without consulting the community? And there are proposals from me that aren't closed yet and that aren't torn apart or have their likes. But if it keeps being this way and brainstormes aren't welcome then it might be better for me to backtrack and shut up 😢 |
I must correct, the backtick character alone already serves the purpose enough. https://github.com/dotnet/roslyn/blob/master/src/Compilers/CSharp/Portable/Binder/Binder_Operators.cs#L1415 with backtick token: {
Debug.Assert(left != null);
Debug.Assert(right != null);
if (left.HasAnyErrors || right.HasAnyErrors)
` return null;
// SPEC VIOLATION: see method definition for details
ConstantValue nullableEqualityResult = TryFoldingNullableEquality(kind, left, right);
if (nullableEqualityResult != null)
` return nullableEqualityResult;
var valueLeft = left.ConstantValue;
var valueRight = right.ConstantValue;
if (valueLeft == null || valueRight == null)
` return null;
if (valueLeft.IsBad || valueRight.IsBad)
` return ConstantValue.Bad;
if (kind.IsEnum() && !kind.IsLifted())
` return FoldEnumBinaryOperator(syntax, kind, left, right, diagnostics);
// Divisions by zero on integral types and decimal always fail even in an unchecked context.
if (IsDivisionByZero(kind, valueRight))
{
Error(diagnostics, ErrorCode.ERR_IntDivByZero, syntax);
return ConstantValue.Bad;
}
object newValue = null;
// Certain binary operations never fail; bool & bool, for example. If we are in one of those
// cases, simply fold the operation and return.
//
// Although remainder and division always overflow at runtime with arguments int.MinValue/long.MinValue and -1
// (regardless of checked context) the constant folding behavior is different.
// Remainder never overflows at compile time while division does.
newValue = FoldNeverOverflowBinaryOperators(kind, valueLeft, valueRight);
if (newValue != null)
` return ConstantValue.Create(newValue, resultType);
ConstantValue concatResult = FoldStringConcatenation(kind, valueLeft, valueRight, ref compoundStringLength);
if (concatResult != null)
{
if (concatResult.IsBad)
` Error(diagnostics, ErrorCode.ERR_ConstantStringTooLong, syntax);
return concatResult;
}
// Certain binary operations always fail if they overflow even when in an unchecked context;
// decimal + decimal, for example. If we are in one of those cases, make the attempt. If it
// succeeds, return the result. If not, give a compile-time error regardless of context.
try
{
newValue = FoldDecimalBinaryOperators(kind, valueLeft, valueRight);
}
catch (OverflowException)
{
Error(diagnostics, ErrorCode.ERR_DecConstError, syntax);
return ConstantValue.Bad;
}
if (newValue != null)
` return ConstantValue.Create(newValue, resultType);
if (CheckOverflowAtCompileTime)
{
try
{
newValue = FoldCheckedIntegralBinaryOperator(kind, valueLeft, valueRight);
}
catch (OverflowException)
{
Error(diagnostics, ErrorCode.ERR_CheckedOverflow, syntax);
return ConstantValue.Bad;
}
}
else
` newValue = FoldUncheckedIntegralBinaryOperator(kind, valueLeft, valueRight);
if (newValue != null)
` return ConstantValue.Create(newValue, resultType);
else
` return null;
} There are places where I probably wouldn't write it with backticks. E.g. when the if has a block then the else should be a block as well, even if it is only one statement. But that's a matter of style guides. |
Starts with keyword, indented properly.
Starts with character that has no meaning, shifts indentation in weird way and actually requires you to type more characters. How is this better?
If you don't want to use braces, maybe it's time to speak with your team and change the rule? In C# 5 I was using braces for everything. Everything in a block looked so consistent to me. :) Technology changes and sometimes makes some rules outdated. If your team still chooses to stick with { } I cannot imagine they would go with what you're proposing. |
If that's your opinion on expression bodies then you're anyway no candidate for these kind of additions.
See "2. putting the same statement on the next line, with indention, is also considered bad style." |
What do you mean by my opinion on expression bodied members? I didn't write anything about them except that blocks look weird. Meaning single line if, for, etc. with { } next to expression bodied members and bunch of chained linq methods don't look as consistent as they did few C# versions ago.
So as I suggested, maybe you should talk to your team and reevaluate the rules since you disagree with them. What does your proposal really introduce? What's the difference (except of 'bad practice') between following three:
|
I don't disagree with the existing rules. I.e. I agree upon having no statements following
Line starts with comment trivia, also very bold trivia:
Line does not start directly with statement. This indicates as first sight - before the eyes and the brain have adapted to the indention (human factors, seriously!) and before the brain has analyzed that behind the
I don't really know how I should express that differently...?! 😕 If you have any other idea how the goal of omitting the braces without the points 1. and 2. from above (bad style rules), then it will be very welcome by me here. |
I have always written if (true) return null; if (true)
{
return null;
} But never do I write a multi-line It is so simple, allows me to occasionally write more succinct code, and does not violate the style rules that help prevent overlooking multiple indented lines that are not subject to the |
@lachbaer You basically reject 100% of existing solutions saying it's bad practice and think adding new syntax that does completely nothing is a solution. Well I consider writing additional characters that don't do anything bad practice and would forbid what you're proposing the moment new version of C# ships. Also you still didn't explain to me how my three examples differ. Why are all 8 of your suggestions @bondsbw |
@dstarkowski Agreed, at some point it boils down to preference and awareness. Someone out there loves Whitesmiths style. Someone believes minification is a work of art. So long as I'm not working with those people, I'm fine. (btw I'm not comparing this suggestion to those abominations 😄) |
Amen (or Amin), brother 😃 It is really hard for me to explain my concerns and drawbacks with the current styles! I'll try again. First, C, C#, D, Java, ECMAScript, PHP and probably others all have the same Non-Empty-Statement or Block-Statement syntax. From that point there is absolutely no need for a change, because it so common to everybody. But they all suffer from the same "problem" (when seen as such). Many maybe most programmers, by team convention or personal preference, don't use the Non-Empty-Statement syntax. The first question that must be answered to understand my thoughts is why they loath it. My believe is that one reason is what @dstarkowski just stated above: "Two things are happening in one line [...] and I don't like that". Another is probably what we all have encountered already. When there is only one statement and you need another one you either have to create a braced block anyway or you run into semantic errors. // Version 1.0
if (condition)
return;
// Version 1.1 (ups, forget to block the statements)
if (condition)
RaiseEvent();
return; The result is that every 'than/else/for statement' is wrapped in a block an thus creates the "excessive empty space" that leads to scrolling and a lack of overview, especially in longer methods. If now a little syntax change is added (maybe the other languages follow in the future?) the actual reason for the guideline why everything, every single statement, is braced vanishes. (I go with // Version 1.0
if (condition)
: return;
// Version 1.1 (compile time error)
if (condition)
RaiseEvent();
: return;
// Version 1.2 (you can easily spot that something is weired)
if (condition)
: RaiseEvent();
return; And even if you do put the statement in one line, you can profit from that, if you like it. if (cond1) : return false;
if (condition2) : return true;
if (yetanothercondition) : return null; That has a bit the look of a Another bonus, if you like, is that a custom analyzer could warn or error you if you forget to either start a block after SummaryI strongly believe that the reluctance of non-brace-blocked substatements come from the just explained reasons. Introducing an optional seperator would eliminate them and make non-braced one-statement lines a first class citizen again in the style guides. If I still have not explained it correctly or extensively enough, then please let me know. |
if-else
clausesif-else
, for
, etc. clauses
You're explaining them all just fine. They're just being appropriately dismissed as entirely unnecessary and redundant. As Cyrus has explained multiple times these tiny language tweaks offer nothing that make them worth adopting. Any perceived benefit is immediately lost to the fact that it's duplicitous and would only confuse and fracture code bases, probably even causing more style arguments than it would solve. |
@HaloFour Without having it we wouldn't know. With best regards from Schroedingers cat. 🐱 Also you can call that evolution 😀 Let's assume an existing code base that follows the guide lines exceptionally and has no standalone substatements. When introducing the seperator with erroring analyzer there won't be any code break. We can start migrating, manually or with automatic code rewrites. I doubt that it will lead to confusion. And when the analyzer is put to "warn" then any occurances of guide violating standalone substatements are reported. I still doubt that it will confuse and fracture code bases. |
Why not just use an indention analyzer? That way you can get rid of the style guideline and let the compiler tell you when you're wrong. |
I don't like snakes 🐍 😉 Indentions don't have the optical appearance that helps when overflying the code with the eyes. They are just... empty. Oh, and with this addition were no real actual need for an analyzer. |
Maybe I could play around with one of the many indent styles or create an own one. But it would be great if Visual Studio (Code) could help me with that by allowing custom brace styles for different constructs in the way it handles "Codestyle / Naming" in the options. Constructs being the different statements together with the information whether the block only consist of one or more statements. Now VS always destroys my formatting attempts or I have to put the braces and indention manually for every statement construct. Or does anyone know about an Add-In that does that already? |
@lachbaer See the entire list of pages underneath Tools > Options > Text Editor > C# > Code Style > Formatting, new in VS2017. |
@jnm2 Those options are limited. There is no possibility to chose between e.g. Allman, Horstmann or Pico style or even custom styles. A bit more control as there is for "Code Style > Naming" would be nice. |
@lachbaer Feel free to submit PRs over at dotnet/roslyn. But this is not relevant to dotnet/csharplang. Note: the team is not going to invest here as there is practically no demand for things like Horstmann bracing. Seriously, we haven't gotten a single customer to ever ask for it. We're just not going to spend cycles on this sort of thing when there is actual practical work we can do that can benefit large numbers of people. |
@CyrusNajmabadi And a further question. Does the produced empty space that makes one scrolling through many lines of code never bother you when re-inspecting your or third party code? |
I am not blaming you. I'm letting you know where the appropriate place for bugs is. And i'm telling you the team's general perspective on work like this.
An actual solution for what? To me i don't see a problem here. If i want non-brief code, i write things in a non-brief fashion . If i want brief code, i use the language constructs available for that.
Not really. In the rare case where it has, i've just fixed the code up. |
Update
This is no longer about Arrow expression syntax to
if-else
clauses.The intent was to eliminate the reasons for guidelines for embracing every statement that follows an
if
,while
orfor
(etc.) statement.Please see #559 (comment) for a better catchup explanation.
[Old initiating post:]
Arrow expressions are awesome!
They let code look so good, short and intuitive. I'd like to have them for
if
-clauses as well.Why not use
return
? Because many style guides prescribe the use of blocks after everyif
, what would result in the much longer:But the same style guides allow the use of arrow syntax, what would result in the first 5-liner.
Especially when some conditions must be met at the beginning of a method and early returns are common then this syntax could shorten code and enhance readability.
Questions
void
contexts as well?void
llambda expressions exists.The text was updated successfully, but these errors were encountered: