Today's best practices are tomorrow's legacy codebase. Don't get hung up on "doing it right" if your code works & your comfortable with it, i.e it is maintainable and it is reliable.
My best advice would be to try and use one of the publicly published coding standards from a big company as there is usually a lot of good knowledge/experience baked into those. Use a linter religiously and do not commit code with lint errors. For every commit, take a step back and think "is this code shit?" If I had to explain it to someone who I thought was a 'better' or more experienced coder than me, would I be embarrassed about it?
Generally you'll get a gut feeling about code being good or bad - how reliable it is, how often you have to tweak it, how easy it is to change etc. If it is hard to make changes to some code or its really buggy or brittle then trust your gut: You Are (probably) Doing It Wrong. That is when you can go and read around different approaches online to see what other people have done to approach the same/similar issue and learn from them. Some approaches will resonate with you, some won't. Make a professional judgement on which (if any) you want to learn from/emulate in your codebase and why you made that decision (the thought process helps - sometimes you just need an 'ah ha' moment to work out your own approach)
tl;dr - beyond fundamentals, everyone does things differently. Do what works for you and what is reliable and maintainable.
My best advice would be to try and use one of the publicly published coding standards from a big company as there is usually a lot of good knowledge/experience baked into those. Use a linter religiously and do not commit code with lint errors. For every commit, take a step back and think "is this code shit?" If I had to explain it to someone who I thought was a 'better' or more experienced coder than me, would I be embarrassed about it?
Generally you'll get a gut feeling about code being good or bad - how reliable it is, how often you have to tweak it, how easy it is to change etc. If it is hard to make changes to some code or its really buggy or brittle then trust your gut: You Are (probably) Doing It Wrong. That is when you can go and read around different approaches online to see what other people have done to approach the same/similar issue and learn from them. Some approaches will resonate with you, some won't. Make a professional judgement on which (if any) you want to learn from/emulate in your codebase and why you made that decision (the thought process helps - sometimes you just need an 'ah ha' moment to work out your own approach)
tl;dr - beyond fundamentals, everyone does things differently. Do what works for you and what is reliable and maintainable.