Skip to content

Instantly share code, notes, and snippets.

@pielegacy
Last active January 7, 2024 06:59
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pielegacy/e2a0b1424038af92f99497790737bd96 to your computer and use it in GitHub Desktop.
Save pielegacy/e2a0b1424038af92f99497790737bd96 to your computer and use it in GitHub Desktop.
Various opinions on programming

My Various Programming Opinions

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.

Loops vs Functional Array Methods

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);
}

Ternaries

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.

If statements and braces

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.

Meaningfully Abstract

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment