5 Clean Code Tips Every Developer Should Know byHeart

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., get Account Info, fetch Geo Data For User). When you use a function for its returned value, it’s a good idea to name it as a noun(e.g., calculated BMI).

·        Good ClassNames. 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 descriptivefile names.

·        GoodProject Names. Please don’t have your work folders filled with Project 1, Project 2, NewProject 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 namingin general.

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

ConsistentStructure 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 arediscussed below:

·        ConsistentStructure Within Each File. In the beginning, you definethe needed dependencies. If you have anyvariables that you want to use in the file multipletimes (something like global variables in Python), you want to place them atthe top too. Then you move on to more specific items.

·        ConsistentStructure for the Dependencies. Use Python as an example. When you importlibraries/packages, you list all imports as separate lines. You first list the imports from the standard library, thenthird-party packages, and then local modulesor applications.

·        ConsistentStructure Within Each Class. Youdefine class variables at the top within theclass. Following them, it’s a good idea to list instantiation/initializationmethods, which instruct the users on how to create instances. Static or class methods (different languages mayhave different names, but the concepts are similar) are usually placed together. Instance methods are placedtogether too, particularly those that are functionally more related. For publicclasses, you can organize methods based ontheir publicity and priority (the more likelyto 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 severalaspects regarding a function’s structure. Forinstance, order the parameters of yourfunctions consistently. Place local variables visibly. Don’t mix functions withdifferent abstraction levels.

KeepThings Small

When you have good names and consistent structures, your code should be muchcleaner. When you achieve these objectives,it’s time to visit something at a higher level — architecturaldesign. One principle for your project is to keep things small. The goal is notto 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 toenjoy the following benefits:

1.    Your codehas 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 smallcomponents, you can expect that many of these small components will be reused.

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

RefactorFrequently

If you never refactor your project, it’s unlikely yourcode 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 atthe end of your project — arguably, there isno end to any project.

You should refactor your project frequently. I don’thave a precise estimation, but if you onlywork on one project for several months, I estimatethat you should refactor every few days. When I say refactoring, I mean it very generically. You canthink of it as a reexamination of your codeto make sure it follows the rules as we have discussed so far. Refactoring canbe multi-dimensional, but some examplequestions 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 rewritesome of the functions?

BalanceCode and Comments

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

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

A few things are recommended regarding comments in your project:

·        Whenever you update your code, update theaccompanying comments accordingly. Outdatedcomments cause significant confusion.

·        Keep your comments lean. Only add comments when you think they’re absolutelyneeded. When you do need comments, try your best to keep them lean — becausereading comments itself interrupts the flowof reading your code.

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