How to Find The Stinky Parts of Your Code (Part IX)

Yet more code smells? Aren't them enough?

We see several symptoms and situations that make us doubt the quality of our development.

Let's look at some possible solutions.

Most of these smells are just hints of something that might be wrong. They are not rigid rules.

This is part V. Part I can be found here, Part II here, Part III is here, Part IV here, part V, VI, VII and  the last one (for now).

Let's continue...

Code Smell 41 - Regular Expression Abusers

RegEx are a wonderful tool, we should to use them carefully and not to look smart.

Photo by John Jennings on Unsplash

Problems

• Readability
• Maintainability
• Testability
• Intention Revealing

Solutions

1. Use regular expression just for string validation.
2. If you need to manipulate objects, don't make them strings.

Sample Code

Wrong

Right

Detection

Regular expressions are a valid tool. There's not much automated way of checking for possible abusers. A whitelist might be of help.

Tags

• Primitive Obsession
• Abusers

Conclusion

Regular expressions are a great tool for string validation. We must use them in a declarative way and just for strings.

Names are very important to understand pattern meanings.

If we need to manipulate objects or hierarchies, we should do it in an object way.

Unless we have a conclusive benchmark of impressive performance improvement.

More info

What Exactly Is A Name: The Quest [Part I]

A Perl program is correct if it gets the job done before your boss fires you.

Larry Wall

Code Smell 42 - Warnings/Strict Mode Off

Compilers and warnings lights are there for help. Don't ignore them.

Photo by Noah Dominic Silvio on Unsplash

Problems

• Missed Errors
• Ripple Effect
• Fail Fast

Solutions

1. Enable all warnings.
2. Enable preconditions and assertions in production.
3. Fail fast
4. Design by contract

Sample Code

Wrong

Right

Detection

Most languages have warning levels. We should turn most of them ON.

We should run linters to statically analyze our code for potential problems.

Tags

• Fail Fast

Conclusion

If we ignore warnings and the code moves on sooner or later it will fail.

If the software fails later it will be very difficult for us to find root cause.

Defect will likely be near first warning and far away from the crash.

If we follow the Broken Windows Theory, we should not tolerate any warnings, so a new issue will not pass unnoticed in a sea of tolerated warnings.

More info

• Fail Fast Philosophy, Explained
• https://blog.rahulism.co/use-strict-in-javascript

One man's crappy software is another man's full time job.

Jessica Gaston

Code Smell 43 - Concrete Classes Subclassified

Inheritance. Concrete classes. Reuse. A fantastic mix up.

Problems

• Bad Models
• Coupling
• Liskov Substitution Violation
• Method overriding
• Mapper fault

Solutions

1. Subclasses should be specializations.
2. Refactor Hierarchies.
3. Favor Composition.
4. Leaf classes should be concrete.
5. Not leaf classes should be abstract.

Sample Code

Wrong

Right

Detection

Overriding a concrete method is a clear smell. We can enforce these policies on most linters.

Abstract classes should have just a few concrete methods. We can check against a predefined threshold for offenders.

Tags

• Composition

Conclusion

Accidental sub-classification is the first obvious advantage for junior developers.

More mature ones find composition opportunities instead.

Composition is dynamic, multiple, pluggable, more testable, more maintainable and less coupled than inheritance.

Only sub-classify an entity if it follows the relationships behaves like.

After sub-classing the parent class should be abstract.

More info

• Composition over inheritance

Software is a gas; it expands to fill its container.

Nathan Myhrvold

Code Smell 44 - Magic Corrections

Compilers are smarter than us. On a Friday night production deploy they betray us.

Photo by Senor Sosa on Unsplash

Problems

• Fail Fast
• Declarativeness
• Ambiguity

Solutions

1. Fail Fast
2. Do not trust magic coercions.
3. Be Explicit

Examples

• Type Casting

Sample Code

Wrong

Right

Detection

Many of this vicious are encouraged by languages themselves.

We should be very declarative and explicit and don't abuse language accidental magic solutions.

Tags

• Declarative
• Smart

Conclusion

Programmers pretend to be smart by exploiting language features.

They feel they belong to community standards that enforce bad behaviors like a sect.

More Info

• Fail Fast Philosophy, Explained

Hackers are arrogant geek romantics. They lack the attentive spirit of inquiry.

Bruce Sterling

Code Smell 45 - Not Polymorphic

Methods should be interchangeable if they do the same.

Problems

• Missed Polymorphism
• Coupling
• IFs / Type check Polluting.
• Names coupled to types.

How to Get Rid of Annoying IFs Forever

Solutions

1. Rename methods after what they do.
2. Favor polymorphism.

Sample Code

Wrong

Right

Detection

This is a semantic mistake. We could add a warning for similar method names on Polymorphic classes.

Tags

• Polymorphic

Conclusion

Naming is very important. We need to name after concepts and not after accidental types.

More info

• What Exactly Is A Name: Rehab [Part II]

If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother. Nowadays, the idea of giving a name to every file on your computer is ridiculous.

David Gelernter

We are done for now. But we are pretty sure we will come across even more smells very soon!

I keep getting more suggestions on twitter, so they won't be the last!