In computer science, there are a lot of things we would normally take for granted, but it might not be so easy to program. Take time, for instance. If we wanted to create an app to calculate how many seconds ago a time and date was, it seems straightforward. Of course we would account things like leap days, but as I discovered, it quickly becomes a lot more complicated than that.

As Tom Scott explains in an episode of the YouTube Channel, “Computerphile,” a simple-sounding app like this can be jarringly complicated. For starters, to create this app for a worldwide audience, it seems reasonable to make it available in all time zones.

To adjust it for each time zone seems straightforward enough. All you have to do is take the Greenwich Mean Time and add or subtract hours based on the time zone that the user is in, right? Not quite.

Take daylight savings time, for instance. It varies from country to country when daylight savings starts, and then there are some states/countries that don’t go on daylight savings time. This is just the tip of the iceberg of how complicated it gets.

There are times when countries skip days when they cross the international time zone. Countries can often switch time zones several times, even within the same year. Some countries can be in the same area but in separate time zones, such  as Israelis and Pakistanis. Historically, we haven’t alway been on the same calendar. Russia only switched to the Gregorian calendar in the twentieth century, complicating matters even more. There are even more confounding historical absurdities, such as the year used to start on the 25th of March, bizarrely.

There is even a such thing as leap second, but leap seconds don’t exist in astronomical time, and the differentiation is important because of how they manufacture telescopes and such.

This video revealed just how easy it is to take a problem and not realize how much more vastly complicated it can be and to appreciate the people who came before me and worked out this absurdly complicated problem.

I found it interesting because it was a problem I never thought about before. It seems like an easy enough problem until you find out how complicated it really is. Like I say, it is easy to take something like this for granted, and this makes me appreciate how seamlessly most technology that uses programmable clocks runs. Now that I can understand how vast and complicated the problem is, I can appreciate those who came before me and did the hard work to get it right.

https://www.youtube.com/watch?v=-5wpm-gesOY

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

“Coding with Clarity”

Software developer Brandon Gregory’s two-part post in the blog “A List Apart”, describes key concepts every software designer should follow in order to make the functions in our programs not only functional, but also efficient and professionally designed.

The first piece of advice Gregory shares with us is to maintain what he calls the “single responsibility principle”. In other words, each function should only focus on one process. By following this rule, we not only limit the margin of error in our code, but also increase the flexibility of them. Having simple functions makes the program easier to read, modify, and detect errors.

The next concept the author illustrates Gregory described as “command-query separation”. This means that a function should either carry out some work, or answer a question and return some data. The key advice is to not combine the two types. A function should either perform an action or answer a question, never both. If a program needed to both change data and return information, it would be better to write two separate functions to handle the tasks.

Finally, Gregory delves into the details of “loose coupling” and “high cohesion” in code. What he means by “loose coupling” is that each subsection of a program should be as independent as possible, not relying on the other parts of the code to inform a function. Similarly, the author advises us to stick to “high cohesion”, meaning that each object in a program should only contain data and functions that are relevant to that object.

Personally, I very much agree with and appreciate Gregory’s perspective and advice on writing clean code. In his advice, he very effectively clarified a lot of the concepts that I’ve trouble with implementing in my previous programs. One of my favorite lines in this post was “Large functions are where classes go to hide.” I found this quote very useful because it helps solidify the process of abstraction. From this point on, if I’m writing a function that becomes too unruly or long or complicated, I will ask myself “would this large function be better off as an independent class?” I definitely learned a lot about good practices in simplifying functions, and I will reflect on from now on when developing programs.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.