Unlock the secret to writing clean code, 4 non-technical tips for junior software engineers.

Unlock the secret to writing clean code, 4 non-technical tips for junior software engineers.

Writing clean code can seem daunting to new engineers, but it is an invaluable skill that will improve the quality and maintainability of your work.

What does clean code mean for an entry-level developer??

How can somebody with no or little commercial experience effectively write code?

Let's go over 4 top tips which will help you to write better code. Do not worry, you do not need to read Uncle Bobs' book for this one!


  1. KISS
  2. Naming conventions
  3. Self-documenting
  4. Styling conventions


Keep It Simple Stupid?

KISS, we all know it. We have all heard it. Never has it been more applicable then in writing code.

Simple code is often easier to understand, maintain, and debug than complex code. Try to use simple constructs and data structures, and avoid overly complex algorithms or design patterns.

Often as entry-level developers, we tend to want to impress our peers or overcomplicate our solutions. This is down to experience and improves with time.

What can help you when starting is to understand the problem at hand. Write a solution and then go back through it. Think about what you have written. Does it:

  1. Solve the problem
  2. Is it easy to read
  3. Are you using unnecessary loops
  4. Do you think there is a more effective solution

Asking yourself these questions before creating a PR can help you to iterate forward and try new techniques.


Use meaningful names

Did you ever think writing meaningful variable names would have such an impact on your code that it made it to this list?

Use meaningful and descriptive names for variables, functions, and classes.?

It will make your code much easier to understand for other developers and yourself when you come back to it later. Using generic names or non-descriptive names will come back to bite you in the ass, especially for larger and more complex code bases.

Clear naming makes code easier to read and follow and allows other developers to be able to understand what a function is doing from just the name.

An example could be getCustomersLastNames() vs something more generic like getNames(). Be specific.


Write self-documenting code

Write code that is easy to understand by adding comments and explanations where necessary. It will make it easier for others to understand and work with your code.

It can be a bit of a catch-22 situation at the same time. You do not want to litter your code with comments everywhere. Writing clean code and having good naming conventions removes the need for comments.

If you find you are doing a complex mutation in your code, it is a great idea to write a comment explaining what it is doing. It helps others to know why it is there and the job it is doing.?

It is a prime example of when and how to use and write comments.


Follow a consistent style

An example is if you are in a code base which uses try-catch over .then(), follow what everyone else is doing. Most code bases will follow the latest conventions.

Sometimes in legacy code or if you have been taught a different approach it can be a little difficult to adapt. Read through the code base, read any documentation from your company and try to follow the coding style that has already been implemented.

If you would like to implement a new style, communicate it with your team. Explain why what you think the benefit would be and how it can be bought into the existing code base with minimal distractions.

If you took some value from this then as always, please share like and drop your thoughts and comments below.

Do not forget to follow and check out more of our articles The Junior Developer Survival Guide

James Alderman

Digital Marketer (DipDM) | Frontend Developer (React, JS, Tailwind, WordPress) | Digital Portfolio Enthusiast. | Crafting Pixels, Shaping Brands!

1 年

Very helpful ?? Ishaq, naming conventions and keeping things meaningful in regards to descript wording is key (I've found!) - especially when returning to code days, weeks or months later - it's a hard lesson to learn at first. Self-documentation is something I am starting in earnest and I suspect explaining what I'm doing to others will help this. Thanks for the article.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了