Single Responsibility Principle

After writing some spaghetti javascript a colleague of mine with waaaay more experience than me explained the idea that each function should have a single simple job.

Run through, and debug the code in your head first.(But then, I learned that when I had to wait for one evening per week when I had to queue with around eight other schoolkids for time on a minicomputers teletype).

It was in my 11th and 12th grade I was taught programming formally (C++). I am courteous and thankful to the teacher who taught me then, I was very lucky to get a talented teacher like him. It was every bit of those fundamentals which helped we along the way and everything I learned there still remain relevant and is the bedrock of everything that I do.

The first thing that I learned was to structure my code so that when I come back after a long break I would still be able to understand it. I also learned that GitHub could be a great way to share code but the repo should be well documented so that new users can easily start using the repo. I always debug code to check whether everything is working great.

I have compiled some best practices here.

I agree to all of them :)

There is one I learned early on that I remember, because I learned it the hard way.

I had some large (GML) script for a GameMaker game. I hadn't indented it, because the code ran the same way anyway.

Some joker friend removed a } when I was away from the computer. I found out not too long after, and put it back.

Then I spent a number of hours over the next week trying to find why my script didn't do what I wanted. Only after a week did I find out that I had put the } back in the wrong place...

I've indented my code very well since then.

I read books, never really had a mentor and had to figure out things on my own. So learning by mistake it was and I made a lot of mistakes. :D Still do.

Tbh I can't remember what the first best practices were. I think it was the book pragmatic programmer 10+ years ago.

No clue, I know that writing my own framework did help and refactoring it 2-3 times did also help.

As a personal side note. I think I dislike the term best practice because as I grew over time it was often used as a phrase to stop the dialog of figuring things out. 'we do this because it's the best practice' and if you ask 'why is this the best practice?' they said some big names or companies as reasoning or some abstract term, but rarely they did explain the underlying concept or reasoning.

And to me that's not how logic works, this is how cults works. To me best practices are very often a very specific implementation of an underlying principle. But these are just my initial thoughts and not conclusions ...

I'd consider the following to be fundamental concepts that noob developers should adopt in order to progress at a faster rate (not limited to noobs though - i still follow these and will continue to do so). I'd also consider everything else to be secondary.

1. Follow good naming conventions.
2. Code comments & provide documentation where appropriate.
3. Get it to work first, optimise after.

To explain each point further:

1. Good naming conventions are key to understand what variables and methods are being used within the code. Messy and inconsistent names for things will cause confusion with not only other developers who look at the code but also oneself when coming back to the code after a long period of time. Good naming conventions also has the added benefit of providing the reader/developer with context and thus the need for comments is reduced.

2. For more complex statements, variables, methods and hacks it is important to outline exactly what it does and how it does it. Again, this provides context for other developers as well as oneself further down the road. Documentation may also be required for any 3rd party libraries that the code consumes, meaning all information regarding the code is in one place. Usually this kind of information is in the readme.md.

3. I have seen many aspiring as well as experienced developers get fixated with optimising code before it needs to be. I came to this conclusion early on in my career and I find it still holds true. To be clear I am not saying don't optimise code. It is important to do so, both for the machines interpreting it and the humans trying to read it. During my career I have developed and seen developed projects which have incredibly tight deadlines and thus fixating on making perfect code could be the difference between being first to market and lagging behind because the Unique selling point is no longer as unique. It's important to optimise, when you have the time, but the project has to be proven to work first.

First one came to my mind is Meaningful variable names I know it is hard :p but by practices, it won't be that hard

My mentors used to tell to keep things simple. To keep if Simple, not for me. Rather, for others who are working with me on shared things, like SOURCE CODE. What I learned is, it is Really not Simple to Keep it Simple. So learned(Still learning probably, 😄) to,

• Document Code(It means, better commenting about what is the code is doing but with a balance)
• Proper package, file, class, method, variable names that doesn't create unnecessary extra reviews.
• Understanding modularity in code and to sell that to others.
• Better source code management with Repo
• Word of Mouth: Talk about the things that helps to keep things simple!

I still follow to comment in my code.

These are the list of the things that I have learn in first few years in programming.

• Comment what you have done. Otherwise even you cannot read and understand your own code.
• Keep modularity of the code.
• Use design patterns as much as possible.
• Keep it simple.