{"id":6836,"date":"2022-02-20T22:01:44","date_gmt":"2022-02-20T14:01:44","guid":{"rendered":"https:\/\/slash.bravefactor.com\/?post_type=resources&p=6836"},"modified":"2024-11-19T18:43:08","modified_gmt":"2024-11-19T10:43:08","slug":"how-to-write-clean-code-6-brief-guide-on-rules-and-principles","status":"publish","type":"resources","link":"https:\/\/slash.co\/articles\/how-to-write-clean-code-a-brief-guide-on-rules-and-principles\/","title":{"rendered":"How to write clean code? 6 brief guide on rules and principles"},"content":{"rendered":"

When Robert C. Martin wrote the book \u201cClean Code\u201d back in 2008, it began to change the world of coding. In early 2000, coding was meant to be harsh \u2013 if not by intention but due to the market practice. However, the concept of clean coding changed the view of many programmers when they started implementing the rules and principles of clean coding. So let\u2019s find out what clean code is, its rules and principles, and how we use it at <\/span>Slash<\/span><\/a>?<\/span><\/em><\/p>\n

What\u2019s clean code?<\/h2>\n

Codes are said to be clean if they are understandable by the entire team without scratching their heads multiple times. In other words, a clean code is easy-to-read, maintain, extend, and change by any developer. That means if you\u2019re an author of a project and pass it on to your colleague developer, but the person cannot understand the code, you haven\u2019t written clean code.<\/span><\/p>\n

Rules to write clean codes to avoid mess<\/h2>\n

You can save your entire team from having a few extra cups of black coffee every day by writing clean codes. All you need to do is to follow these rules:<\/span><\/p>\n

Be all downhill<\/h3>\n

The first rule is to do things in the simplest way possible. Try to write codes without complexities. If you got a file with a lot of complicated codes, try to fix those before going forward. Doing so will ease coding in the upcoming stages. Also, try your best to view and overcome problems from their roots.<\/span><\/p>\n

Design rules<\/h3>\n

Always keep configurable data on the highest level but avoid over-configurability. Also, it is best to use a single interface to different types of entities (polymorphism) to switch\/case or if\/else statements.<\/span><\/p>\n

Moreover, it is wise to break up multi-threading codes and apply the dependency technique. Additionally, always follow the \u201cLaw of Demeter\u201d (LoD).<\/span><\/p>\n

Understandability<\/h3>\n

Just be consistent in your way of doing things. <\/span>For instance, if you have a particular method to code a specific action, make sure that all similar actions are done in the same manner.<\/span><\/p>\n

Likewise, put all boundary conditions processing in one single place and include explanatory variables when writing codes.<\/span><\/p>\n

Next, avoid using negative conditionals and logical dependencies by writing codes that aren\u2019t dependent on any other element in the same class.<\/span><\/p>\n

Give easy names<\/h3>\n

First things first, give names that are easy to understand. You can do this by:<\/span><\/p>\n