| If you have a large important financial service to maintain and develop, and such a code basis is part of your backend, I guarantee you that you won't think twice to simply rely on deterministic linters. The reason is quite obvious if you have dealt with such a huge code basis in production with thousands of developers contributing for decades to it coming from different vendors and countries. Code has a meaning attached to it. And paradoxically being able to cleanly cut out such dead code raises my suspicion. There is a reason why such code exists in there often times and since almost always stakeholders give a damn about documentation, and developers traditionally have a hard time writing even JavaDocs, JSdocs, whatever and not to mention maintaining them. In earlier times CPU time was precious and comments were deliberately left off due to space and processing considerations. So why is this all important? Because until you cannot find the one guy who uses this code for a good reason, I would never kill it. Good reasons in these cases are almost always so called application owner, an app admin and hosts, who serves according to ITIL specs as deployment and production person. Dead code can be actually quite lively under the right circumstances. And since sometimes people have to be very creative to serve regulation requirements and compliance, sometimes release pressure or missing tools can make such code an important script or deployment tool or fix for a reboot or whatever. Believe me, dead code isn't. What you can do is, watch it at least over a period of two years. Here is why. Most processes have yearly deadlines. Many fall on the 1.1. of each year, while others somewhere at the end of the year. Some processes need to be served once a year due to compliance to laws. And why two years then? As I said, human beings. Maybe that one time a guy had an exception running for it or there is a maintainer, who uses a different method - his own dead code so to say - because these scripts are rarely shared and maintainer's best kept secrets. The lesser a company knows, the more important these last line folks feel and they are blackboxes when something is or isn't working. (I hated this, this was not way of working and I changed it. It is not their company and a keeper is a Red Flag for me.) But rarely the same person will serve the process two times in a row. Vacation times vary as well as positional changes. Hence the two years period and even then, there are smarter, more easier ways than to use linters. Hint: it is the frontend first paradigm. How do I know? Because I invented it. Proof: Huge international Bank. dbCORE. |