REAL-WORLD COMPUTER PROGRAMMING FOR KIDS
STEP 33: CODE COMPARISON AND A GLIMPSE INTO WHAT MAY BE YOUR FUTURE (SOURCE CONTROL TOOLS)
Hello all, and Welcome Back!
In this Step, we will consider Code Comparison in general, and a specific Code Comparison tool. First, though, you may wonder:
What is Code Comparison? Why is Code Comparison Useful? andHow Is It Used?
Let’s tackle these questions one at a time:
What is Code Comparison?
“Code Comparison” is when you compare code. Okay, on to the next question.
Just kidding. What it’s really about is comparing a particular block of code with a different version of that same block of code – in other words, it’s like traveling in time back to a former version of the method or the file. So what you’re doing is comparing code written at one time with code written at another time. It can show you how much the code has changed in the meantime. But there is more to it, which leads to the next question:
Why is Code Comparison Useful?
As described so far, it sounds like Code Comparison is just a way of measuring how much code has changed, or to “geek out” over which changes have been made. But, again, there’s more to it than that.
Mainly, Code Comparison tools are used to see what code changed when a bug was introduced. Let’s say, for example (not that this would ever really happen) that a certain portion of the code was working fine, and then an additional feature was added, but that new code caused a different bug (or two ... or a few) to arise. Or possibly the code won’t just work wonkily, but won’t even compile at all after the changes were made. It may be that you were so busy adding code here and changing code there that you don’t know where the bug was introduced. The changes you made are scattered all over the place. By using a Code Comparison tool, it will show you exactly what changed, and where.
How Is Code Comparison Used?
The first thing you need to do in order to be able to use a Code Comparison tool in the first place is to save the current version of your code from time to time. At the minimum, you should save your code once each day that you work on it. How often you save your code depends on how much work you are doing (how much you are changing it), though. There are times when I’ve saved a new version of my code every half hour or so.
So now for the crux of the biscuit cookie: When you want or need to compare one version of your code with another version, you can do it by “hand” (actually, by eye), but that is overly tedious, difficult to do right -- and fraught with peril for that reason (this may seem overstated, but you may get so irritated trying to do it that way that you blow a gasket or a fuse or something), and have something like this happen:

Photo by Yosh Ginsu, from unsplash.com
You are now doubtless saying to yourself, “There must be a better way!” There is. Rather than endanger yourself and your surroundings that tedious way, you can use a Code Comparison tool to semi-automate the process. There are many, but one of my goals on this Journey we are taking together is to point out to you free tools to work with (such as Visual Studio). In this case, I recommend that you try the free online tool at https://www.diffchecker.com/
I will now demonstrate that with two versions of the code from our app. I will compare the current version of the code from Form1.cs with a version from a week ago (plenty has changed in that time).
When we go to the web address mentioned, we see this:

You see there is an “Original Text” section on the left and a “New text” section on the right. It doesn’t say, “Original Code” and “New code” because you can use this tool with any text files – it could be a letter to your grandmother thanking her for baking you that nice apple pie, or those ginger snaps/molasses cookies, or tasty cinnamon rolls (give her my address if that is the case; Taste-testing those types of health food is a hobby of mine).
I copy-and-paste the code from last week into the “Original” pane, and the most recent code in the “New” pane:

Select the “Find Difference” Button below the two Text panes. The two versions will now look like this:

Notice that in the six days between these two versions of the code, DiffChecker says there have been 87 Removals and 225 additions (upper left corner). It highlights the lines that have changed with a different color, and bolds the areas where the differences are. For example, notice line 16, where it has noted that “string originalQuestionNofN;” has been commented out in the newer version of the code.
Also, notice on line 39 in the old (“original”) code and line 42 in the new code the change in calling the separate method (old) to directly calling the code (new) that the separate method was calling in-place, or inline (cutting out the middleman):

Here’s another example of something that can really stand out:

Do you notice what it is? The new code has a call to InitializeForm whereas it is absent from the old code. If a bug arises, and you trace it to this method (either by stepping through the code, looking at the Exception message that is displayed, or by logging it), this can be a clue as to the culprit. Something different is causing a bug. What is it? Could it be this new code you added? Quite possibly. To test it, you can comment that line of code out, run the app again, and if the error goes away, you’ve probably found the culprit. Now you will want to look at it in more detail so as to determine how you can still accomplish what you want to do, but without the error.
Note: I’m not going to sugar-coat it. You will deal with a lot of bugs when you’re coding. Sometimes it gets very frustrating and tedious. You can get irritated and agitated. What I recommend to you as a soothing influence at times when you feel like throwing the monitor (the computer screen, not the big lizard) through the wall is to listen to Johann Pachelbel’s Canon in D (or suchlike music – J.S. Bach’s “Jesu Joy of Man’s Desiring” and “Air on the G String” and “Sleeper’s Awake”, in particular). Don’t think I’m a fuddy-duddy (even though I might be in some ways) – I also like modern, “loud” music (a lot! including Laura’s Rock version of “Canon”), but there’s nothing like a dose of Pachelbel’s Canon in D when you’re feeling grouchy or over-stressed. It’s not just for weddings. The man was a genius, and a beautiful soul. I didn’t know him personally (his death and my birth are 252 years apart), but nobody but one with a truly beautiful soul could have composed such a sublime and majestic masterpiece. In other words, I kind of like that composition. A little.

So, back to the Code Comparison. The code changed a lot in those six days, and it’s a bit overwhelming to take it all in. Provided you save your code often, there shouldn’t be too many differences between your last working copy and the new problematic one. That makes it easier to track done what is causing the bug, of course.
For example, let’s now load the second-most-recent version of the code along with the newest (hit the “Clear” Button on the page, then refresh the page to go back to blank areas for the text to be pasted into). There are far fewer differences when comparing these two, but there are some, of course, such as where we changed the Exception handling code by adding the Exception Logging, as shown here:

So there you have an introduction to Code Comparison – what it is, why it is useful, and how to use one free tool, DiffChecker.
There are more full-featured versions of Code Comparison tools, but they usually must be downloaded and installed (perhaps no big deal to you), and usually cost money, too (perhaps a bigger deal to you).
And caveat emptor! (which means, “Wear an empty tie!” or something) – sometimes tools will advertise themselves as free, but then it turns out they are just a free limited-time trial, and after the trial period ends they will continually harass you to purchase them and make it difficult for you to completely uninstall them. So...be careful. I’m not saying it’s not worthwhile to pay a little for such tools, but make sure you do some “comparison shopping” (no pun intended) first.
Two that I do recommend are Beyond Compare and KDiff. KDiff is free to download (not as a trial); they do accept donations.
Related to Code Comparison tools are full-fledged Source Control solutiions, which can be handy even for solo/hobbyist programmers, but are necessary when working with a team, and you need to collaborate on projects – especially if multiple people are working on the same code at different times. We won’t go into this subject much, at least not yet, but this is just to let you know that if you decided to pursue software development/computer programming as a profession, you will probably need to familiarize yourself with Source Control packages, such as Git, Microsoft Visual Source Safe, or something else. Using these tools properly allows you to assure that you are not overwriting someone else’s code, and vice versa. You “check out” code to work on it, and then “check it back in” before anybody else can then check it out, and make their changes/additions. You can think of it as a physical library book – while one patron has it checked out, others have to wait to get their hands on it.
In the next Step, we will wrap up the Windows Forms with C# and Visual Studio portion of “Real-World Programming for Kids” by answering questions readers have sent in from around the world. We will take up, after that, with Databases. Tune in to the next episode/Step to see how interesting, fun, and useful they are going to be!
Until then, my friends!
The first volume of my four-volume series, Real-World Computer Programming for Kids of All Ages, namely Volume 1: Windows Forms Apps Using C# and Visual Studio is now available in both Paperback and Kindle formats. Volume 1 contains everything that has been printed in this Newsletter so far and through Step 34.
The kindle version of the book can be accessed here: https://www.amazon.com/dp/B08H7DKKCS/ and the Paperback version can be accessed here https://www.amazon.com/dp/B08H9RB1WG/

Earth-shakingly Important Notice: If you have a basic programming question (suitable to an audience of “Kids”), send it to idiolectable@gmail.com, specifying whether you would like your name and location used if it is printed in a future “Step” of this newsletter. If you are a subscriber to the newsletter, you can also leave a question at the bottom of this Step, in the “Comments” section.
If you do not want to give your real name, a nickname is acceptable (the first “Letter to the Editor” of mine that was printed appeared in Rolling Stone magazine, back in the early 1970s, and I signed it “Sylvester” for some reason which I no longer remember).
Finally, it’s always interesting to see where people are from, so please provide your City or Town and the State it’s in, too (or Province, or whatever the region where you live is called).
To listen to this Step, the audio of it can be found here: