Object Oriented Mistakes


This week I listened to the CodingBlocks Podcast Episode 67 titled “Object Oriented Mistakes.” Over about two hours the three hosts, Allen, Michael, and Joe discuss common mistakes and various programming problems that are easy to run into. I chose to listen to and write about this podcast because all of the programming I’ve done so far has been object oriented, so this was an easy opportunity for me to learn.

I picked up on one example they used early on while talking about the concept of BaseBean. BaseBean is when a class is implemented without falling under the category of “is a” for the parent. The example was if you were creating a car class including physics based attributes such as speed and weight, then creating a bullet class that inherits from it. This saves time in the short term since a bullet has attributes like speed and weight as well, however, a bullet is not a car and therefore you can easily run into problems later. Say you now wanted to put a new attribute into a car, like seat belts which no bullet should ever have yet it is inherited anyway. This can also be confusing for other developers looking at your code, assuming that bullet is some type of weird new very very small fast car for ant people. A good work around this common mistake is to only inherit things that fall under the “is a” category for the parent.

Next the hosts talked about how it is common to wrongly call the super method. Having to call super means that there is something in the parent class that is meant to be changed by its children. A common inefficiency occurs when a programmer sees they must remember to always change some common inherited method from the super class. Quoted by Martin Fowler, “Whenever you have to remember to do something every time, that’s a sign of a bad API.” This can be fixed by implementing template methods with the concept of the Hollywood principle, “Don’t call me, I’ll call you.”

So what I’ve learned from this podcast is in the future, I will remember specific common errors like these and know how to solve them. There are many other topics the hosts of CodingBlocks talk about in this episode, so i suggest you go listen to it if you want to hear more. Their content is interesting, their personalities are likable, and they have plenty of episodes to choose from with more continuously coming out.



Software Community and Toxicity


This week, I read this blog post titled “kindness and code” authored by Max Kanat-Alexander on his blog, Code Simplicity. The post is about the toxicity of the software development community and Alexander is trying to help improve it by explaining the importance of kindness and treating fellow developers with respect. I chose this post to write about because I am interested in improving the typical harshness people tend to deliver to each other on the internet. As somebody who plays a lot of remarkably toxic video games such as league of legends or call of duty, its easy to see how that type of bad behavior can also exist in software development. In fact, you can find horrible behavior common in any field regarding random community communication on the internet.

I believe people tend to lash out over the internet more often than in real life. This is because they are mostly anonymous and care less about good manners or reputation when it involves somebody they may not ever meet again. This allows somebody who is given any slight reason to judge you, the justification to barrage you with hate. This type of behavior is pointless as Alexander writes “There is no value to being cruel to other people in the development community” as it seems like an instinctual reaction for some people to point out anothers flaw just to make them feel bad about it. Take an example of any normal person trying to learn something new for the first time, either with a video game or in software development, and they make a mistake. If another person online is able to see their mistake, they might be aggravated by it enough to insult and verbally abuse the poor person who is just trying to learn.

Usually this occurs when somebody more experienced looks down on a newer person however, not necessarily. As the internet matures like an older brother, more and more experienced people are picking up the habit of lending healthy advice down towards the still learning user, and that is what Max’s blog is about. Coming from an experienced point of view, he offers techniques of constructive criticism to the software development community in hopes that they will help each other rather than judge each other. While today it is common sense to simply ignore and accept the inevitability of horrible comments on the internet, it is becoming more of a growing trend that not everybody on the internet has something hurtful to say. That means progress! Even though it is difficult to imagine an internet without any angry anonymous trolls waiting to insult your every move, I believe the internet community is getting better and better every day.

Writing “Clean” Code


As I learn more about computer science, I find that writing code for a programming project is very similar to writing an essay for an English project. I find that the core structure of a coding language mimics the core structure of any other language. A run on sentence can be compared to poorly using indentations, grouping your variables together at the top of the page is like having a well organized thesis statement. Just as we spend years taking English courses perfecting our grammar and sentence structure, it takes a lot of practice and learning to perfect our syntax and ability to write clean code.

Some benefits of writing clean code include:

  • Being able to easily follow your own code to track down errors
  • More efficient productivity
  • A more professional reputation
  • Your employer/teacher will resist the urge to strangle you

I appreciate how the author includes many quotes, my favorite is “nothing frustrates me more than code that reads like code.” Reading this line was particularly interesting to me, it emphasizes the amount of effort a person has to go through in order to fully read and understand code simply because the nature of coding is difficult to understand unless you look it over a few times. A solution to this problem is adding reader friendly comments and explanations to guide the reader along the way by pointing out in plain English what a certain method is used for or why a certain variable is necessary later on.

The goal of this solution is so that anybody can read your code without actually having to read your code, they can instead read your detailed comments and have an easier time understanding. Taking the time to write out detailed comments also helps you understand your code better by taking a second look at your code. By explaining to yourself why your code works the way it does, you can easily discover opportunities to better optimize it as your reading it through. Suddenly things you thought were necessary could be done in a different, simpler fashion, all because you took the time to show yourself how your code works a second time over.

In conclusion, this article explains in detail why we should try to better our code and how to develop better habits from common mistakes. I for one, typically write messy code just hoping it will work and later try to buff out bad variable names, overly complicated methods, and half written comments. After reading this article however, I’ve learned tips and tricks for writing better code and how to embrace the clean code mindset. I can only imagine how many frustrated programming teachers’ evenings I’ve saved after reading this article, so for your own sake and for the sake of whoever has to look at your code, I recommend you read this article as well.