Truck on a Wooden Bridge, by Ono Paiva
Every week a “don’t do this” article is posted somewhere. Don’t use inheritance, never write a singleton, scrum is dead. But are we really supposed to abandon it all? Is an if-statement really that bad a thing? How can we tell what advice is worth listening to?
There isn’t a perfect programming language, nor is there a right way to code. There are guidelines (and known pitfalls). Browsing through programming advice on the internet today is terrifying — everyone is telling you to stop doing something. Soon we’ll be out of commands to use. Everything is a source of bugs.
Consider this analogy: You don’t send a truck down a wooden bridge and expect it to reach the other side. That doesn’t means wooden bridges are dead nor that you should stop using trucks.
Programming languages give us tools. It’s up to us to know when, why, and how to use them. Don’t throw your hammer away because you hit your finger — improve your aim.
How to Spot Bad Advice?
Good advice has three parts. First, the information itself, second, its when, and third its when not to. Bad advice often lacks the second and third part — it’s presented as something that _always _works.
A common theme is to “avoid inheritance at all costs.” If left without the when or when not to, you might end up blindly following this and lose one of OO’s most essential tools. Instead, consider the following: “inheritance is a great tool. However, deep hierarchies are often harmful.” This time around its clear that the problem is depth. This explanation is far more precise and provides a direct insight into the matter, telling us that shallow hierarchies are fine.
Another thing to keep an eye on is language. Many writers are trained to “write boldly and never ask forgiveness.” This kind of tone is known to do well on the internet and particularly Medium. The problem is that boldness for the sake of boldness is damaging. People forget to add that their advice is not for every case. To avoid sounding weak, they ignore the when not to.
Good advice is friendly, not intimidating_. _Recall all the genuine help you have had over the years. Has any of it been given angrily?
Rules of Thumb
When it comes to coding, in particular, two rules of thumb apply:
1. Languages are expensive to create and maintain. If a feature keeps being added to new languages, it still has an important role to play.
That’s why the global scope is still a thing, as is inheritance and the if-statement. Any article stating that those should be avoided entirely is missing a pretty important aspect of these features.
A good example is typing. The sensual type-less world of Python and JavaScript allured many developers to their embrace, who would later regret writing ten thousand lines in such unstructured languages. None of that existed on the old fashioned world of Java and C## (which doesn’t mean they were any paradise either).
It is no wonder TypeScript is a thing. Typing has returned as loosely typed languages — you type just enough, the compiler fills the rest. This idea was so successful that it entered the C## and C++ worlds, through the varand autokeywords, respectively. Even Python has typing features by now.
In the opposite direction, the second rule of thumb is:
2. Modern languages have taken down all the really nasty stuff by design
That’s why we don’t see macros anymore or gotostatements or explicit memory management. Java had quite some bad press for its GC back in the day, but GCs have outgrown the JVM to pretty much all modern languages.
A recent removal is the null pointer exception. Modern languages like Kotlin and Swift enforce null checking by design. C## 8 is following a similar route. Raw threading and async callbacks have also had their share of problems. Now, we code asynchronous tasks with handy async/await constructs.
#programming #software-development #startup #productivity
