> Then with static using directives, you don't need to spell out the namespaces.

Static using directives! Certainly a useful tool, thank you. I had been away from the .Net universe for a while and I think I have some more catching up to do. Some of the newer changes in C# help a lot with reducing code heft, even though it makes the language more complex.

However, the Framework seems to be headed in the opposite direction when it comes to simplicity. Here's for example the IOptions pattern: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/co...

I really wish the documentation for things like DI, IOptions and ILogger were moved out of the ASP.NET documentation. Trying to decipher from the documentation how to use these in a non-ASP.NET project is needlessly complicated.

It's getting pushed out of ASP.NET with the "Generic Host" efforts. It's still for the time being in ASP.NET documentation, but you see it's moving in that direction.

https://laurentkempe.com/2019/09/03/WPF-and-dotnet-Generic-H...

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ho...

The asp configuration thing is complicated but powerful. If you don't want that, you can just use ``Environment.GetEnvironmentVariable`` and be done with it.

Plus it’s barely any extra work to load settings from environment variables. And it lets you write code agnostic to where the settings are coming from, and then choose to load them from environment variables, a file, hard coded values, etc.

Makes testing easier too because you don’t have to write a fixture around your settings. Just build the class with known setting values without writing code purely for testing.

I have found that large partial classes declared across many physical source files creates lots of issues with intellisense throughput. At 50+ partials, you are looking at solid 10+ second delays in the IDE between when you typed something naughty and when you are informed of it. This behavior has been replicated across many different computers and versions of visual studio, so I think it's just a fundamental limitation.

We have some solid use cases for free floating functions (e.g. business rules that need to be able to arbitrarily invoke each other) which we ultimately decided to scope to one public function per class. This allowed for some other interesting advantages in terms of consolidating tightly-coupled business logic that was formerly spread across the codebase (e.g. items used only by the one function - mappers, request/response models, private utility methods, etc). We even explicitly duplicated out some logic in order to enable completely isolated verticals of BL.

Don't get why people want floating functions. It makes easier to do bad coding and architecture imo. At least you must namespace them;

Consider something like the Math class. In practice it just works like a namespace for math-related functions. The only reason to have a class is because the language requires it.

It would certainly be cleaner without having to define a useless class.

Well, a static Math class always did make perfect sense to me. Never bothered me. Even after I discovered languages that allow you to define functions everywhere, I still prefer static classes; As long as there's no performance penalties, I'm good. In fact, static classes method calls are really fast;

Yeah, except I like that Log() isn't already a reserved function name.

I don't think anyone is suggesting the function names should be reserved names. They would still exist in a namespace.

I don't really understand how this is significantly different than having a static class with the function