|
lucanor wrote: I'm retired now, but it's like the religious argument of how many angels can dance on a pinhead. This far I follow you.
When I started decades ago wrote in assembler language and that was much easier to understand and one felt a direct connection to the machine. Well, I think it a good principle to be familiar with the mechanisms at least one level below the one you are working at.
C# is only fit for philosophy students. And there you lost me.
You make me think of an old discussion, way back in the age of NetNews - I saved it in my archives, because I found it extreme even 20+ years ago: This guy completely rejecting the VAX C compiler because it generated other machine instructions than he would have generated for a given C statement. Other debaters argued that the C compiler's choice was indeed faster, but he rejected the arguments: If there was no way to emit the instructions he wanted, the compiler was useless.
Choosing the best philosophy may be essential for finding the best solution. So, if C# stimulates to finding the best solution, I will embrace it (and I often do!).
|
|
|
|
|
Its true that C# isn't the right tool for everything, but its also not the wrong tool for everything. I love when people say, "I don't do that so nobody should."
|
|
|
|
|
Assembler is good, and useful - I have earned a lot of money writing it over the decades - but it's not the only thing.
And C# isn't about "a direct connection to the machine", it's about producing reliable, maintainable, understandable code quickly, by providing a huge amount of "proven" code in the background. Lists, Dictionaries, access to DB's, to interprocess communications, to threading, to ... well most of it, realy.
This frees you from the "donkey work" of development, and allows you to move from your codebase to someone else's without having to learn the library of functions they have (inevitably) developed and used extensively - just as you have almost certainly done the same with your code.
And because everybody shares much the same framework it's pretty well debugged by now (unlike other people's library functions which obviously aren't as good as yours)
C# isn't for "philosophy students", it's for "developers" - including low level coders sometimes!
"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!
|
|
|
|
|
...that this "new way" does me no good at all. Granted, most of my property get methods are indeed one-line methods, but I certainly won't be adopting the lambda version in those instances because both versions compile to the same result, and visually, it disrupts the flow of the code.
".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 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.
|
|
|
|