I am Tim Corey. I teach coding online and my inbox is full of questions from current and future developers. I wish I could sit down with each of you and share the answers I know will help you go further, faster in the world of development. This podcast is the next best thing. On this podcast, I will answer the biggest questions people are asking! Send us to your suggestion for a future Dev Questions at https://suggestions.iamtimcorey.com/ To keep the podcast coming, like, subscribe, rate, and share it with your friends and colleagues. See why thousands of students have chosen to learn to think and code like a professional developer at www.DevForge.com.
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
0:00
|
11:26
Why is Microsoft changing things that already work? Top level statements (Program.cs files without a method, class, or namespace), file-scoped namespaces, switch expressions, minimal APIs, and more are all just adjustments to what we already had. So why make these changes? Why is it important? Isn't it just confusing? These are the questions we will answer in today's episode of Dev Questions.
Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.
SPEAKER_02
Why is Microsoft changing C Sharp syntax so much? Recently, there's been a lot of changes to the syntax itself of C Sharp, and those changes seem to be not really taking things out or adding new features, but doing the same thing in a different way. So, why is that? This is a question that's come up quite a bit recently, and it's one I want to tackle in today's episode of DevQuestions. Now, if you have a question you want to get answered, go to suggestions.imtimcorey.com and ask your question there. Hopefully you'll see it answered in a future episode of DevQuestions. So let's talk about some of these changes that have happened recently and why they were made. So as an example of these changes, we have top-level statements. So when you go into your program.cs file now, it's just code. There's no namespace, there's no class, there's no method name, and it's all just code. And that's totally different than every other file in our entire application. We also have file scope namespaces where we say namespace and then give the name and put a semicolon instead of having the curly braces and have everything inside that namespace. We have global usings. So instead of having usings in every file, we put them in a new location, but they apply to all the files. So those are a few. We also have switch expressions, which are kind of like switch statements, but they output a value. And we have minimal APIs, which are just APIs done in a different way. So why don't we have new features instead of just seemingly rearranging what we already have? All right, so let's talk through this because there are really good reasons to do these changes. First of all, Microsoft is reducing unnecessary boilerplate. For instance, when you open up a new uh API project, let's start with a full API project that is a.NET 5 API project, or even.NET Framework, doesn't really matter. But you open up a.NET 5 or before full API and then compare that to opening up a new.NET 6 or 1T7 minimal API. Well, the minimal API project has one file in it. That's everything. That's that's the demo API, that's the setup, that's the configuration, the running, the routing, that's everything. But the other API has a section for controllers, it has a program.cs file, it has a startup.cs file, it has all these other things all over just to get started. Do we need that for every project? Well, there's a lot of stuff there that's kind of unnecessary. We also have uh, for example, the um the using statements we talked about earlier with the global usings now. Well, it used to be that when you started a new class file, you would get oh, four, five, six different using statements at the top, or using directives, I'm sorry, using directives. You get six using directives at the top that were the same. And usually they kind of gray out because you're not using them. Uh you have using system, you'd have uh using system.txt maybe and and others. And then as you start working, it might light up because you're actually using it now, but that's in every single file. Well, why are we repeating ourselves? We're creating unnecessary boilerplate that we could reduce. So that's one reason. Another reason is that we're reducing repetition, like those using directives, where we we don't need to have the same stuff over and over again in all these different places. We're also simplifying the experience. Imagine for a minute that you don't know C sharp, and you decide, I'm gonna start my first C sharp project. And so you you start a project, and maybe you probably shouldn't go here first, but maybe you did open up an API project. Or maybe you're you've learned some C sharp, but now you want to get into an API. And you open up that project and you realize, oh my goodness, I have multiple files and NuGet packages and all this stuff all over. There's a lot of stuff going on here. That can be confusing. Even when you look at a console application, the very place you should start. Well, when you start a new console application in.NET 5, then you have a bunch of using directives, then you have the namespace declaration, which is uh program, and then you have the class, program, and then yeah, the class, um, and you have static void main, and you have all these curly braces and all that stuff. You have the um the args that are coming in, and you get about a line 11 before you start even writing any code. And if you're just starting off, you look at that and say, what is all of this? It what is the the class program? What is the namespace that's named after the project? What it what are the using directives? And so you've got a lot of lines of code that are confusing and they're a barrier to entry. Whereas now, when you start, it just says, okay, let's start writing code. Let's just get to the point of doing something. Now, as you grow, it's going to be you add things to that and you add complexity, but that's a growth over time. Now, so we've got here is we've got really four reasons. So we have our our first reason, which is reducing unnecessary boilplate. We have the second reason, reducing repetition. Number three, reducing the or simplifying the experience, and number four, making it easier to get started. So with all of these, these are good reasons to make the code cleaner, to make the experience cleaner, which does mean that we're gonna have to have changes in the way we do the things we've always done. So I get it, change can be hard. And if you're used to a certain experience, just changing it feels like you're just moving stuff around, but the same stuff's all here. I get that, but unfortunately, we're not the only ones that use C sharp. It's not like once we get into C sharp, okay, now we're gonna close the doors, lock them, and you're locked in, and this is what's gonna be from now on. Change happens. And so this change right here is to make the process simpler, make things cleaner, make things easier, and make it a better experience overall. That's kind of the point and the purpose for all these changes that we get kind of new features, but those features already existed in just a different way. Um, it kind of just changes to how we do things, additional changes. And yes, change is hard, but the really cool thing here is this is where I really applaud Microsoft for how they're doing this, is these changes aren't just being forced on you. You do have the option of not doing most of these changes, if not all. So, for instance, the the top level statements. There's a checkbox in all project types now that says, hey, I don't want that. Check it and you're back to the old way. And the idea of file scope namespaces, you don't have to use them. You can undo the the um the semicolon and bring back the curly braces. You can even use the quick actions refactoring to do it for you. Um, with the global usings, you can turn it off. You don't have to use it. With the implicit usings, you can say don't use those. Um, with null checks and all those other things, you can turn them off. These are optional things for you because what Microsoft is doing is saying, we get it. It's hard to change. And when you've already got, I don't know, 100,000 lines of code written in your application. You don't want to just change all of a sudden because now a new file looks different than all the rest of the files. They get that. And so they've said, hey, these are optional. But over time, we'd love for you to start moving this direction because the fact that these are better ways of doing things typically, and they're cleaner and they're simpler, and there's less repetition, and it does make it easier for people to get on board with new projects. So the changes are optional, but they are something that we can work towards as we move forward in our development. So that's why these changes have come about. That's why you'll see some changes in C sharp syntax that's that they already existed in a different way, but now there's a new way of doing it. We have uh minimal APIs. We can write an API in, I think, three lines now. Three lines of code, and you have a functional, if hello world-ish, uh API. But that's pretty cool and it reduces a lot of those lines of code. Instead of having a hundred lines of code just to get started, now we can start with just three. And we can grow it over time, but it allows us to say, you know what? I don't need a complex API that has tons of controllers. Maybe I just need essentially one controller's worth of endpoints. I can create a minimal API. I'm gonna create a microservice that's 50 lines of code that's an API. Well, that's a great experience for that. And so these are these new ways of doing things will help us do things more efficiently and easier and cleaner. And yet we don't have to abandon what we've done in the past and stop doing the same way. We can still do it the same way we used to if we want to match our styling. Okay, so that's that's my thoughts on the changes with C Sharp and why I think they're really a good thing. And even though it is change and change is hard, I think it is an important thing for the Microsoft team to be doing.
SPEAKER_01
Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamtimCorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.
