Writing code in away of “telling story”
Everybody in this country should learn how to program a computer …
because it teaches how to think — Steve Jobs
The most common mistake programmers do is assuming they write code for a machine to read. While technically that is true, this mindset leads to the hell that is other people’s code.
Write a code is a great way to express yourself. Creatively, Intellectually, and getting the satisfaction from your created something. But write the code is for us, it’s for humans and we have to be able to tell the stories that we want to tell each other through code.
Our puny brain can handle a very limited amount of logic at a time. While programmers proclaim logic as their domain. The more logic our app has, the harder it is to change it or introduce new people to it.
Whether we are writing a novel, a short story, an article, or code, our audience is always our fellow humans. The computer can interpret the statements whether we use the most concise way of writing an algorithm or whether we use the most readable way. Sometimes we will care about the optimization of a line.
Code should be written for humans to read, but data should be designed for machines to read.
Simple
Before writing code, analyze and predict, what your customers/clients need, then select MVF(Most Valuable Features) that you can develop with good quality in a short term. Good code is simple, it’s obvious it’s boring.
It’s very important and it’s very go thing to think, we will also want to have kind of good glance ability of code. Code should be all self-similar and familiar and same as each other and as well as being the same within one team and ideally, we should have one way to do something. Don’t write complex code. More it simpler than fewer bugs it may have and less time needed to debug them.
If the code isn’t easy to read, the structure is already a monument. You can change small things, but big changes — the kind that every onset goes through almost every month — are just as enjoyable as a root canal. Once the code reaches a state where it is difficult to read, calamity and suffering are upon you. Remember code is for humans
Make Short File
Limit the length of your files to one-page editor, and make each file do one thing. Can’t you cram all your logic into tiny modules? Put all the logic in small modules or packages so that other people will understand your code in a reasonable amount of time.
And thus when the development will be carried out in the future it will be easier to do. Provide descriptive names for variables and functions so they are easier to understand. If necessary, give comments so that it is easier for other people to read the intent and purpose in each code block that we make.
don’t obsess over the performance of code, obsessed over making it clear
Review
The main purpose of code review is to improve our solutions while learning new technologies and techniques. Implementing an effective and efficient code review process is not easy. So writing code that is easy to read by humans, so that reviewers will find it easier to understand when there are additions or changes to logic in one or more block code.
Code reviews are classless: being the most senior person on the team does not imply that your code does not need review. Even if code is flawless in the rare case, the review provides an opportunity for mentorship and collaboration, and, minimally, diversifies the understanding of code in the codebase.
What to review? There is no eternally true answer to this question and each development team should agree on its own approach. Some teams prefer to review every change merged into the main branch, while others will have a “triviality” threshold under which a review is not required.
The trade-off is between effective use of engineers (both authors and reviewers) time and maintaining code quality. In certain regulatory environments, code review may be required even for trivial changes
Reviewers may possess knowledge about programming techniques or the code base that can help improve or consolidate the change; for example, someone else may be concurrently working on a similar feature or fix.
Positive interaction and communication strengthens social bonds between team members.
Motivation
Consistency in a code base makes code easier to read and understand, helps prevent bugs, and facilitates collaboration between regular and migratory developer species.
Thanks for reading . I hope you understood why it is important to write clean readable code, because we write it for humans. WE DON”T WRITE CODE FOR MACHINES, And it’s not hard to write clean code.
