5 clean code tios every developer should know by heart

Article about 5 clean code tios every developer should know by heart

Published by

Aug 2, 2021

5 Clean Code Tips Every Developer Should Know by Heart

Without any further ado, let’s get it started.

Good Names for Everything

Names are probably the single thing that you get to know things, people, or organizations. Good names are easy to understand, easy to refer to, and easy to remember. You should use good names in your project — for everything — as long as they represent anything.

·         Good Variable Names. Good variable names indicate what data the variables hold. Don’t be afraid to use long names — descriptive names can’t be bad ideas.

·         Good Function Names. Good function names indicate what functions do. When the function is an action, it’s a good idea to start the function with a verb (e.g., getAccountInfofetchGeoDataForUser). When you use a function for its returned value, it’s a good idea to name it as a noun (e.g., calculatedBMI).

·         Good Class Names. Good class names indicate what data the class holds and handles. Class names are usually nouns. Ideally, the names use a single word. When a single word isn’t clear, we should consider two words. In my experience, in most cases, you don’t need three words for a class name to be clear. If it happens, there is a good chance that you may have to revisit the overall design of your data models.

·         Good File Names. When you work on your projects, particularly big ones, you must deal with a series of files. They should be named clearly to indicate the contents of the files. If they’re data models, use the related class names. If they’re utility or helper files, name them to reflect their served roles. Similar to variable names, it’s absolutely OK — or even preferred — to give descriptive file names.

·         Good Project Names. Please don’t have your work folders filled with Project 1, Project 2, New Project 1, and New Project 2. Do give each project a distinct name. It’s not only understood by you, but should be understood by your teammates, and this understandability rule applies to naming in general.

Certainly, another important thing about naming is that you should respect the naming conventions of your language, for instance, whether it’s using camel case or snake case.

Consistent Structure for Everything

Clean code means good readability. One way to improve your code’s readability is to use a consistent structure for everything. Some notable ones are discussed below:

·         Consistent Structure Within Each File. In the beginning, you define the needed dependencies. If you have any variables that you want to use in the file multiple times (something like global variables in Python), you want to place them at the top too. Then you move on to more specific items.

·         Consistent Structure for the Dependencies. Use Python as an example. When you import libraries/packages, you list all imports as separate lines. You first list the imports from the standard library, then third-party packages, and then local modules or applications.

·         Consistent Structure Within Each Class. You define class variables at the top within the class. Following them, it’s a good idea to list instantiation/initialization methods, which instruct the users on how to create instances. Static or class methods (different languages may have different names, but the concepts are similar) are usually placed together. Instance methods are placed together too, particularly those that are functionally more related. For public classes, you can organize methods based on their publicity and priority (the more likely to be used should be placed at the top for better visibility).

·         Consistent Structure for Your Functions. Most of your code deals with functions, so having consistent structures for your functions is key. There are several aspects regarding a function’s structure. For instance, order the parameters of your functions consistently. Place local variables visibly. Don’t mix functions with different abstraction levels.

Keep Things Small

When you have good names and consistent structures, your code should be much cleaner. When you achieve these objectives, it’s time to visit something at a higher level — architectural design. One principle for your project is to keep things small. The goal is not to actually make things small, but when you try to limit the size of each entity (e.g., a class or a file or a function) of your project, you’ll probably be able to enjoy the following benefits:

1.     Your code has better abstraction. There will be less unnecessary duplicates of your data models or functions.

2.   Code reusability will be higher. This benefit is closely related to the first one. By having small components, you can expect that many of these small components will be reused.

3.   It’s easy to make changes and debug. When things are small, it’ll be easier for you to debug and make any corrections.

Refactor Frequently

If you never refactor your project, it’s unlikely your code will be clean. Even if you’re a senior developer, you’ll find out that your project benefits from refactoring. In addition, refactoring isn’t a one-time deal that you do at the end of your project — arguably, there is no end to any project.

You should refactor your project frequently. I don’t have a precise estimation, but if you only work on one project for several months, I estimate that you should refactor every few days. When I say refactoring, I mean it very generically. You can think of it as a reexamination of your code to make sure it follows the rules as we have discussed so far. Refactoring can be multi-dimensional, but some example questions that you can ask include:

·         Are the current working files organized clearly and consistently?

·         Should a big file be broken into a few smaller files?

·         Are the current data models appropriate?

·         Do I need to rewrite some of the functions?

Balance Code and Comments

A good project with clean code can’t live without any comments. However, comments should never or be able to replace clean code. Comments are used to help the readers understand your code.

If your code is unclear when the readers don’t read your comments — it’s a sign that you should work on your code to make it tell the story.

A few things are recommended regarding comments in your project:

·         Whenever you update your code, update the accompanying comments accordingly. Outdated comments cause significant confusion.

·         Keep your comments lean. Only add comments when you think they’re absolutely needed. When you do need comments, try your best to keep them lean — because reading comments itself interrupts the flow of reading your code.

·         Don’t confuse comments with documentation. Documentation is considered more official, while comments are more relaxed in terms of their styles and requirements.

Articles authored by Tony singh

Published: Sep 1, 2021

Published: Aug 31, 2021

Published: Aug 30, 2021

Published: Aug 28, 2021

Published: Aug 18, 2021

Published: Aug 16, 2021

Published: Aug 14, 2021

Published: Aug 13, 2021

Published: Aug 11, 2021

Published: Aug 10, 2021

Published: Aug 4, 2021

Published: Aug 2, 2021

Published: Jul 29, 2021

Published: Jul 28, 2021

Published: Jul 26, 2021

Published: Jul 26, 2021

Published: Jul 26, 2021

Published: Jul 26, 2021

Published: Jul 24, 2021

Published: Jul 21, 2021

Published: Jul 21, 2021