How it works
Would you use the bathroom without washing your hands afterwards? Probably not. But before Louis Pasteur proposed the germ theory of disease, doctors would routinely examine hospital patients having just dissected a dead body in the morgue, without washing their hands in between. Why should they? They had no reason to correlate hand washing with the prevention of disease.
We think that software is a bit like the human body. These days, we write and maintain applications that are complex enough that one person can't keep the whole design in their head. Often times, when we are trying to fix part of an application, the fix may impact other parts of the application in unexpected ways. In medicine, they call that "side effects". And sometimes, it's hard to tell whether the symptoms you are observing are side effects of some treatment, or indications of some other, unrelated problem.
Just like humans, we think that software benefits from good hygiene. The biggest problem most developers face is meeting deadlines, and the easiest deadline obstacle to remove is unnecessary rework. Automated tools can't find all the problems in your code - far from it - but they can, very easily, find (and even fix) many of them. Similarly, washing your hands won't cure cancer - but it will prevent a whole slew of other problems, which is why you do it.
Enerjy does two things: it measures the probability of bugginess of your Java code (we call that the Enerjy Score), and then it helps you understand what causes a high or low score. The metrics that contribute to the overall score are like symptoms.
Some of those symptoms are direct indications of problems that can be addressed. We call those causal metrics. An example might be the use of curly braces around single statement if/then clauses. Adding the braces will directly reduce the likelihood of bugs.
There is another type of symptom, that we call indicative metrics. These do not relate directly to problems in the code, but are statistically shown to be associated with buggy code. For example, it turns out that a high proportion of in-line comments usually indicates problematic code. Of course, going through and removing the comments will not reduce the likelihood of bugs, even although it will improve the Enerjy Score. But, if Enerjy finds code that does have a high level of comments, it would be worthwhile spending some time looking at it to see if it needs refactoring.