How to code? — 8

Start coding as soon as you see something that can be coded. Keep thinking until then.

Continuing from post-7 on the copying algorithm,

we can split it into two functions as below to keep it more clean.

backup(source folder array, destination folder)
1. create the destination folder if it does not exist
2. for each folder in source folder array
   2.1 copy(source folder, destination folder)
copy (source folder, destination folder)
1. create destination folder\source folder
2. for each item under source folder
   2.1 if the item is a folder
     
       2.1.1 copy(item, destination folder\source folder)
   2.2 else // the item is a file
       copy file under destination folder\source folder

With the above reorganization, the code is lot more easier to read. The backup function takes a array of source folders and a destination folder to copy as parameters.

Step 1, it creates the destination folder in the external drive.

Step 2, loop over each source folder and call copy function to copy all contents of every source folder into the destination folder.

The copy function is now a generic function that recursively copies the files from the given source folder into the given destination folder.

step 1, it creates the source folder under the destination folder

step 2, it goes through all the files of the source folder

step 2.1, check if a file is a folder, if so, recursively call copy with the folder as source and destination folder\source folder as destination. This will repeatedly do a depth first dive into the folder hierarchy to unlimited depth.

step 2.2, the item is a file and not a folder. So, just copy it to the destination folder under the source folder created before.

As you see here, this is lot more readable code than the previous one. What we did is split the code into separate functions. One handling the looping over the given source folders and another just doing the copy of a folder into a destination. This was all combined into one in the previous attempt. It is utmost important to keep your code simple. Our brain cannot hold a lot of nested loops and conditions. Though often complex software with lots of checks are difficult to break down, you as a programmer have to continuously think of ways to restructure your code and break it down into simple, readable code. Functions with less number of lines, Splitting large blocks of code into small manageable functions are all things that can be done to simplify.

Often project deadlines with features stacked up leaves less time to make the existing code better. New code keeps coming in. Failing to spend time to think of restructuring code, removing dead code often results in code becoming monstrous and unreadable over time. This takes more time to debug a problem and also fatigue for someone reading it. A well written code with comments itself can reveal the design thinking. There is no need to have a separate design document.

This also means that you can start to put little blocks of code as soon as you realize an important piece of design or algorithm. Thinking of design by coding small parts of it and going back to the board to refine it is one of the ways to understand the problem in hand better.

Read further on post-9.