How to Find the Stinky Parts of Your Code (Part IV) | Hacker Noon

@mcseeMaximiliano Contieri

I’m senior software engineer specialized in declarative designs and S.O.L.I.D. and Agile lover.

Are we done on code smells? Guess not.

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 IV. Part I can be found here, Part II here and Part III is here.

Small changes yield unexpected problems.

Photo by Jack Tindall on Unsplash

Problems

Solutions

1. Decouple.
2. Cover with tests.
3. Refactor and isolate what is changing.
4. Depend on interfaces.

Examples

• Legacy Systems

Sample Code

Wrong

Right

It is not easy to detect problems before they happen. Mutation Testing and root cause analysis of single points of failures may help.

There are multiple strategies to deal with Legacy and coupled systems. We should deal with this problem before it explodes under our eyes.

Architecture is the tension between coupling and cohesion.

Neal Ford

40+ Thought-Provoking Software Engineering Quotes

Discouraged by Object-Oriented Programmings, Many mixed languages support it. And developers abuse them.

Photo by Mae Mu on Unsplash

• Coupling
• Readability
• Maintainability
• Testability

1. Wrap the function in a context object.

• External Resources Access, Database access, Time and Operating System resources.

Wrong

Right

Many modern languages avoid them. For the permissive ones, scope rules can be applied and automatically checked.

Structured programming considers global functions harmful. Yet, we can observe some bad practices cross paradigm boundaries.

Singleton and Classes are global points of access.

The road to programming hell is paved with global variables.

Steve McConnell

Yet another global access coupled with laziness.

Photo by Alex Azabache on Unsplash

• Coupling
• Testability
• Protocol Overloading
• Cohesion

1. Class Single Responsibility Principle is to create instance. Honor it.
2. Delegate method to instance.
3. Create stateless objects. Don’t call them helpers.

• Static class methods
• Static attributes

Wrong

Right

We can enforce a policy to avoid static methods (all class methods but constructors).

• Global
• Libraries

Class are globals disguised. Polluting their protocol with “library methods” breaks cohesion and generates coupling. We should extract static with refactorings.

There is no programming problem that can’t be solved with one more level of indirection.

John McCarthy

Disguised as a friendly shortcut is another coupling smell.

• Coupling
• Unexpected results
• Side effects
• Ripple Effect
• In languages with optional arguments but limited to basic types, we need to set a flag and add an accidental IF (another smell).

1. Make arguments explicit.
2. All function calls must have same arity.
3. Use Named Parameters if your language supports them.

Wrong

Right

Detection is easy if language supports optional arguments.

• Optional
• Laziness

Be explicit. Favor readability over shorter (and more coupled) function call.

The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.

Seymour Cray

Planning ahead of time needs a crystal ball no developer has.

Photo by Markus Spiske on Unsplash

• Coupling
• Testability
• Readability
• YAGNI

1. Create great models and bijections first.
2. Create a conclusive benchmark once the model is working.
3. Design for Performance.
4. Use Test Driven Development technique. It always favors the simplest solution.

• Weird data structures
• Caches
• Singletons

Wrong

Right

This is a design smell so it can not be detected by mechanical tools (yet).

• Premature Optimization
• Antipattern

Defer performance decisions until functional models are mature enough.

Donald Knuth created/compiled the best/fastest algorithms and data structures. With great wisdom he warned us of abuse. Why do we think we are smarter than him?

Programmers waste enormous amounts of time worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. 

Donald Knuth

Premature optimization is the root of all evil.

Donald Knuth

And that’s it for now.

But rest assured, more smells will come.

read original article here