Hello,
Continuing to my previous posts, I will share my understanding on the Part-3 of the book "The Art of Readable Code" by Dustin Boswell and Trevor Foucher.
Reorganizing your code
For reorganizing your coding so that any person reading it can understand it better, the authors suggest four simple steps.
1.Extract unrelated subprograms
Engineering is the idea of breaking down a large problem and work our way to the perfect solution to it. In your program, decide if each function is doing a specific task. Identify the lines which are supporting the code to extract the final output. I possible try to extract those supporting lines and create a new sub-function.
Common lines of code such a reading a file in C is termed a Pure utility code, which can be written once a separate functions and called at different times of need. Though new languages such as PHP and many others support in-built default functions for this purpose.
Other general purpose code, try to segregate many such general purpose codes in your program. The end result will be much easier in understanding the whole logic of the project and easier maintenance. Also, such codes once developed and perfected, can be easily reused in your next projects.
Keep your project specific logics in separate functions. Also, separate or dissect the logic into smaller sub functions as possible. Provide easy simple interface to all your sub-functions. They should not take in unwanted inputs or cleaner specific single functionalities. By such way more number of people will tend to reuse your code further. As an end result, further rare bugs can be identified solved and your code is matured well.
It has been identified as a lot time and work in your code goes to formatting your input to make able to use third party library or an old code base. Create a rule or directions for the whole project and follow the rules or easier coding and maintenance.
2.Rearrange your code so that it does one thing at a time
Before you jump right into coding, write down all your logics. Separate the logics which can be reused in multiple places in your project like reading a file or logging. Separate the actual project functionality.
Follow a clear flow in your coding, start off with headers, reading inputs, computation and finally output. As mentioned earlier, do not cluster many logics into one function or do not perform multiple logics in one single function. Separate them into smaller more understandable functions as possible, they easier to read and helps in re-usability in future.
3.Describe your logic or program in words first
Apart from writing a clean bug free code, another important ability of a developer is to explain the logic or problem in clean plain text to another person. Before writing or solving the program, it a good practice to write your problem in plain text, carefully pointing out the important points and conditions involved and finally turning them all into code.
Also, as mentioned in previous chapters, knowing the general libraries and common functions can greatly help. Even if you do not know all the functionalities in your project it is better to know their names and get a general idea of what they do. This will greatly help you when you write new functions, if a similar function already exists; full or partially, you can just reuse it.
4.Writing Less code
It is general to get over loaded with ideas and features at the initial stages of your project. But at the end, many functions and code can be unfinished or not used at all. Try to look at your problem in different points of view, question your logic and input as much as possible. The initial time and planning spent on your project can help you in great ways.
Keeping your code base small will help greatly in your project. As the project grows, more source files, unction and libraries are added. At the end the programmers may not remember all the functions. It will become hard to add new code logic at the end state. Hence, it is recommended to break the logic to smaller bits as much as possible and create many common utility classes.
As pointed out earlier, when you are entering into an existing project you cannot understand all functions or logic at beginning. But still take the time and get to know the names and comments about what the logic inside them. This will greatly help you when you write new functions; it will strike you of old similar logic somewhere. You can reuse many of the existing code rather than creating same code again and again. As the project continues, you will hopefully get good understand of the project scope easier and better.