|
Readable line counts are what matters. Most software, including the Windows 10 source, could technically be represented on a single line (get wrecked Python nerds  ).
Also, and I might be a pedant, but I'd say this
int y = x switch { "test" => 0, "test1" => 1, "test2" => 2, _ => 3 };
is way more readable than this
int z = -1; switch (x) { case "test": z = 0; break; case "test1": z = 1; break; case "test2": z = 2; break; default: z = 3; break; };
since it has fewer columns, reads much like an array initializer syntax which is common in modern languages, and due to the restrictions on the expression syntax the case body is a relatively constant size (a compound scope isn't allowed like with the statement syntax).
modified 11-Jun-21 6:04am.
|
|
|
|
|
Jon McKee wrote: (get wrecked Python nerds )
People who program in Python cannot be classified as nerds. Nerds are smart.
Nothing succeeds like a budgie without teeth.
|
|
|
|
|
I used to feel the same way until IntelliJ IDEA showed me how to reduce a block of code to a single line using similar obscure syntax. (much to my surprise!)
The Lounge[^]
Get me coffee and no one gets hurt!
|
|
|
|
|
Cp-Coder wrote: Tonight I will have nightmares of vicious IDEs chasing after me to correct all my many mistakes!
Kind of mandatory[^]
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Because doing something guilelessly makes a person appear to be much cooler.
|
|
|
|
|
IMO, because doing something guilelessly makes a person appear to be a bad engineering example.
|
|
|
|
|
Dennis Ritchie will haunt them.
|
|
|
|
|
We're saving people that think they know better from ever bothering with the nonsense.
Whether or not they're correct is another matter.
|
|
|
|
|
ELI5
Anyone care to explain ?
it looks like a switch.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Personally I find that 1000x more readable than switch/case or if/else, and also tells me if I haven't implemented the default option, so more robust code.
|
|
|
|
|
Terseness is the enemy of clarity. All programmers need to remember this. Programmers who use languages that encourage terseness need to be extra careful to not destroy clarity.
|
|
|
|
|
It's part of the "how much can I pack into one LINQ / SQL statement" school of obfuscation.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Chris Maunder wrote: Are we really helping the Art with this type of syntax?
No.
There seems to be a modern prejudice against classic iteration (for, while) and conditionals (if). Somehow writing these same constructs as imperative statements is "more robust" and "less error-prone". Any construct that introduces a nested scope seems subject to this prejudice. Those imperative statements are only syntactic sugar supplied by the compiler.
I have a hard time liking the new features in the last couple of major versions of C#. Most if not all of them seem to be this sort of syntactic sugar, and they don't really add new functionality.
The features that make the most sense to me are those that let you omit specifying a type where the compiler can figure it out from context. That saves typing (even with IntelliSense) and time.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: Those imperative statements are only syntactic sugar supplied by the compiler.
I see this argument a lot, but you do know for is just syntactic sugar too, right? Same with references, same with try-with-resources, same with lambdas, same with properties, same with typedefs... I could go on for hours. Most of the features of modern languages are just sugar. The real litmus test is whether that sugar is useful to add clarity, simplify a common use-case, etc.
|
|
|
|
|
I suppose I could code in IL directly ... 
Software Zen: delete this;
|
|
|
|
|
Since vendors wanted to lock you in to their development environment rather than using the competition.
Most people rely on autocomplete and suggestions for their coding. If you would prefer to use vim or another editor that doesn't do that - it makes it just that little bit harder. . . and once you are hooked, much less easy to move away . . .
I may be paranoid - but it doesn't make me wrong.
|
|
|
|
|
This particular way of typing things doesn't make terribly much sense, but it demonstrates how you can save syntax. The one method it demonstrates is a lambda, the other (and I think that's the point here) is a Switch expression. I know I miss the latter in my C++ project.
|
|
|
|
|
Too much syntax, kills the syntax
This is just syntactic sugar, probably to make it more accessible to a new generation of programmers. But under the hood it'll still generate the same stuff we grew up with.
I really don't like arguments such as: yes, "but this is shorter", or "you shouldn't use loops anymore"
If you write out stuff in full, intentions become clearer. But hey, I'm just an *old* programmer...
|
|
|
|
|
There comes a point where all these lamdas and expressions become much like Regex. It may be compact, but debugging and validating it is a nightmare. There are only three constructs we need process, decision and loop 
Carpe Diem (Seize the fish)
|
|
|
|
|
You don't have nearly enough calls to libraries that have interfaces that reference other libraries, all using dependency injection and so on.... so that getting to the code that does the 2 + 2 is fully a dozen files deep in an outdated package that is no longer maintained.
|
|
|
|
|
Cool kids like functional programming, so this is the new fad. Microsoft evangelists play for them.
|
|
|
|
|
Sad to say, C# is beginning to look more like JavaScript. The readability is lower and with more linq expressions, it takes longer to understand what the code is doing. For true engineering quality code, it should be more readable so there is less wasting of time understanding it.
|
|
|
|
|
I always knew it would come to this. I can see the case for using lambda functions in certain situations but I always regarded their introduction into C# as a bad move due to their potential for abuse. Sometimes adding N dimensions of abstraction is not a good move. I mean, shall we all start doing maths in base 90 just to use fewer digits? How about we join together n to the power of p math opeartors into newer short-hand operators, just to make that calculus even harder to follow? Just think - one hundred lines of calculus could be comprised into a single line!
|
|
|
|
|
cryptic syntax to programmers in other languages. that's why i don't like it.
i always try to write the code in a style that is familiar to all languages.
when as a pascal programmer i started using c it affected my future pascal code. when i got better at javascript it affected my future c code.
this monday at work they told me to use this syntax for delegates (given int add(int a, int b)):
Func<int, int, int> x;
x = add;
instead of:
delegate int X(int a, int b);
X x = add;
i prefer the later, because it's more language tolerant.
typedef int (*X)(int, int);
X x = add;
type X = function(a, b: integer) : integer;
var x: X = add;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
too. It's so wrong, it has to be right! 