When using principles or techniques in code, we need to use them in moderation and understand the meaning behind them; otherwise we over-salt our code. The post that I will use in discussion explains a common salting problem in programming, the article was found in an early programming blogpost from Coding Horror, to reflect a topic that is relevant in programming and also discussed in one of my courses. The topic is Object Oriented Design.

In the article that I chose, titled, “Your Code: OOP or POO?”, the author, Jeff Atwood, talks about how many programmers these days are not using Object Oriented Programming correctly. He attributes this problem to institutions that rush and advise the usage of OOP to their students without properly explaining when and why objects are necessary in programming design. In addition, he also blames the pro-object culture that is common among programming communities, where programmers glorify objects and boast the superiority of object oriented languages over non-object languages. Due to these influence, he explains that it causes programmers to undergo object happiness, a frenzy of object-izing everything in their code. This mess, is the coding horror that is seen when Object Oriented Design is used improperly.

To address these concerns, Atwood recommends POO, Programming fOr Others, which brings in the element of empathy into programming design. What Atwood proposes is that programmers should be thinking about their audience, such as their readers, who will have to make sense and use their code. So, along with implementing other OOP principles, such as, encapsulation, simplicity, re-use and maintainability; Atwood encourages empathy and to build code while keeping in mind what their readers would want or need and to anticipate what they need to do next when following the code. Atwood concludes his argument with ‘programming as if people mattered will always be a more effective strategy than satisfying the architecture astronauts’.

Although this is an early post, which was posted on 2007, the topic of this post still holds relevance. While continuing my CS undergrad studies at WSU, I have noticed this pro-object culture, where object oriented languages are remarked as superior than non-object languages and I have also noticed that some of my peers falling victim to object happiness and not having a firm grasp of OOP principles. I also feel that this post was a good reminder, that we should be questioning our studies and what we are taught at institutions in programming. In a sense, it was a good step back for me to reevaluate my principles and goals in coding. It also brought in a new perspective, the element of empathy; where one should code as if people mattered; rather than solely focusing on the efficiency of the solution; we should also consider readability and simplicity of our code.

The link of the source can be found here

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

As I progress more in my CS studies, I’m starting to move beyond learning how to write the code for a project to how the project should be designed overall. In fact, this is one of the main purposes of two of my current CS classes. This has lead me to learning about TDD, or Test Driven Development. I’ve come across a fantastic article by Andrea Koutifaris which outlines the concept well called Test Driven Development: what it is, and what it is not.

In this article, I’ve learned the purpose of writing test driven code and what the plan for doing it should be. In TDD, tests come first in the process while writing production code comes second. This is in order to almost put oneself in a user’s shoes. If I myself in the user, what do I want my code to do? This is where the tests come in. Once the goals are clear and defined, the production code can be written.

The rules for TDD can be broken down to two essential parts:

• “Write only enough of a unit test to fail”
• “Write only enough production code to make the failing unit test pass”

Tests must be written to be very specific and achieve the ultimate application goals. Analysis of your tests can help you determine a method to writing your production code. They often not only outline what need to be achieved, but how it needs to be achieved.

The next part of TDD would be writing production code. As outlined before, the second essential rule of TDD is to “Write only enough production code to make the failing test unit pass.” Had production code been written first, output may not match user goals and unnecessary code may be written, which comes with its own set of problems. The focus is on writing clean code and limiting the amount which you write.

The last part of TDD would be the “refractor phase.” This is where code can be changed to be better, but what is stressed here is removing all duplicate code and consolidating.

The result of TDD should be efficient, clean code which serves its purpose. Although it can seem long-winded and like extra work, it’s mostly just inverting the process which we usually work by, so once the process is learned and practiced, it can help with writing better code more coherently and more focused on user goals, which is the ultimate goal as a programmer.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.