tpeterb

The switch statement code smell

Yes, you read it well. The title says switch statements are code smells. You might be thinking, this guy is out of his mind, how on earth could something as useful as a switch be a code smell? As it turns out, it depends on the situation. Let me explain.

You have probably encountered a situation when you had to code multiple else if statements after an if, just to cover all possible conditions. The result was inconvenient to your eyes, too many braces and ifs. Then you suddenly remembered what you were taught: at these junctures, it's more elegant to use a switch statement, so you refactor your code and write different cases for the different conditions. You look at the new code, and feel deep satisfaction: it looks much nicer than it used to.

However, sometimes utilizing switch statements is equivalent to shooting yourself in the leg as you were better off without them. Let's see how you can recognize these situations.

Why is it a code smell?

tpeterb

The refused bequest code smell

In the previous articles, we explored the main code smells that belong to the category of bloaters. All three have one thing in common: they are pretty well-known. Everyone has seen large classes and long parameter lists, even if they don't know how to resolve the situation. There are many code smells though, of which no one knows that they resemble a problem with their code which shouldn't be left as is. This article's topic is one of those.

The refused bequest code smell possesses a magical name, but it's meaning is rather simple. Basically, one or more subclasses inherit methods, fields, in short class members from their ancestor they don't need. The unneeded methods will either remain unused or they will get some fake implementation, or throw an exception.

The naming stems from the refusal, denial of the heritage: stuff inherited from the parent class the current class cannot make use of.

Why is this a code smell?

tpeterb

Large class code smell

The large class code smell is pretty similar to the two previous ones and thus belongs to the bloaters. It features a class who has grown way too much, and now no one dares to touch it and makes everyone question their life choices whenever it comes to the surface.

To make it clear, a large class is a class which bears the burden of too much functionality and too many responsibilities. In practice, this is often materialized as a hodgepodge of lengthy methods and fields that are likely, to a certain extent, unrelated and deal with different aspects of business logic.

As far as the size of the class is concerned, again, just as we saw with long parameter lists, an exact limit over which your class is a code smell doesn't exist! However, there's definitely an interval which starts signifying huge problems with your code. I would say up until 500 lines you are doing great, but when facing classes containing 5-6-700+ lines, please raise your eyebrows at yourself and start sensing somet

tpeterb

Long method code smell

Another one of the code smells that belongs to the bloaters, the long method code smell is one of the, if not the most frequently committed crimes against clean code. Its background doesn't demand any explanation, it means exactly what you think: a method consisting of too many lines and logic.

Naturally there's no such thing as a limit beyond which it's a code smell and under which every method is acceptable. Most clean code followers say any method longer than 10 lines should make you raise eyebrows, but that's just total nonsense, practically no complex algorithm can be summarized in 10 lines. I would say up until 50 you are good, and beyond 100 definitely refactor as you and your colleagues will just suffer with it in the long run.

---

Why is it a code smell?

tpeterb

Long parameter list code smell

One of the most often occurring code smells is long parameter list, which signifies a situation where a method has more parameters than comfortable. They usually say 3-4 is max, but I would say 5 is still fine, above that definitely question your design.

Why is this a code smell, what's wrong with it? Why can't I have 2789139 parameters in a method signature if I want to?

• Makes the method parameter list hard to understand and read: We don't want another shopping list in the codebase, it's more than enough what we have at home. Long lists are difficult to understand and comprehend, as we have to keep track of what each of them does, and what role each plays in the method's life. Also, reading a parameter list of 10 parameters is pretty tiring and by the end you forget how it began, pretty annoying. The longer the parameter list, the harder to understand and read.
• Error-prone: Calling methods that have more than 5 parameters is extremely error-prone, as it's very e

tpeterb

R Markdown

Készítette: Tóth Péter Balázs, Neptun-kód: ET75HL

---

Ennek a dokumentumnak az az elsődleges célja, hogy bemutassa azoknak a szoftvereknek a telepítését, amelyek ahhoz szükségesek, hogy a https://github.com/jeszy75/rmarkdown-examples linken található GitHub-os tároló html_document/python alkönyvtárában található, R Markdown formátumú fájlok esetén a make parancs sikeresen végrehajtható legyen. A dokumentum további célkitűzései közé tartozik a Markdown jelölőnyelv lehetőségeinek prezentálása.