Sat Apr 09 2022 (3 months ago)
Engineer by mistake!
I am a software engineer by passion
Structured programming is a programming paradigm aimed at improving the clarity, quality, and development time of a computer program by making extensive use of the structured control flow constructs of selection (if/then/else) and repetition (while and for), block structures, and subroutines.
Let's see why coding structure is important
Readable code is simply codes that clearly communicate their intent to the reader. Most likely, the code we write will be read by other developers, who will either want to understand or modify the way our code works. They may need to test the code, fix a problem, or add a new feature.
These other developers reading our code could be our teammates, a consultant, a new junior developer, or even developers from another company who are programming a specific portion of the application. And more importantly, that developer could be ourselves, when we revisit our own code. With most languages, the ratio of time spent reading vs. writing is well over 10:1.
Good code must satisfy 2 qualities:
It must be correct, it must produce a result that is expected when executed.
The code must be easily readable and understandable by ourselves and other developers.
Since our software code can be shared with other developers, we’ll want to make it easier to work with this shared code. To do this, we’ll have to make sure that everyone involved, including ourselves, understands the same thing easily and quickly. Code that is readable for one person is not necessarily readable for another.
The code maintainability is a capability that requires organization-wide coordination since it relies on being able to search, reuse, and change other teams' code. Managing dependencies effectively is often a major source of pain when working with large codebases and large organizations. Tooling that can help avoid problems with dependencies or illuminate the consequences of code changes can improve design decisions and code quality for all engineers, which in turn enables them to work faster and create more stable, reliable software.
Variable, method and class names should both follow a defined structure and be human-readable and descriptive of their intended purpose. Camel case (e.g. camelCase) and snake case (e.g. snake_case) are two examples of how to structure variable names. It is recommended that different types of components (e.g. classes and objects) follow different standards. For example, the standard in many languages is that classes should be upper camel case (or pascal case) while objects should be lower camel case. This standardization can easily be enforced by the tools discussed in the previous section. Not only should variable names be similarly structured, but they should also be sufficiently descriptive. The variable
firstName is much more descriptive than the variable
aString, and its intended purpose is easily understood.
While it may be tempting to develop applications with the minimal amount of lines possible, there is a risk of making the code overly complex. Clever and complicated logic should be minimized, with a preference for verbosity and ease of understanding over complexity. Code should focus more on what is being done rather than how it is being done. Code comments should not be required to explain the logic and flow.
Commenting involves placing Human Readable Descriptions inside of computer programs detailing what the Code is doing. Proper use of commenting can make code maintenance much easier, as well as help make finding bugs faster. Further, commenting is very important when writing functions that other people will use.
© 2021 dsabyte. All rights reserved