Code Smell 18 - Static Functions

Code Smell 18 - Static Functions

Maxi Contieri
·Nov 6, 2020·

2 min read

Subscribe to my newsletter and never miss my upcoming articles

Listen to this article

Yet another global access coupled with laziness.

TL;DR: Don't use static functions. They are global and utilities. Talk to objects instead.


  • Coupling

  • Testability

  • Protocol Overloading

  • Cohesion



  • Static class methods

  • Static attributes

Sample Code


class DateStringHelper {
   static format(date) {
     return date.toString('yyyy-MM-dd'); ;    

DateStringHelper.format(new Date());
class DateToStringFormatter {
   constructor(date){ = date;

   englishFormat() {

new DateToStringFormatter(new Date()).englishFormat()


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.

In most languages, we cannot manipulate classes and use them polymorphically, so we can't mock them or plug them on tests.

Therefore, we have a global reference too difficult to decouple.


More info


Photo by Alex Azabache on Unsplash

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

John McCarthy

This article is part of the CodeSmell Series.

Last update: 2021/06/28

Share this


Technical Opinions are my own. I don't have the revealed truth.

Software Design is a creative activity. These are hints and not rigid rules.

I write on BackEnd Business Systems and OOP Design. My advice/experience might not suit other systems.