When I taught for a coding bootcamp years ago one of the more popular sentiments that people would often share is that they wanted to learn to code the 'right' way. And as someone who had been coding for almost 2 decades at that point, those statements always left me a bit confused.
To start off, I understood (more or less) where they were coming from. They wanted to become moderately decent software developers, in whichever niche they chose to work on. I totally get that part.
My response was usually some esoteric 'there is no right way' statement that probably left some people confused. So today, I'll attempt to break down why the 'right' way probably doesn't exist. Probably.
Code ages poorly
What was once new, is now terribly old, outdated and probably causing some security issue you're unaware of. This happens all the time. And it doesn't mean that you need to delete the codebase and start over. That might get you fired.
If you work for a company that's more established, meaning they have been around for 10+ years, then odds are the code is outdated. And that's perfectly fine. You're job probably isn't to modernize it, it's more or less to keep it running by patching it up as needed and fixing bugs that no one has seen in decades.
Take a look at my blog as an example. This blog is around 10 years old and is written in C#. C# is still around and doing pretty well for itself. But the specific project type that I chose to use back then, was ASP.NET Web Forms. And if you don't know what that is, you're probably in the normal camp.
Web Forms, as far as I know, are still supported by Microsoft. They are still mentioned in the documentation every so often and there is no official 'end-of-life' date on it. They just aren't talked bout very much. But for that reason, it's difficult to work on. The less people talk about a specific technology, the less documentation and bug fixes you'll find online as well.
Alot of what made ASP.NET Web Forms stand out back in the day, is also now standard out-of-the-box features that JavaScript can do readily. So I don't technically use those older features anymore.
Slowly but surely, I've managed to incorporate newer web technologies into this project, and now it's a bit of a hybrid of many things, including some Angular, some Knockout.js and about 2-3 other .NET project types, because why not.
Too many frameworks
Often times, developers get stuck in their tracks before they event start. The decision fatigue is real when it comes to starting a new project, mainly because every framework that pops up that's 1-2 years old is faster, smaller and more future-proof than the last. I won't name any specific ones here, but you know which ones I mean.
And that makes it hard to start anything new. I myself face this constantly when brushing off the dust on my idea book and deciding to start a new project. Should I choose one of the newer C# based project templates, or maybe the latest JavaScript framework that just came out. Or maybe the more established JavaScript framework that's been around for years.
Or maybe I should steer into a new language and learn something new, at the expense of development time. What is the 'right' way?
I've yet to find an answer that makes sense above all the others. And that's because they're all valid. You can choose any of those routes and build the exact same thing that looks exactly the same and functions exactly the same.
And there's a high chance that the code and logic will resemble itself 80-90% of the time. The only real difference is how that code is compiled, interpreted, transpiled, etc.
"Best practices" aren't always the best
The only real place to find 'best practices' is probably at your job working with a lead developer. And that's because 'best practices' really depend on where you work and what you're working on.
For example, microservices might be overkill for a solo developer, while monoliths might be a nightmare for a very large team.
However, if you're a solo dev and you want to build a microservice based app then have at it. It's definitely not 'wrong' in any way. And I personally worked on large projects with large teams before microservices were mainstream and we did perfectly fine, because we designed our workflow to accommodate that.
Technically though, if you are working for a corporation and the tech is so advanced that it requires a very specific configuration in order to optimize on costs and time, then there probably is a 'better' way to do things (for that company).
Readable code vs clever code
Some developers, particularly on the internet, tend to favor clever one-liners for pretty much everything they do. It looks good on film and they get to shorten the amount of time that it takes to actually type out their code.
Other developers, tend to favor readability, meaning explicit declaration of variables for each individual piece of data, and bracket usage and line-breaks wherever it makes sense.
And similar to 'best practices', if its your own code there is no right or wrong way here. I personally favor readability, mainly because most of my codebases at this point are years old and hundreds of thousands of lines each. And sometimes I go months in between adding features.
But if you're confident that you'll be able to come back in a year and make sense of your 6 layer deeply nested function chain, then have at it.
If you work for a company though, things can get confusing in this regard. I've had lead developers that favored readability (most of them), but I've also had lead developers that made it a part of their job to rewrite any and all code into clever one liners.
And I will say now, that clever code was painful to work on. Particularly when things broke, and you had no idea where things were going awry.
The only 'wrong' way
There might not be an exact 'right' way to write code, but there is a 'wrong' way. And that's to not write it at all. That might sound corny, but I bet every developer out there has either postponed some bug fix, or avoided a new project, because they couldn't think about the 'right' way to do it before they even started.
I myself do this all the time. I have a long list of features to add to this blog and new apps to build, but they are still sitting on a queue waiting for me to decide how I'm going to approach them.
Slowly but surely though I'm working to fix that in the coming year. And I think the solution is really in the title of this post. There isn't any 'right' way to do it.