These aren't supposed to be hot takes as most of these are pretty lukewarm and things that for the majority people follow anyway, thought it would be nice to have them all in one place.
I like to use loops where possible with functional array methods (not sure what the best terminology for it is but in JS it's stuff like map
, reduce
, filter
and in C# it's Where
, Select
etc...).
The design of these array methods is to follow very standard functional programming concepts so methods such as a .ForEach
where nothing is returned from these iterations always bug me.
Taking something like C# having a snippet like this:
var names = new List<string> { "Alex", "Zoe", "Maddy", "Bella" };
names.ForEach(name => Console.WriteLine(name));
This doesn't read correct to me, yes the .ForEach
method reads like .Select
in what it does but it doesn't represent the same intention. Select is supposed to map the contents of one collection to another with (in most cases) no mutations to the original collection. ForEach
is not this, the same code with a loop makes a lot more sense to me as the intention of the code is much clearer.
var names = new List<string> { "Alex", "Zoe", "Maddy", "Bella" };
foreach (var name in names)
{
Console.WriteLine(name);
}
They're good in small amounts and I don't think they should compound.
If you can't easily fit the contents of a ternary expression in one line then change it to an if statement.
Never use a ternary to execute side effects/unrelated code that's not the point of them.
Always use braces - even if it's something simple like:
if (someCondition)
{
return someValue;
}
There's nothing lost by using braces here, the code is still readable and breakpoints can easily be placed within the braces for debugging. If you've worked with me I've almost definitely used the example of Apple's SSL Bug that was caused entirely by a lack of braces in an if statement - maybe a stretch of an argument but there's something worth considering there nevertheless.
Sometimes it's better to just write some "dumb" code instead of trying to abstract away the dumb code.
This applies so much to the C# I write these days, especially when people to try automate the registration of dependencies.
There's nothing wrong with explicitly loading new services with calls such as AddSingleton
, AddScoped
, AddTransient
- you don't need to use reflection to autoload these dependencies.
If you're scanning assemblies to avoid writing a few manual calls to these methods it screams premature optimisation for little gain.
Dependency injection is one of those concepts that in many other languages is considered a bit too magical for what it's doing, I think DI provides a lot of benefits but when you remove calls to the explicit registrations of these services you start moving into territory I'm not a fan of.
It may be the "smarter" thing to remove these manual calls but was it worth it? The custom layer of assembly scanning seems like an overkill addition to avoid a few calls to service registration methods.