Bad code vent - not even worth debugging at this point

You ever see code so bad, its not even worth debugging. I feel like that right now on this project. The guy who did it had good intentions but his implementation is horrendous. I spent too much time troubleshooting just to say why am I even bothering? I can write this way better with way less code. And I wouldn’t even call my self a good programmer right now.

Sometimes I wonder why this system I work on has so many weird issues. Then I run into all this bad code. And while I can’t definitively tie anything to it. From what I’ve read that does impact the system.

I’m basically deleting all his scripts and starting from scratch. And it’s not even my main priority here.

2 Likes

I would caution you from deleting the old scripts in case you need to reference them later on because it did something you didn’t think did anything but turned out to be important.

I can commiserate. Recently was working on a project that was version 8.1.0 and instead of using named queries or runPrepUpdate statements, or even using string formatting like INSERT INTO table (value1, value2) VALUES (%i, %s"%(x,y), it was all INSERT INTO "+str(tableName) + " (value1, value2) VALUES ("+str(x)+","+str(y)")" where table name is a variable from the top of the script that’s grabbing a database table name off the PLC for some reason. Just some really questionable design issues (database tables don’t change often, and probably not through the PLC for that matter) along with not using the Ignition functions the right way or the easy way.

I think the two main hurdles people have to writing good code is

  1. not knowing how to write good python code in general, not having standards, not having good naming conventions etc.
  2. Not knowing how to properly utilize Igintions system.* functions, and therefore making life harder for themselves

However, I will say, refactoring bad code into good code is probably what helped me “level up” as a programmer more than anything else. It forces you read bad stuff, interpret it, and then figure out the right or better way to do it. Not to say it doesn’t suck when it’s on a real live project and you would have been better off writing it from scratch, but just offering a positive perspective you can take to try to make the tedium more manageable. Good luck :crossed_fingers:

3 Likes

@bkarabinchak.psi Def better not to reference in this situation. So this is what I’m dealing with.
two things.

  1. instead of indirect addressing, he throws scripts on every input box, no write alls so like 30 lines of individual tag writes. 90% of the code is commented it. Instead of just putting what is needed.
  2. his verification code. Instead of creating tags and checking them. He decides to upload a csv to a table on a window with button. Then somewhere else, open that window, loop the table, print the same value 100 times, trying to cross check valid names using like 10 or statement on one if condition
2 Likes

I have found myself, doing this with my own code.

Learning to refactor code that was written poorly or prior to learning better practices is an often under appreciated/practiced art.

At least you're doing this with Ignition/Jython where documentation and support abound. I am at the beginning of converting a FT application to Ignition in which I already know that the VBA code that shouldn't have been needed to begin with is horrid. It will be a rather adventurous year for sure.

5 Likes

Here is one refactor I think I just finished please go be honest on it. lol