I prefer classic way too. I only like file-scoped namespaces but top-level statements, implicit and hidden stuff are bad idea - more confused than readable and easy to understand code.
Great video as always! I searched this one out because I was trying to learn more about usings, specifically "static" usings for a project I took over that has them. But still learned a lot nonetheless! Thanks!
Thanks in a million my brother again, Tim! Great content. Awesome. Very well explained. I couldn't find this content--simply put anywhere else. Grade: A++ 💥
Thanks Tim. You have asked us what we think... here a thought... (tongue in cheek) it will be a lot of fun hiding 'global using' statements somewhere two thirds down a 2000 line source file and watching your team mates search for it...
This was an amazing video. I wondered where all the global namespaces were coming from when vs 2019 blows up and a bit of googling to turn things on to get it to build many thanks
Amazing video as always Tim! But I have the question. How can I access the command line params with C# 10 Program.cs? Do I have to write the Main method "in old style" or is there another way of accessing them?
Thank you Tim Corey 😊🙏🏻 Default namespace for each class must be based on file structure. As you show us there is some problems in this feature. If Microsoft fix this problems, it would be very good feature. Less and more clear code for the same job.
Great Vid Tim, Got to say I think I prefer the old way, "Using's, Namespace, Class, Main Method" maybe extra code but to me seems more structured and easier to read ? maybe its something I will get used to, always a learning curve ;)
I prefer classic way too. I only like file-scoped namespaces but top-level statements, implicit and hidden stuff are bad idea - more confused than readable and easy to understand code.
Quickly brushed over the title and rolled my eyes, but then I noticed the video is 43 minutes long. Now I have to wonder, what do I not know about namespaces? I guess I'm watching this video.
Here's a quick preview of things you might have missed (the early stuff is probably just review): namespace aliases, merging namespaces, namespace collisions, and the new .NET 6 namespace updates including global usings, implicit usings, file-level namespaces, and more.
Thank you Tim for this video because it was really helpful. I don't like top-level statements because it makes code too much implicit. You can explicitly define the Program class such as: internal class Program { // ... } public class Program { // ... } and with top-level statements you don't know if auto generated Program class is internal or public. As beginner you don't know about string[] args variable, you don't know about Main() method as well, because it's hidden. I understand an idea about reduced boilerplate and yeah it reduces code but it still makes more confusion than help. If somebody comes from another language (for example Java, Kotlin, C, C++) and see explicitly defined Program class and Main(string[] args) method then it's easier to understand how to do these things in C#. I think following way is more readable and easier to understand, because as you read the code you know what exactly is going on and there isn't any hidden stuff, except global usings. namespace NamespaceDemo; internal class Program { public static void Main(string[] args) { // ... } } Also don't forget that you have to put usings before namespace declaration. Summary: + File-scoped namespaces are nice idea. They're like Java's package or PHP's namespace statements. +- Global usings aren't good or bad idea but I don't think if it's good to import so much usings on default. Look at this file in obj directory. Even Visual Studio highlightes that these usings could be removed. Also, you can use Visual Studio's analyze tools which removes not used namespaces. How will these tools work when it comes to implicitly defined usings from obj directory? - Top-level statements, implicit and hidden stuff aren't good idea because these features introduce more confusion than help. That's my opinion. I hope you or somebody find it helpful.
Just FYI, the class template generates with "file scoped" or "block-scoped" namespace based on the preference set in code style settings of Visual Studio.
I think this stuff is cool. However, my job is to write code examples for other developers. I'm sure that the SDK PM is going to want me to use .NET Core 6, but I'm not sure whether top-level statements and implicit using statements will help or hinder readers' understanding. What are your thoughts?
Hi Tim, a video full of knowledge again. Thanks for that. Tim can you please guide, what is the best approach for implementing waiting room functionality for a crowded application. i.e. I want to serve only 500 users at a moment, and rest to wait in waiting room.
I think a lot of this will make teaching new students a little easier by removing distractions but I doubt I would use them just to save a few lines of code.
Any student learning from this video should question whether programming is really for them. Its riddled with bad habits and a blatant lack of even the most basic understanding of the subject.
A question and a comment: How does this work out for XAML code and the accompanying code behind partial class? My comment: a lot of more stuff is hidden here and needs to find a place in you memory. How will this affect debugging namespace issues? Will it be more difficult? Maybe a good challenge would be to apply these new features to the TimcoRetail project and then see how it affects maintainability of the project. To me it looks a bit like adding some magic to the code and we may get used to it, but especially for inexperienced C# programmers this makes it harder to get started. The namespace concept is not trivial and hiding it makes it more difficult to understand.
This is really cool. One thing I often find annoying about namespaces is that if I create a class and then later move it into another folder, the namespace is left the same. So then I have to rename the namespace. In dot net 6 if I do not specify a namespace and move a file into a new folder, will it now get the namespace of that folder?
Visual Studio Intellisense can automatically rename your file to match your class name by hovering over the class name. Resharper does the same thing, but can also rename the folder to match your namespace and vise versa.
I've also seen an inline using command, e.g. "using Process fileopener = new Process();" I think it has some kind of destructor function, but I'm not sure. Would be great if you could cover this and whatever the encompassing concepts are. For certain functions, I'm at the "grab bits of code from stackoverflow to see if they work, even if I don't fully understand what they do" stage.
Yep, that's confusing. What you are seeing there is a using statement, not to be confused with a using directive (the ones we did in this video). A using statement calls the IDisposable method Dispose after the scope of the using is complete: docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/using-statement
Another idea for a video (please let me know if I've missed something in the archives): passing information between classes / methods and the related topic of contexts. This seems to be the area where I spend most of my time scratching my head at the moment. How do I get THAT to be seen THERE? I know there are various methods (such as explicitly passing parameters by value or returning a result of a method). From playing around after your delegates video, I discovered that they can be used for this purpose too. How about having several methods working on the same List, such as populate list, display list, write list to file? Using globals doesn't seem the right approach here. As there are so many options, your when and why approach would be really helpful to clarify.
about those generated files: why is it so difficult to find them? I have the same issue when wanting to see the blazor generated files. there should be a shortcut
I think that will happen at some point, but really we shouldn't need to find them. They are just one more piece of boilerplate code that we don't need to think about unless we are dealing with an edge case.
The boilerplate reduction adds more complexity for no benefit. The Program file boilerplate clarifies at a glance its structure and its supporting code. Without it, you now have to move among several files to find out what namespaces are in use. Switching between several files to cross reference your code, harks back to C/C++'s include files and precompiled header files. With this new method, everything is still there, but they're scattered throughout your project. Already, we have project configurations split between the project and the config files. If typing out the Program boiler plate is too painful, we already have project templates which is already written for you. Moreover, if you're concerned about clutter, the Program file is often very short, occupying less than one screen's worth. The vast majority of your code is written elsewhere. The feature isn't well thought out.
I disagree that this feature wasn't well thought-out. Your issue is that code is all over. However, how many times have you actually modified your root namespace? How many times have you changed the Program class name? How many times have you changed the Main method's signature? Unless the answer to all three is significantly above 0, these items aren't necessary. Code is meant to be read. Stripping away the redundant, frankly irrelevant information makes it easier to read the actual relevant code. If you really don't like the new template code because you need to see the root namespace, the program class, and the main method declaration then just use them. You can even create a template that brings them back for you. You haven't lost anything. You have just gained an option.
@@IAmTimCorey I don't necessarily agree that this particular syntax simplification necessarily makes your code more readable. The disadvantage of the syntax convention that is being removed here is, of course, that it is the same all the time, is cumbersome and bloats the code. The advantage of it is that your namespace-class structure is actually a tree, and the curly brackets convention made that tree visible. Now, the tree is implicit, and you have to remember yourself where it sits. It looks like a wonderful rabbit hole for writing spaghetti code. This is all well and good if you only write small programs and mostly for yourself; you can choose your poison. But think of a 30,000 line codebase with complex interdependencies where 15 programmers over the years have each used the convention they liked best...
@Jessica - I’m not sure I understand your point. Developers won’t be choosing how they want this set up. It either follows the normal convention (which follows the folder structure) or they explicitly type it out. Those are the two options. There is no allowance to “do your own thing” and make a mess. Nothing is really hidden either. The namespace follows the folder structure, so we can see what it it will be. We just aren’t seeing it twice now.
@@IAmTimCorey I think @Jessica is saying what I'm saying but with a bit more detail. In a nutshell, great designs are elegant in their consistency and clarity, allowing their users to use their intuition instead of requiring instruction. In your web api video, you mention why is there all this ceremony with Program class and its main method, since it's never called. There are cases, however, when you might want to call main directly, say execute an application without going through the shell by loading the app's assembly and executing the Main method directly. It's also possible to change your application's entry point via configuration, so Program.Main can be changed. When you hide the boilerplate of Program.Main, you're replacing it for confusion. As @Jessica points out, the boilerplate clearly illustrates the tree structure of your applications and its namespaces, which may or may not be mirrored by the file system. It also makes it abundantly clear that your program is in reality an object just like any other object in .NET. This concept is lost among newcomers, especially future ones who have never seen the boilerplate. Moreover, given how infrequently we even touch the Program.cs, and the little code contained therein, hiding it brings a significant cognitive cost for no benefit. Not to ruffle your feathers, but I see this feature along with others as sales fluff. It's a cheap attempt to increase .NET adoption by making it familiar to other development environments and frameworks. Instead of selling the consistency and the intuitive structure of .NET, they are borrowing inferior conventions over to .NET, namely the convention of organizing namespaces around the directory tree. You can also see this in how Microsoft built Blazor around the component architecture used by Angular, instead of sticking with its MVC architecture.
Does the ammount of classes in a namespace affect the compiling or loading time of the app? Exaple (a) namespace vehicles has car.cs truck.cs plain.cs helicopter.cs boat.cs submarine.cs Example (b) namespace land has car.cs truck.cs ; namespace air has plain.cs helicopter.cs ; namespace sea has boat.cs submarine.cs ---> If I have to add motorcicle.cs in (a) Iam "using vehicles" but in (b) Iam "using land" . Does It affect the performace of the app in any way?
I really like .net 6. This was a good video because until now, I never knew how to have more flexibility with namespaces in .net 6. Any company who upgrades to .net 6, its recommended to completely redo their projects to take full advantage of the features of .net 6 and makes the projects much easier to maintain.
Not immediately, no. Don't fix what isn't broken. There is no need to make namespace changes just to gain back an indent level in existing code. This will be for new code going forward.
gr8 vid like always. please can you make a vid about web API testing i do not know how to apply tests (unit, integration, e2e) on an ASP.NET (.NET 5) project
I got to say, i would prefer the old way to be the default, not because i don't like the new way, i think that's great for people whom already Know the language but it will be mach harder for new developers to understand all the new implicit stuff
I'm not sure these are good features. For the sake of reducing the verbosity of the code you get to browse the folder structure to figure out what namespace you're working on. Hidden using statements, hidden class names, hidden namespaces. My initial sense is that this will cause complete confusion in any sufficiently large project. I hope I'm wrong.
The class can only be hidden for Program in Program.cs. All others must be visible. Namespaces are trivially easy to add back in with visual studio's built-in quick fix.)
Marko you're totally right. I prefer classic way too. I only like file-scoped namespaces but top-level statements, implicit and hidden stuff are bad idea - more confused than readable and easy to understand code.
Hmmm... something about this video reminds me of walking by Radio Shacks in the mall and whipping out a few lines of BASIC before walking away 8^) Anyone that was born before the 80's knows what I'm talking about LOL
@@IAmTimCorey I was actually referring to: 10 PRINT "TIM IS COOL!" 20 GOTO 10 But you bring up an important point! It is refreshing to get going quickly without a ton of overhead.
Hey, I'm pretty sure I have the copyright on that code you just wrote there. Don't worry, though - I let anyone use it without attribution since the attribution is built-in. I wrote that code in about 1992.
@IAmTimCorey You can tewner the best of both worlds. With just a few lines of comments, they make it easy to find things, and document the code at the same time. /// namespace /// Start of the Main() ... /// End of Main() Another Class or whatever. Regards!
It's sad and upsetting that his free videos are better than the videos in a course you paid $500 for. Still isn't a great explanation of namespaces, but better than what's in the C# Mastercourse. So for those who didn't lose $500, go treat yourself to a nice meal with the money you saved.
If I went into this depth on every topic in the C# Mastercourse, it would be easily 20-50 times as long (and much more expensive). The purpose of the Mastercourse isn’t to go into incredible depth, it is to give you the 80-90% you need to do the job as a developer. There will always be more to learn.
Yeah, I am not a huge fan of this... it saves code, yes, but really creates more guess that messes up readability. Suddenly, the code no longer TELL me openly what is going on step-by-step. Yes, there is far-less code to look at; there is also a lot less information that is essential to your application, especially when you have to debug. In code, I am not at all a fan of things that are implied... And I have the same issue with code like this: if (true) Console.WriteLine("Condition met!"); else Console.WriteLine("Condition not met!");
I'm assuming you mean the empty Program.cs file. I can understand that. It isn't really ideal for new developers, which makes it not as ideal in general (since we can add new devs to the team at any point). However, I also see the benefit. The good news is that it is optional and can be turned off (all of these changes are).
@@IAmTimCorey Yes, the out of the box empty Program.cs file in .NET6. And yes, there are benefits to it, as i said you simplify things but you also take away overview of what is really going on and push it behind the scene as you do with Entity Framework. Is it a good idea, bad idea? I'll tell you whwn you do your next course on RUclips or the ongoing TimCo peoject and switch it to .NET6 (if you do). .NET6 for me as far as work is concerned lies waaayyy out into the future for me sadly, so it would absolutely be a follow-along RUclips kind of thing for me. :-( But that I also DO look forward to. Between four kids, wife, and work, its hard pressed otherwise.
@@tomthelestaff-iamtimcorey7597 IT was not so bad. At least we did not need to wait for version 10 to be able to create a time management system with the proper field formats ;-)
Best teacher ever, thank you , can you do a lesson on the Encapsulation, abstraction, inheritance, polymorphism
I will add it to the list. Thanks for the suggestion.
Brilliant tutorial, thanks Tim.
You are welcome.
Excellent explanationtion of the concepts, looking forward to view more of your videos. Thank you for making so much effort, highly appreciate it.
You're very welcome!
I just learnt how to assign a namespace. But well, I learnt something better!
Thanks Tim
Great!
Great video as always! I like explicit namespace declarations and using, but I really like removal of the indentation of namespaces!
Thank you!
I prefer classic way too. I only like file-scoped namespaces but top-level statements, implicit and hidden stuff are bad idea - more confused than readable and easy to understand code.
Great video as always! I searched this one out because I was trying to learn more about usings, specifically "static" usings for a project I took over that has them. But still learned a lot nonetheless! Thanks!
Glad it was helpful!
Thanks in a million my brother again, Tim! Great content. Awesome. Very well explained. I couldn't find this content--simply put anywhere else. Grade: A++ 💥
You are welcome.
Thanks Tim. You have asked us what we think... here a thought... (tongue in cheek) it will be a lot of fun hiding 'global using' statements somewhere two thirds down a 2000 line source file and watching your team mates search for it...
Honestly, I love folks like you.
Thanks,, this really helped me understanding about namespace, top level statement and how it work
Great to hear!
This was an amazing video. I wondered where all the global namespaces were coming from when vs 2019 blows up and a bit of googling to turn things on to get it to build many thanks
I am glad this video was helpful.
🤣
Amazing video as always Tim! But I have the question. How can I access the command line params with C# 10 Program.cs? Do I have to write the Main method "in old style" or is there another way of accessing them?
Same way as before. You can still access the args array even if it isn't explicitly written out.
@@janne_kekalainen thank you
Thank you Tim Corey 😊🙏🏻
Default namespace for each class must be based on file structure. As you show us there is some problems in this feature. If Microsoft fix this problems, it would be very good feature. Less and more clear code for the same job.
Yeah, had to be some quirk of the pre-release software.
The new .Net 6 stuff looks super cool and makes me feel inspired to learn new stuff!
Tim's goal is always to inspire folks, so glad to hear it. Hopefully he had a little to do with the inspiring?
Awesome!
@@tomthelestaff-iamtimcorey7597 Absolutely!
Great Vid Tim, Got to say I think I prefer the old way, "Using's, Namespace, Class, Main Method" maybe extra code but to me seems more structured and easier to read ? maybe its something I will get used to, always a learning curve ;)
I can understand that. The good news is that you can use the "old" way without an issue.
I prefer classic way too. I only like file-scoped namespaces but top-level statements, implicit and hidden stuff are bad idea - more confused than readable and easy to understand code.
Quickly brushed over the title and rolled my eyes, but then I noticed the video is 43 minutes long. Now I have to wonder, what do I not know about namespaces? I guess I'm watching this video.
Here's a quick preview of things you might have missed (the early stuff is probably just review): namespace aliases, merging namespaces, namespace collisions, and the new .NET 6 namespace updates including global usings, implicit usings, file-level namespaces, and more.
You always show new stuff.....Thank you, Teacher.
Thanks for watching
Thank you very much for every tutorial you make!
Thank you for every one you watch and share!
Great overview! Looking forward to .NET 6
Thanks!
Thank you Tim for this video because it was really helpful.
I don't like top-level statements because it makes code too much implicit. You can explicitly define the Program class such as:
internal class Program { // ... }
public class Program { // ... }
and with top-level statements you don't know if auto generated Program class is internal or public. As beginner you don't know about string[] args variable, you don't know about Main() method as well, because it's hidden. I understand an idea about reduced boilerplate and yeah it reduces code but it still makes more confusion than help. If somebody comes from another language (for example Java, Kotlin, C, C++) and see explicitly defined Program class and Main(string[] args) method then it's easier to understand how to do these things in C#.
I think following way is more readable and easier to understand, because as you read the code you know what exactly is going on and there isn't any hidden stuff, except global usings.
namespace NamespaceDemo;
internal class Program
{
public static void Main(string[] args) { // ... }
}
Also don't forget that you have to put usings before namespace declaration.
Summary:
+ File-scoped namespaces are nice idea. They're like Java's package or PHP's namespace statements.
+- Global usings aren't good or bad idea but I don't think if it's good to import so much usings on default. Look at this file in obj directory. Even Visual Studio highlightes that these usings could be removed. Also, you can use Visual Studio's analyze tools which removes not used namespaces. How will these tools work when it comes to implicitly defined usings from obj directory?
- Top-level statements, implicit and hidden stuff aren't good idea because these features introduce more confusion than help.
That's my opinion. I hope you or somebody find it helpful.
Thanks for sharing.
Awesome tutorial...
Thanks!
Just FYI, the class template generates with "file scoped" or "block-scoped" namespace based on the preference set in code style settings of Visual Studio.
Thanks for sharing.
I think this stuff is cool. However, my job is to write code examples for other developers. I'm sure that the SDK PM is going to want me to use .NET Core 6, but I'm not sure whether top-level statements and implicit using statements will help or hinder readers' understanding. What are your thoughts?
Hi Tim, a video full of knowledge again. Thanks for that. Tim can you please guide, what is the best approach for implementing waiting room functionality for a crowded application. i.e. I want to serve only 500 users at a moment, and rest to wait in waiting room.
We appreciate the suggestion and I have added it to Tim's list.
Super useful video!!! thanks,
Thanks for watching.
Hey tim, Nice videos as usual. Could you do a video on creating apps with MAUI
We appreciate the suggestion and I have added it to Tim's list.
Thanks for clarification. how about args in Void Main?
They are still there and still the same. They just aren't displayed. You can access them like normal, though.
What about async Task Main?
I think a lot of this will make teaching new students a little easier by removing distractions but I doubt I would use them just to save a few lines of code.
I can see it being really useful for microservices too.
Any student learning from this video should question whether programming is really for them. Its riddled with bad habits and a blatant lack of even the most basic understanding of the subject.
A question and a comment:
How does this work out for XAML code and the accompanying code behind partial class?
My comment: a lot of more stuff is hidden here and needs to find a place in you memory. How will this affect debugging namespace issues? Will it be more difficult? Maybe a good challenge would be to apply these new features to the TimcoRetail project and then see how it affects maintainability of the project. To me it looks a bit like adding some magic to the code and we may get used to it, but especially for inexperienced C# programmers this makes it harder to get started. The namespace concept is not trivial and hiding it makes it more difficult to understand.
Find a channel from a professional programmer and ask them - this guy doesn't know what he's talking about.
is there a way to configure the .net templates for class etc. ourselves (so can change to the new style namespace)?
Sure, you can create an Item Template fairly easily: ruclips.net/video/3uYN3mDFP-o/видео.html
There is a toggle for the namespace style in visual studio settings, among other c# code style options.
@@janne_kekalainen hmm whats it called? didnt find it
@@LindenMikus Tools => Options => Text Editor => C# => Code Style => General
"Namespace Declarations" in "Code block preferences" category
(VS 2022 Required)
This is really cool. One thing I often find annoying about namespaces is that if I create a class and then later move it into another folder, the namespace is left the same. So then I have to rename the namespace. In dot net 6 if I do not specify a namespace and move a file into a new folder, will it now get the namespace of that folder?
Visual Studio Intellisense can automatically rename your file to match your class name by hovering over the class name. Resharper does the same thing, but can also rename the folder to match your namespace and vise versa.
I've also seen an inline using command, e.g. "using Process fileopener = new Process();" I think it has some kind of destructor function, but I'm not sure. Would be great if you could cover this and whatever the encompassing concepts are. For certain functions, I'm at the "grab bits of code from stackoverflow to see if they work, even if I don't fully understand what they do" stage.
We appreciate the suggestion and I have added it to Tim's list.
Yep, that's confusing. What you are seeing there is a using statement, not to be confused with a using directive (the ones we did in this video). A using statement calls the IDisposable method Dispose after the scope of the using is complete: docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/using-statement
@@IAmTimCorey Thank you - I'll look that up.
Another idea for a video (please let me know if I've missed something in the archives): passing information between classes / methods and the related topic of contexts. This seems to be the area where I spend most of my time scratching my head at the moment. How do I get THAT to be seen THERE?
I know there are various methods (such as explicitly passing parameters by value or returning a result of a method). From playing around after your delegates video, I discovered that they can be used for this purpose too. How about having several methods working on the same List, such as populate list, display list, write list to file? Using globals doesn't seem the right approach here.
As there are so many options, your when and why approach would be really helpful to clarify.
about those generated files: why is it so difficult to find them? I have the same issue when wanting to see the blazor generated files. there should be a shortcut
I think that will happen at some point, but really we shouldn't need to find them. They are just one more piece of boilerplate code that we don't need to think about unless we are dealing with an edge case.
The boilerplate reduction adds more complexity for no benefit. The Program file boilerplate clarifies at a glance its structure and its supporting code. Without it, you now have to move among several files to find out what namespaces are in use. Switching between several files to cross reference your code, harks back to C/C++'s include files and precompiled header files. With this new method, everything is still there, but they're scattered throughout your project. Already, we have project configurations split between the project and the config files. If typing out the Program boiler plate is too painful, we already have project templates which is already written for you. Moreover, if you're concerned about clutter, the Program file is often very short, occupying less than one screen's worth. The vast majority of your code is written elsewhere. The feature isn't well thought out.
I disagree that this feature wasn't well thought-out. Your issue is that code is all over. However, how many times have you actually modified your root namespace? How many times have you changed the Program class name? How many times have you changed the Main method's signature? Unless the answer to all three is significantly above 0, these items aren't necessary. Code is meant to be read. Stripping away the redundant, frankly irrelevant information makes it easier to read the actual relevant code. If you really don't like the new template code because you need to see the root namespace, the program class, and the main method declaration then just use them. You can even create a template that brings them back for you. You haven't lost anything. You have just gained an option.
@@IAmTimCorey I don't necessarily agree that this particular syntax simplification necessarily makes your code more readable. The disadvantage of the syntax convention that is being removed here is, of course, that it is the same all the time, is cumbersome and bloats the code. The advantage of it is that your namespace-class structure is actually a tree, and the curly brackets convention made that tree visible. Now, the tree is implicit, and you have to remember yourself where it sits. It looks like a wonderful rabbit hole for writing spaghetti code.
This is all well and good if you only write small programs and mostly for yourself; you can choose your poison. But think of a 30,000 line codebase with complex interdependencies where 15 programmers over the years have each used the convention they liked best...
@Jessica - I’m not sure I understand your point. Developers won’t be choosing how they want this set up. It either follows the normal convention (which follows the folder structure) or they explicitly type it out. Those are the two options. There is no allowance to “do your own thing” and make a mess. Nothing is really hidden either. The namespace follows the folder structure, so we can see what it it will be. We just aren’t seeing it twice now.
@@IAmTimCorey I think @Jessica is saying what I'm saying but with a bit more detail. In a nutshell, great designs are elegant in their consistency and clarity, allowing their users to use their intuition instead of requiring instruction. In your web api video, you mention why is there all this ceremony with Program class and its main method, since it's never called. There are cases, however, when you might want to call main directly, say execute an application without going through the shell by loading the app's assembly and executing the Main method directly. It's also possible to change your application's entry point via configuration, so Program.Main can be changed.
When you hide the boilerplate of Program.Main, you're replacing it for confusion. As @Jessica points out, the boilerplate clearly illustrates the tree structure of your applications and its namespaces, which may or may not be mirrored by the file system. It also makes it abundantly clear that your program is in reality an object just like any other object in .NET. This concept is lost among newcomers, especially future ones who have never seen the boilerplate. Moreover, given how infrequently we even touch the Program.cs, and the little code contained therein, hiding it brings a significant cognitive cost for no benefit.
Not to ruffle your feathers, but I see this feature along with others as sales fluff. It's a cheap attempt to increase .NET adoption by making it familiar to other development environments and frameworks. Instead of selling the consistency and the intuitive structure of .NET, they are borrowing inferior conventions over to .NET, namely the convention of organizing namespaces around the directory tree. You can also see this in how Microsoft built Blazor around the component architecture used by Angular, instead of sticking with its MVC architecture.
Does the ammount of classes in a namespace affect the compiling or loading time of the app? Exaple (a) namespace vehicles has car.cs truck.cs plain.cs helicopter.cs boat.cs submarine.cs Example (b) namespace land has car.cs truck.cs ; namespace air has plain.cs helicopter.cs ; namespace sea has boat.cs submarine.cs ---> If I have to add motorcicle.cs in (a) Iam "using vehicles" but in (b) Iam "using land" . Does It affect the performace of the app in any way?
Nope. The namespaces just affect the naming and naming conflicts. They do not affect compile time or performance.
I really like .net 6. This was a good video because until now, I never knew how to have more flexibility with namespaces in .net 6. Any company who upgrades to .net 6, its recommended to completely redo their projects to take full advantage of the features of .net 6 and makes the projects much easier to maintain.
Not immediately, no. Don't fix what isn't broken. There is no need to make namespace changes just to gain back an indent level in existing code. This will be for new code going forward.
Hope they default namespaces to be autogenerated by following folder structure if not explicitly set to be something else.
Right now it doesn’t but I’m hoping that will happen.
gr8 vid like always. please can you make a vid about web API testing i do not know how to apply tests (unit, integration, e2e) on an ASP.NET (.NET 5) project
I added it to Tim's list for topics to consider. Thanks for recommending it.
I got to say, i would prefer the old way to be the default, not because i don't like the new way, i think that's great for people whom already Know the language but it will be mach harder for new developers to understand all the new implicit stuff
That is a concern and one I intend to spend some time on to help new developers.
What about main function? Wow this is amazing
The Main function is implicit in the Program.cs file.
@@IAmTimCorey so cool
a question regarding namespace: is there any side effect if define a long namespace? (sub-level/sub-folder)
Not really. It just makes it long.
@@IAmTimCorey Thanks for clarifying, this really clear my doubt
I'm not sure these are good features. For the sake of reducing the verbosity of the code you get to browse the folder structure to figure out what namespace you're working on. Hidden using statements, hidden class names, hidden namespaces. My initial sense is that this will cause complete confusion in any sufficiently large project. I hope I'm wrong.
The class can only be hidden for Program in Program.cs. All others must be visible.
Namespaces are trivially easy to add back in with visual studio's built-in quick fix.)
Marko you're totally right. I prefer classic way too. I only like file-scoped namespaces but top-level statements, implicit and hidden stuff are bad idea - more confused than readable and easy to understand code.
Hmmm... something about this video reminds me of walking by Radio Shacks in the mall and whipping out a few lines of BASIC before walking away 8^) Anyone that was born before the 80's knows what I'm talking about LOL
You're right, it does feel that way. We can get up to speed very quickly and just write code. Man, that's a throwback.
@@IAmTimCorey I was actually referring to:
10 PRINT "TIM IS COOL!"
20 GOTO 10
But you bring up an important point! It is refreshing to get going quickly without a ton of overhead.
Hey, I'm pretty sure I have the copyright on that code you just wrote there. Don't worry, though - I let anyone use it without attribution since the attribution is built-in. I wrote that code in about 1992.
Happy World Teachers Day 🎁🎁
Thank you. Tim is a teacher of the world with his global footprint.
@IAmTimCorey
You can tewner the best of both worlds.
With just a few lines of comments, they make it easy to find things, and document the code at the same time.
/// namespace
/// Start of the Main()
...
/// End of Main()
Another Class or whatever.
Regards!
cool things
Thanks!
What is that auto complete in 7:20 ?
its the new version i think(he is using 2022 )
that thing came from VS 2022 preview
Correct. VS2022 has some even more power code completion suggestions.
Of course you are cool 😉
please add (command pattern) tut. in your list.
I will add it to the list. Thanks for the suggestion. And I'm glad you think I'm cool.
It's sad and upsetting that his free videos are better than the videos in a course you paid $500 for. Still isn't a great explanation of namespaces, but better than what's in the C# Mastercourse.
So for those who didn't lose $500, go treat yourself to a nice meal with the money you saved.
If I went into this depth on every topic in the C# Mastercourse, it would be easily 20-50 times as long (and much more expensive). The purpose of the Mastercourse isn’t to go into incredible depth, it is to give you the 80-90% you need to do the job as a developer. There will always be more to learn.
Yeah, I am not a huge fan of this... it saves code, yes, but really creates more guess that messes up readability. Suddenly, the code no longer TELL me openly what is going on step-by-step. Yes, there is far-less code to look at; there is also a lot less information that is essential to your application, especially when you have to debug.
In code, I am not at all a fan of things that are implied... And I have the same issue with code like this:
if (true)
Console.WriteLine("Condition met!");
else
Console.WriteLine("Condition not met!");
I'm assuming you mean the empty Program.cs file. I can understand that. It isn't really ideal for new developers, which makes it not as ideal in general (since we can add new devs to the team at any point). However, I also see the benefit. The good news is that it is optional and can be turned off (all of these changes are).
@@IAmTimCorey Yes, the out of the box empty Program.cs file in .NET6.
And yes, there are benefits to it, as i said you simplify things but you also take away overview of what is really going on and push it behind the scene as you do with Entity Framework. Is it a good idea, bad idea? I'll tell you whwn you do your next course on RUclips or the ongoing TimCo peoject and switch it to .NET6 (if you do). .NET6 for me as far as work is concerned lies waaayyy out into the future for me sadly, so it would absolutely be a follow-along RUclips kind of thing for me. :-(
But that I also DO look forward to. Between four kids, wife, and work, its hard pressed otherwise.
The concept of global using reminds me of Informix-4GL in 1990. I am not sure if I like it.
That triggered some painful flash backs. LOL
@@tomthelestaff-iamtimcorey7597 IT was not so bad. At least we did not need to wait for version 10 to be able to create a time management system with the proper field formats ;-)