Document

I blocked off some time at work to knock out some more of the tool I'm building for extracting/analyzing support cases. It's been about a week since I had last dug into it so it was tough to figure out where I had left off. Since I didn't have much time before I had to be home I decided to abandon coding and start documenting. I wrote out the general reason for the program, some sample usage of the main class and its instance variables and methods, and documented the purpose of the methods I had already written.

Honestly it was a weird form of procrastination, but now I know exactly what's done and this is a good pointer for where I need to go. There was a link on Reddit I wish I had bookmarked about programming "backwards" where you write the documentation first - even writing out sample implementations of APIs not written yet. It provides a sort of design document and gives direction of what the actual implementations need to do.

I'll probably write about this more later (actually maybe I already wrote about it...) in a specific sense. The largest struggle I've had with this program is how to store results. Should the class members return data internally, or to an outside variable? My experience with C has driven me to the latter. Most functions return the value you're asking it to compute. Sometimes the function will work with pointers to outside variables and technically return void (or 1 or 0 or whatever means success) but it still involves outside variables. Once you start working with classes you have to somewhat abandon those rules and try to stay within the class. I am always repeating this: "A class is where you keep data and the functions that can alter that data". A natural extension of that is "data in the class that you modify will also be in that class".

I struggle with object oriented programming. This must be something a CS major puts a great deal of time into, and maybe that's why Java is a dominant language in CS programs.