In a small to medium size code base you can really treat the two methods interchangeably.

If you have a method that is in the first category (can-be-static), and you need to change it to access class state, it's relatively straight forward to figure out if it's possible to turn the static method into a instance method.

In a large code base, however, the sheer number of call sites might make searching to see if it's possible to convert a static method to a non static one too costly. Many times people will see the number of calls, and say "ok... I better not change this method, but instead create a new one that does what I need".

That can result in either:

A lot of code duplication

An explosion in the number of method arguments

Both of those things are bad.

So, my advice would be that if you have a code base over 200K LOC, that I would only make methods static if they are must-be-static methods.

The refactoring from non-static to static is relatively easy (just add a keyword), so if you want to make a can-be-static into an actual static later (when you need it's functionality outside of an instance) then you can. However, the inverse refactoring, turning a can-be-static into a instance method is MUCH more expensive.

With large code bases it's better to error on the side of ease of extension, rather than on the side of idealogical purity.

So, for big projects don't make things static unless you need them to be. For small projects, just do what ever you like best.

About Me

Software Developer with 17 years experience as senior developer and tech lead in many large and small agile teams. I enjoy consulting with teams to implement improvements in development, testing, and devops practices leading to higher-quality software. I've experienced many of the pros and cons of Agile/Scrum/XP/DevOps and I'm always looking for continuous improvement in both team efficiency and personal skill. I believe the world needs more well-rounded developers, capable of seeing themselves in the bigger picture, able to quickly spot bottlenecks in the delivery pipeline - whether it be in Dev, QA, or Ops - and work with a sense of urgency to fix them with cutting-edge technical ability while using well-honed interpersonal skills to help improve the culture around them. Passionate about giving back to the community, I co-organise the DevOps Brisbane Meetup group and help run study groups for professional software developers on topics such as AWS Solutions Architect Certification, Continuous Delivery, Functional Programming, NoSQL & Distributed Systems, and enjoy inspiring IT professionals to sharpen their craft through professional development and group learning.