|
public int Foo => 0;
or if you wanted something a little more useful:
public DateTime CreatedDate => DateTime.Now;
I think the latter is a better example of a use case for this syntax style.
As it stands, the question, where one is overriding a public method, not a property, is in my opinion a very poor example of when to use this syntax.
|
|
|
|
|
|
|
It does make the function easier to read.
|
|
|
|
|
|
Placing breakpoints on multiline statements is always a struggle.
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
|
|
|
|
|
Yup. I can't tell you how many times I've used the short code method, only to have to lengthen it later when I needed to debug...
|
|
|
|
|
Read all the comments...
For very little gained, we consumed an operator!
|
|
|
|
|
could choose any method name, but instead override ToString to some text.
My first care is chasing down the developer who decided to override the ToString causing confusion in the logs like why it saying this instead of the number of the int?????
.....
5 minutes in, ohhhhhh, it was me that wrote that 2 weeks ago.
|
|
|
|
|
To determine which is the right answer.
|
|
|
|
|
I do not know, hence I am asking the question.
|
|
|
|
|
Saving a couple of source lines (certainly a lot of lines containing braces only).
I suspect that programmers whose productivity is measured by produced lines including braces-only lines favor the old style. Programmers whose productivity is measured by source lines containing actual code are more likely to favor the => style.
|
|
|
|
|
Our productivity is measured by the question, "Does it work as intended?"
How many lines of code it took to get there doesn't matter in one bit.
We use a tool I came up with to generate MVVM entities, so we don't have to do that ourselves, and shortcuts like this are wasted on us.
".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
|
|
|
|
|
If I had to work somewhere where my productivity was measured by the number of lines I produced, I would be out of there in a heartbeat.
A good programmer is measured by the *quality* of the code they produce, sometimes less is more. Measuring if someone is productive by the number of lines is going to lead to unmaintainable crap code as all developers insert junk in an effort to appear as productive as possible to the bean counters.
|
|
|
|
|
Right? Some of the "best" work I've done probably involved cutting the total number of lines by a significant percentage. It's always been a ridiculous metric, but I haven't witnessed it ever being used.
RE: the expression body poll
When it is simple like the example, the "old school" syntax isn't making things any more clear for anyone at all really, unless they just haven't been introduced to expression body. This is not expression body's fault. No logic 1-liners mean there's just no reason or need to chew up screen space with the more verbose way of doing it.
I knee-jerk answered the poll that it depends, but thinking more, expression body is probably just the way to go here.
Even where the verbosity of "old school" makes more sense for readability, what should be happening in that scenario in pretty much all cases is an expression body that calls such an "old school" function.
Maybe before we were all doing so much dependency injection and unit testing this was not objectively answerable. Taking those into account though, expression body is a clear winner. FWIW, ReSharper seems to think so also.
|
|
|
|
|
It's useful to reduce 'wasteful' white space in simpler getters and setters and nested lambdas. But I just find it harder to read, because I don't use them very often. I think there's been a trend in the last few versions of C#, with context sensitive keywords and shortform symbols, to make the language more concise at the cost of readability.
But I learned C# by example so maybe my experience isn't the norm.
|
|
|
|
|
I'm retired now, but it's like the religious argument of how many angels can dance on a pinhead.
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.
C# is only fit for philosophy students.
|
|
|
|
|
C# is best for COM-project like automating MS Office with some database. But to control some chips and motors you better use assembler or C.
There is need for other tools than the hammer. Not everything is a nail. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Higher level languages are born out of convenience.
It's hard to believe a programmer would be against such things when the whole point in writing computer programs in the first place it to reduce the time/effort spent by humans.
|
|
|
|
|
Not only, but also using higher level tasks. Like HTML oder Javascript: direkt user interaction and webservices.
If you will code that in Assemlber or C you will have to do lot more. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Gabba gabba we accept you we accept you one of us
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
