Yet more code smells? Plenty of! 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 , Part II , Part III is , Part IV , and (for now). here here here here part V the last one Let's continue... Code Smell 36 - Switch/case/elseif/else/if statements First programming lesson: Control structures. Senior developer lesson: avoid them. Photo by Adarsh Kummur on Unsplash Problems: Too many decisions together Coupling Duplicated code Violation of . Open/Closed Principle A new condition should not change the main algorithm. Nulls Solutions Polymorphism Create hierarchies/compose objects following . Open closed principle Use to model transitions. State pattern Use / to choose for branches. Strategy Pattern Method Object Examples Discrete Values State transition Algorithm choice. Sample Code Wrong Right Detection Since there are for If/else usages, we should not pull the plug and forbid these instructions. We can put a ratio of if statements/other statements as a warning instead. valid cases More info How to Get Rid of Annoying IFs Forever NULL: The Billion Dollar Mistake If debugging is the process of removing software bugs, then programming must be the process of putting them in. Edsger Dijkstra Code Smell 37 - Protected Attributes Protected attributes are great for encapsulating and controlling access to our properties. They might be warning us for another smell. Photo by Jonathan Farber on Unsplash Problems for code reuse purposes. Sub classification violation ( principle). Liskov substitution SOLID Possible subclass overrides. Solutions Favor composition Don't subclassify attributes. Extract behavior to separate objects. Use (if available). traits Wrong Right Detection In languages supporting attributes we can avoid them by policy or have a warning of this smell. protected Tags Encapsulation Conclusion Protected attributes are yet another tool we should use carefully. Every decision is a smell, and we should be very careful with attributes and inheritance. More Info Traits on Wikipedia Subclasses shouldn’t always share all characteristics of their parent class but will do so with inheritance. This can make a program’s design less flexible. It also introduces the possibility of calling methods on subclasses that don’t make sense or that cause errors because the methods don’t apply to the subclass. Steve Klabnik Code Smell 38 - Abstract Names Avoid too abstract names. Names should have real world meaning Photo by Rodion Kutsaev on Unsplash Problems Implementation Naming Meaningless names Broken and to real world entities. MAPPER Bijection Solutions Choose meaningful names. Find metaphors. Avoid words like , , , etc. abstract base generic helper Use for naming. rules Sample Code Wrong Right Detection We can set up policies and rules warning for certain words like . base, abstract, helper, manager, object etc Tags Naming Conclusion Finding names is the last thing we should do on our designs. Unless we have a clear business understanding, good names emerge at the end after defined behavior and protocol boundaries. More info What Exactly Is A Name: Rehab [Part II] There are only two hard things in Computer Science: cache invalidation and naming things. Phil Karlton Code Smell 39 - new Date() 70s first tutorial: getCurrentDate(). Piece of Cake. We are in the 20s Time is global no more Problems Coupling Fragile Tests Timezone Problems Solutions Use Dependency injection to decouple time source. Sample Code Wrong Right Detection We should forbid global functions policies. We need to couple to accidental and pluggable time sources. Conclusion Date.today(), Time.now(), and other global system calls are coupling smell. Since . We should easily set up time, moved it back and forth etc. tests must be in full environmental control and classes should only create immutable instances. It is not their responsibility to give the actual time. This violates Single Responsibility Principle. Date Time The passage of time is always scorned by programmers. This makes objects mutable and designs poor and coupled. More info Is it Crystal Clear for Everybody That a Date Should Not Mutate? Tags Globals In programming, the hard part isn't solving problems, but deciding what problems to solve. Paul Graham Code Smell 40 - DTOs Data Transfer Objects (DTOs) are widely used, and they 'solve' real problems, do they? Problems Anemic Object Inconsistent Data Duplicated logic Duplicated structure Class Polluting Information Hiding Violation Code repeated among , accessors, , mutators serializers parsers Ripple Effect Data integrity Solutions Transfer anemic data on arrays. Use real business objects. If we want to transfer partial objects: use proxies or null objects to break the reference graph. Sample Code Wrong Right Detection We can use the same anemic object detectors. We can check for classes with no business object behavior (removing serializes, constructors, mutators etc). anemic Tags Anemic Conclusion DTOs are a tool and an established practice in some languages. We should use them with care and responsibility. If we need to disassemble our objects in order to send them away from our realms, we need to be extremely cautioned. Since dismembered objects have no integrity considerations. His author warns us about its actual abuse. More info Martin Fowler Refactoring Guru What is the Point of Using DTO? The best smells are something that's easy to spot and most of time lead you to really interesting problems. Data classes (classes with all data and no behavior) are good examples of this. You look at them and ask yourself what behavior should be in this class. Martin Fowler Are 40 enough?. When will we stop? I keep getting more suggestions on , so they won't be the last! twitter

Twitter

I Asked #DevTwitter for Advice for Junior Developers; got 50+ Responses 

Simple Tips to Boost Your Productivity in 2021 (Part 2)

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Book Author

Too Long; Didn't Read

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

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Predictions About the Future of Finance

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

3 Things Coding And Prose Writing Have In Common According To Cory House

4 Simple Habits For Engineering Teams To Beat Technical Debt

10 Predictions About the Future of Finance

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

3 Things Coding And Prose Writing Have In Common According To Cory House

4 Simple Habits For Engineering Teams To Beat Technical Debt

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps