|
I was just about to write something similar.
Like, are people just writing methods that call other methods, or am I missing something here?
|
|
|
|
|
Well, constructors, event handlers, and so forth that can be a single line of code work well as expression bodies.
And the expression body syntax for properties does make it clearer once you are used to it:
public string FolderBase => Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); Is a readonly property.
And for normal ones, you can omit the return keyword:
public string Name
{
get => _Name;
set => _Name = value;
}
I think it's a case of getting used to it - it took me a while as well, but I switched in the end.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
For my MVVM code, pretty much all of my set methods look like this:
get { return this.property; } set { if (value != this.property) { this.property = value; this.NotifyPropertyChanged(); } }
Doing it this way gains me nothing.
get => this.property; set => if (value != this.property) { this.property = value; this.NotifyPropertyChanged(); }
There is no tangible reason or benefit to use this construct. At all.
Even if we were using .Net5+ at work, I won't be adopting this...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I look at your excellent example here and I have to stop and stare awhile as my brain tries to insert curly brackets and a return. It's just not as readable, especially when the expressions get more complex.
|
|
|
|
|
No need to limit yourself to one-liners only. Consider something like following
public int MyProp => new Func<int>(() => {
int value = 0;
for (int counter = 0; counter < 100; counter++)
value--;
return value;
})();
Then again, it could be that I took a wrong turn at some point
|
|
|
|
|
override var description: String {
"That is Swift"
} Some some documentation. Hint the missing return is allowed in such one liners.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I am all for extra toppings, but I can't really see how your example is any better/easier than the C# example provided.
|
|
|
|
|
Really???
1. No "()" and
2. return statement.
3. And get rid of the annyoing ";"
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
There is no return statement in the C# example.
Your example is only 4 characters shorter than the C# example, and in yours you have to specify var and String ? What kind of nonsense is that!
|
|
|
|
|
The string is also needed in the C# syntax and that scary "=>" instead of Swift var. A bit silly but that is "software development"
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Every time that you add another way to do something without any single benefit you're making your language less and less maintainable, beacuse during years developers turnover and start mixing every single possbile syntax in the codebase. So instead of having a simple, clean language you end up with a language kitchen sink and products that look more like gas station toilets than actual software.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Agreed. I do a lot of inline definitions, and even then, this change adds nothing... really,
This:
public override string ToString() { return "No, just ... NO!"; }
And this:
public override string ToString() => "No, just ... NO!";
It's just 8 characters shorter ... are everyone becoming so lazy, that typing begin and end of context/function is too much for then to cope with?
|
|
|
|
|
I am even lazier, I usually auto generate toString override, so I rarely touch it more than that.
|
|
|
|
|
It took me a while but I got used to it and now default to it.
But ... it can be a pain because if you start with an expression body UserControl constructor like this it's fine:
public MyControl() => InitializeComponent();
But when you need to add code to the body, you have to convert it to a "traditional" function:
public WordleLine()
{
InitializeComponent();
...
}
But generally I try to use expression bodies throughout, when it's a single line of code.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: I try to use expression bodies throughout, when it's a single line of code.
|
|
|
|
|
I absolutely agree - I find they actually make code much easier to read.
When you need to convert to use a block, Ctl+'.' shows an option to convert to use a block, or back to an expression body - which saves a lots of bother.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|