My few obvious advices I wish someone had told me when I started coding

Writing code is something that you can learn at school, at some training, or even online. Also, you need only a few tools to start writing lines of code. It’s straightforward to stay focused on the technical part, and it’s a big one, and not to dive enough into some methodology.

Here I would like to contribute with the few obvious pieces of advice I wish someone had told me when I started, to help me write better code.

First … KISS …

… Keep It Stupid Simple!

I’ve seen too many complex functions, especially in front-end development, where some code had to handle complex render logic and do more than it was initially supposed to.

One function = one purpose.

Don’t write too big and complex functions if you can avoid them. Split them into several ones if necessary. Keep your code readable, simple, and functions with as few arguments as possible.

There are plenty of tools at your disposal to simplify functions, and Currying is a good example. It helps you modularize the logic and let you create combinable and reusable functions, … also with fancy writing.

Fa-cto-rize

During my coding training, I was told a very true rule: if you duplicate your code, usually with a copy/paste, for any reason, you can factorize and make it reusable.

Of course, like every junior developer, I duplicated code because it was easier. Then I continued focusing on my exercise and its result without thinking about future maintenance and updates … because there weren’t any!

In the real world, there always are maintenance and updates, and many reasons appear that will push you to fix or refactor a piece of code.

Maximizing reusable code make your product more easily and quickly maintainable. Maybe you can create your own libraries of global classes and functions, so you can simply import and use them everywhere you need.

Get it pure …

… like cristal water!

Pure functions are, by definition, predictable and reliable. You can be sure that it will always return the same result, given the same input.

Using pure functions will drastically reduce side effects during code execution. Of course, your product can not be built only with pure functions, but there are plenty of benefits to using them as soon as possible.

They are easy to debug since errors will be caused by the function itself. They are also lightweight and don’t require any special libraries or frameworks.

Name it …

Name your functions, variables, classes, and folders …, expressing their purpose.

This part is crucial: write your code and choose names for your “future you”!

Remember that you will work again on your code in several months. Your code should be as explicit and readable as possible.

While naming your variables, classes or functions, try to consider their types or what they returns. For example:

for a Boolean variable that will store a process state: isUserRequestRunning, instead of processStatus
for a Numeric variable: amountOfMoneyLeft instead of calcResult
for a function: getUserProfilePicture(), convertEuroToDollar()
and so on

Test it …

… fix it … try it … clean it … push it …!

Testing your code should be essential, especially if your codebase grows. It looks like tedious work at the beginning but shines like the Holy Grail when your project reaches a considerable size.

During my developing experience, I had to upgrade some backend functions that impacted parts I was not working on, but running the tests raised unexpected issues. We could fix everything before pushing a buggy release.

There is also the effective TDD development technique, TDD for Test-Driven Development. If you are unfamiliar with this technique, I recommend getting some information about it.

Long story short: it consists of writing a test function with the expected result and then writing the code to produce and pass the test. Then write a second test with another behavior, upgrade your functionality, and it needs to keep passing all the tests you define, and so on.

Conclusion

In a few words, try to keep your codebase as simple, pure, well named, and tested as possible. It seems obvious, but I know it’s so easy to get trapped by the « I’ll do it later » monster.

You will find many pieces of advice to help you get started with better code writing. Don’t hesitate to share some tips and thoughts.

What can you do to help me?

Please don’t hesitate to:

Like the article
Follow me
Leave a comment and express your opinion
Support me by becoming a Medium member

Happy coding!