|
Yessssss! The BBC are re-showing 'selected episodes' of Total Wipeout. 
Series 1, Episode 1 will be shown a week tomorrow.
|
|
|
|
|
I take it you are excited?
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
To quote Blackadder: "I'm as excited as a terribly excited person who has a really good reason for being terribly excited.". That's another one they should bring back.
|
|
|
|
|
Makes a change from the utter balls in some of their recent output.
|
|
|
|
|
Yep! Also, I got round to watching "Floor Is Lava" (on Netflix) last night. Oh dear!  That will be my first and last episode. It's not just poor. It's incredibly irritating! The only way they could make it worth watching is to replace the bubbly red water, with actual real lava! 
|
|
|
|
|
I'm busy changing part of our codebase to use the new style of using statements: What's new in C# 8.0 - C# Guide | Microsoft Docs
It's nice because it's neater and causes less nesting, but for someone not familiar with it the drawback is that it's less understandable than the classic syntax. What are your opinions on syntax changes like this?
Also, should I pay back the company for the lines of deleted code? :P
|
|
|
|
|
I assume you can still use the "old" way also. That syntax is fine if, like the example, you code would otherwise be;
private void MyFunction()
{
using (var x = new Widget())
{
}
}
as you are reducing the inner nest, but for all other uses (pun not intended) the existing way should defo be used. What you'll see though is people using the new way regardless because if it is "new" it must be "better"  "Why do you want to change this for loop to a linq statement again....?"
|
|
|
|
|
Being honest, I haven't use the new one. But looking at the examples of MS that you linked is not that bad, but if a function is more complex and needs a couple of usings that can get a bit messed up if the dispose is only called at the very end of the function instead of being called when exiting the "active" using.
Have you tested it in such scenario?
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.
|
|
|
|
|
My scenario was mostly adding tracing to a method. So with the old syntax I could either add the braces or for less nesting have a finally where I dispose the tracer.
The other places where I changed it I don't think it matters too much bc that part was at the end of the method. If it were at the start it might make a difference.
|
|
|
|
|
Then just saving one indentation index is not worth the lose of readability or the mess of the execution scopes. At least in my opinion
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.
|
|
|
|
|
Jacquers wrote: but for someone not familiar with it the drawback is that it's less understandable than the classic syntax.
Code is written primarily for other programmers, not for the compiler. It does not matter how elegant your code is, if others cannot understand it.
Jacquers wrote: What are your opinions on syntax changes like this?
If it isn't broken and is properly written, don't fix it. If you are fixing broken code, rewriting poorly written code, or writing new code, you may consider using new syntax.
Personally, I believe that the chance of introducing bugs into formerly working code by such syntactic sugar is not worth the supposed increase in clarity. My opinion might differ if you are writing a completely new module.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Valid points! 
|
|
|
|
|
I don't like it: I don't think it's as obvious what the precise scope of the variable is and where it gets disposed.
For me, it gets "swallowed" by the other code and is harder to work with.
It's a bit like "always use curly braces" even when you don't really have to - they can save a lot of grief when you do this:
if (a == b)
c;
d; And don't notice.
"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!
|
|
|
|
|
Good points, especially the always use curly braces example
|
|
|
|
|
OriginalGriff wrote: I don't think it's as obvious what the precise scope of the variable is and where it gets disposed.
This. Oh, so much this.
To me the curly braces remove all ambiguity and they tell me exactly what the original coder had in mind. Without any brace, could the disposable variable be disposed of earlier than the end of the function? Probably. Where? I don't know, and now I have to study the code more closely to determine that. This syntax is trying to tell me it shouldn't matter to me. And I disagree with that.
|
|
|
|
|
Jacquers wrote: but for someone not familiar with it the drawback is that it's less understandable than the classic syntax.
Anyone and everyone that is writing production code (vs, say, hobby code for yourself and to learn) should know the syntax of the language like the back of their hand. One may not choose to use a particular syntactical sugar, but it should NOT result in a "WTF does this mean?"
Conversely, we all start from a place of "not knowing" and that's fine. But any code a junior dev writes should be reviewed by the senior people and the junior person should be educated. It's better for them, it's better for the company and the code base.
For example, I still feel I write "hobby level Javascript" and when I have to touch something on the front-end for our product, I always ask my coworker who knows Javascript much much better than I to review my changes.
I also look at his commits to learn things!
Writing dumbed down code simply so it's more readable for the less educated - why? That's absurd.
Jacquers wrote: Also, should I pay back the company for the lines of deleted code?
Hell no. They should pay you! Less code == less things that can go wrong.
|
|
|
|
|
In this case the compiled code is the same
|
|
|
|
|
Jacquers wrote: In this case the compiled code is the same
One would assume so. But we don't write code for the compiler, unless we're writing highly optimized kernel code, IMO. We right code so we can read it later.
|
|
|
|
|
Jacquers wrote: busy changing part of our codebase
I've never understood that. Just leave it alone. New code can be written that way but who has the time to go back and change old code just for the sake of style?
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Exactly 
It does not solve my Problem, but it answers my question
Chemists have exactly one rule: there are only exceptions
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Some developers have Weird 'ocd' habits
I also don't want the code base to be outdated, although this change doesn't really change anything.
|
|
|
|
|
Yep, some really have 
I have seen it too often that cosmetic changes/refactorings have brought errors into the software. Ok, you can argue now that our tests were bad.
It does not solve my Problem, but it answers my question
Chemists have exactly one rule: there are only exceptions
modified 19-Jan-21 21:04pm.
|
|
|
|
|
0x01AA wrote: I have seen it too often that cosmetic changes/refactorings have brought errors into the software. Ok, you can argue now that our tests were bad.
I'd argue the tests were valid and the refactoring caused the problems. The new code failed regression testing.
|
|
|
|
|
I'm blaming Resharper for that. It knows about the latest and greatest syntax "improvements" (ahem), and won't shut up until you make it happy.
While it's a useful tool, I've always found it to be a memory hog, and VS is always doing more than its fair share of that. So I don't use it. But one of my coworkers keeps it up to date, and is a big believer in compiling clean (0 error, 0 warning).
But I definitely remember one instance where Resharper made a suggestion that had implications that broke code elsewhere. I know I'm too busy to make changes for the sake of making changes.
|
|
|
|
|
I use the newest language constructs wherever I can.
Mostly because Visual Studio draws a small squiggly line and advises me to change it to the latest standards (and even does it for me).
I do like them though, less nesting, less variables (like with the inline out parameters), etc.
I'm not going to revisit old code unless I have to though.
Don't fix what isn't broken and all that.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
