More smelly code...
• Chris Liscio
• Chris Liscio
In an ongoing attempt to refactor my code, I am now facing the task of organizing my display code. Originally, it was born from example after example found online and in books, but as with all the code I write based on examples, it's time to clean up and make it proper.</p><p>There is a lot of code that I write that starts out utterly spaghetti-like, but for the most part it gradually evolves into a fairly (NOT perfectly) well-designed system. The more I work at the code, the cleaner it gets. The cleaner my code gets, the less bug-prone it is. The final result is a quality product for the end-user.</p><p>If you've had the opportunity to see the display of my app, you'll note it's not like anything else out there.1 First of all, it uses the NSBezierPath to render the graph, which makes it look beautiful.2Furthermore, I use a nifty little algorithm (nothing new, but not something documented/explained in anything I could find) to smooth the curve's display by generating bezier control points on the fly. The result is a smooth curve all the way down to the lowest frequencies, which are very far apart due to the log scale. That algorithm took me a few nights to "figure out" (not that I invented it), and another few nights to perfect in implementation.</p><p>Anyway, you are probably trying to figure out where I'm going with this. This display code required a lot of calculations to translate points between coordinate spaces within the view, as well as handle the log scale and smoothing algorithm. In implementing all this, I probably did what most people do, which is hack away until it works. Once I hit a point where changing that code was a pain in the butt (due to varying sample rates, and other things I originally hardcoded), I cleaned it up a little bit by adding some configurability. </p><p>Once I had to use the code in a second component, it was time to break the logic out in such a way that it was generalized, and worked for multiple cases (rather than having some hard coded uglies). I'm in the middle of breaking some of the display logic out of the measurement class (eek!) and into the display class as I write this.</p><p>Earlier this week, I had to correct the hard-coding of a calibration scale for the measurements.3 That was converted into an addition to my preferences panel, and a measurement process was developed that allowed me to do the calibration automatically. Guess what? Adding the measurement process also led to some more refactoring that caused me to break my code apart so that I could run different MLS measurements arbitrarily.</p><p>So, this week was full of many long hours of redesigning and organizing code. These tasks are the toughest to work on, since it feels as if you're getting nothing done. That's because your code usually doesn't gain any new functions – think of it as giving your pet project a bath.</p><p>In closing, I should probably explain why I'm listing out these hideous things about how I work on my code. First off, we all know that nobody's perfect when it comes to software development – Programming Is Hard! In my case, I'm just trying to lay things out on the table here and detail the process that goes into putting out a software product. I just hope that the hard work that I'm putting into my software is going to be evident to the users of the software.</p><p>1I'm speaking about software in the same category as mine. Just about every Cocoa OSX software that draws lines uses nice, smooth lines. :)
2If I do say so myself. :)
3The scale factor was actually first determined by hand! Yuck!
</p>