<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Error_prone on JAVAPRO International</title><link>https://javapro-en.svenruppert.com/tags/error_prone/</link><description>Recent content in Error_prone on JAVAPRO International</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Thu, 18 Sep 2025 07:00:01 +0000</lastBuildDate><atom:link href="https://javapro-en.svenruppert.com/tags/error_prone/index.xml" rel="self" type="application/rss+xml"/><item><title>Code Wizardry: Casting Spells to Fix Bugs</title><link>https://javapro-en.svenruppert.com/code-wizardry-casting-spells-to-fix-bugs/</link><pubDate>Thu, 18 Sep 2025 07:00:01 +0000</pubDate><guid>https://javapro-en.svenruppert.com/code-wizardry-casting-spells-to-fix-bugs/</guid><description>&lt;h2 id="introduction"&gt;introduction&lt;/h2&gt;
&lt;p&gt;Multiple developers may introduce changes to develop new features or fix bugs during an application&amp;rsquo;s life. At the same time, these changes could introduce problems in the code, such as bad practices regarding the declaration of attributes, duplicate code, or pieces of code with a high risk of producing errors. &lt;br&gt;
&lt;br&gt;
In many cases, this situation could be detected on a peer review of the code for another developer but implies that someone needs to spend too much time focusing on small details instead of focusing on the problem that the code tries to fix. The appearance of tools like PMD, Checkstyle, SonarLint, and many others that detect problems analyzing the code mitigates most of the problem, but let’s see in detail the impact on the day-to-day of the company or developer.&lt;/p&gt;</description></item></channel></rss>