Find dirty Java fields on Github

Free. No signup or credit card required. The information is deleted after your request.

Clicking "Run report" with no input will show example results.

If it's a moderately sized repo it might take more than 30 seconds. You'll see the spinner in your browser tab. I'm working on making it faster.

What is a dirty Java field?

Java is a programming language. A Java field is a variable used to store a piece of data with others in a class.

Fields have a type. Text strings, integers and boolean true/false are example types. Types can also be classes or interfaces. An interface describes what a class can do. A class implements the functionality of an interface.

A dirty field is a field whose type is a class that could be replaced with an interface.

The "dirty" part of the name comes from books and presentations by "Uncle Bob".

How is a dirty Java field fixed?

A software developer changes the type declaration of the field from a class to an appropriate interface that the class implements.

Importantly, the interface must have all the methods called on the field within the containing class.

Benefit of fixing a dirty Java field?

Interfaces allow swapping out different implementations. For example, if a class accepts a database interface, any class with connection and querying method can be used. This means different kinds of databases are supported.

They make it easier to update code.

Interfaces can also only capture a slice of the necessary functionality. So if a field is only used for one thing, the interface makes that clear.

What is the input?

Github is a website where developers can share code repositories.

If you have a Github repository, you can login and click the green [Code] button. Then click the "Copy url to clipboard". Paste it into the input above and hit [Run report].

Potential enhancements

Right now this is a very small specific tool. I might try to add some more functionality as part of what I'm working on to make my own code better:

The source code for the tool itself is available. It's sort of it's own testbed for the improvements below.

Report "dirty" variable declarations inside class methods, incl. type inference from "var" keyword.
Report "dirty" method type parameters and returns.
Create a separate downloadable command-line package that people can run on their own instead of through a web interface. Look into open source licenses for this.
Report blocks of logic that call the same methods on the same types, even if the type's variables have different names. Use this to suggest refactored methods.
Report switch/condition code blocks that could be replaced by polymorphic interfaces.
Report "disjoint" classes where each client only uses one of several subsets of the methods and properties.
Report situations where an enumerable is iterated with an integer iterator, then a dictionary is checked for some object matching. Common slowdown. It can be often be replaced with a sequential for-each.
Report suspicious public/private declarations (i.e. they should be the other)
Report places dictionaries could be used to replace list lookups.
Report nested enumerables that looks like they could be refactored to classes/objects.
Report places values could be cached.
Refactor the report logic code. It's not too bad, but there isn't very much logical structure to the methods. Some of the variable names are confusing. The way the class paths get built needs to be it's own function.
Refactor the view logic code. Right now the way it handles rowspans is confusing. It should gather all the inner objects, then the next level, etc. and detect rowspans from the counts.
Change internal name and packages of project from "example.demo"