How can you improve code readability by refactoring?

Code readability refers to the ease with which a human reader can understand and comprehend the code written by another developer. Below are the characteristics of readble code: Clear and Descriptive Naming. Consistent Formatting and Style. Effective Comments and Documentation. Readable Control Flow. Use of Meaningful Comments

There is a mix of objective and subjective measures involved in readability. I've documented 7 code virtues that help, and only 2 of those are subjective. Those that are subjective are specific to the group of people in the codebase that contains the source code file (not just the author and compiler). If it helps, think of readability as "the user experience of your source code" - put it in a shape that the whole audience can use and appreciate (including the author and the compiler, but going much further). This "audience-subjective" means that projects may make different choices. Consider that in prose, a scientific paper, a news article, a poem, and a novel have different choices.

Be aware that code readability can be subjective. What's readable for one team might be hieroglyphics to another. The key is making sure that in your team, everyone can easily understand the code. But also, don't refactor the whole codebase in 1 commit because that is a recipe for headaches. If a bug pops up, you will need a lot of time just to find the issue. Instead, make small and incremental changes in separate commits which allow you to easier pinpoint the source of the issues. Bring reliable allies to your code like linters and automated tests (unit, integration, e2e, whatever can help you). With this, you'll make your code readable and easy to update. And let's be honest, in the fast-growing world of tech, who doesn't want that? 😊

One of my friends mentioned that for the most part, naming is your primary tool here. You choose what to name, and what to call it. This may involve renaming existing elements, but may also mean choosing to give a paragraph of code a name by extracting a method, or introducing a named variable or constant in place of a complex condition. Often, though, it involves raising the structural simplicity of code. Choosing the simplest possible representation of an idea (fewest operands, operations, and paths) will often make the code easier to understand. Languages often have better features, just like a foreach is easier than an integer-counting for.

To Refactor for readability involves making changes to the codebase to improve its clarity, simplicity, and understandability without altering its external behaviour. 1.Break Down Large Functions 2.Eliminate Duplicate Code 3.Simplify Conditional Logic 4.Use Descriptive Names (Hardest Part in coding) 5.Remove Dead Code and Comment (Very important and usually ignored)

1. Perform cod review before every checkin 2.Use Automated Code Analysis Tools 3. Refactor Incrementally 4. Monitor Code Quality Metrics while coding

I didn't know what "primitive obsession" meant but, after searching for it, I can tell that I consider primitive obsession to be one of the biggest problems most software architectures suffer from. It seems like people would do everything to do data-type validations, be it creating new attributes, helper classes and methods, special UI controls... but they simply cannot stop using primitive data-types. That obsession with primitive types is really a source of issues and bad architecture.

I would addiotionally also recommend this: - More focus on testing the behavior, not implementation details. Clients don't care about what the internal function returns if we show exactly what is necessary. - Write tests before refactoring the code, so that you can be sure that you have covered the correct behavior you expect after refactoring. - Don't test absolutely everything or write the goal with the goal of testing absolutely every line. We should focus on writing quality tests that can really bring us benefit.

1. Most important thing before testing is to get the code review done. 2. Run the automated unit testing framework if available 3. Do manual unit testing. 4. Do manual smoke testing. 5. Perform regression testing.

The test for readability is to have other people read the code. This is easier, sooner, faster if you are co-creating code with other people (pair programming, swarming, teaming, etc). I am reluctant to refactor any code that doesn't have very fast microtests. Consider adding tests before starting the refactoring.

By sticking to "Clean Coding Principles", you can create code that's self-explanatory. No need for extra documentation in this situation.

Code is for humans to read and coincidently for computers to execute. Computers do not care about the readability of your code. Concepts like abstraction, encapsulation and loose coupling etc are for people who write code. They improve the maintainability and extendable of your software ecosystem. A rule of thumb for documenting code is: - Comments must describe what a piece of code is trying to achieve rather than explaining how it does it. - Have an item in your PR checklist that reminds engineers to make changes to the necessary documentation. - Create state diagrams for feature flows. - Create sequence diagrams, ensure you document inter-service communication flows on priority.

Static code analysis tools like SonarQube make refactoring a breeze. They sniff out and highlight any funky-smelling code, making it easier to clean up.