Requesting best ways debug/follow and make sense of spaghetti code?

[novinosrin]

Situation: Too many spaghetti codes in production since 2014 

Requirement: To make changes, plug additional requirement and still will only use spaghetti code

Consequence for self: Headache,- tylenol-aleve medicines don't work for my headaches being so irritated

Consequences for Business: Time , losing time and what not

Any smart , simple ways to quickly rush through. I am ready to over hourly Connecticut minimum wage for the right suggestion lol😁

[PaigeMiller]

I assume you mean you have inherited, or your department is the proud owner of, spaghetti code. If you are writing your own code, use structured programming methods as much as is humanly possible; structured programming allows IF-THEN-ELSE type of programming, it allows DO loops as needed, but no GOTO statements, and no coding that reminds people of any type of pasta.

I don't understand this:

Requirement: To make changes, plug [sic] additional requirement and still will only use spaghetti code

Are you saying you are not allowed to modify the spaghetti nature of the code, you are only allowed to add new features? I agree with your statement of consequences, and this may be a good time to sit down with your supervisor and have a heart-to-heart discussion about how inefficient you are when working with spaghetti code, and how this will continue to cause trouble down the line in fixing bugs and in validating the code.

[novinosrin]

Sir. yes I inherited legacy stuff dating back to 2014. 

Are you saying you are not allowed to modify the spaghetti nature of the code, you are only allowed to add new features?-- Answer is Yes

"or your department is the proud owner of, spaghetti code." --This is also correct. The department has been proud owner of spaghetti code for a long time

[Quentin]

---

@PaigeMiller wrote in part:

this may be a good time to sit down with your supervisor and have a heart-to-heart discussion about how inefficient you are when working with spaghetti code, and how this will continue to cause trouble down the line in fixing bugs and in validating the code.

Totally agree with that.  Many years ago, I worked (for a brief time) at a place where they said "if the code works, you're not allowed to change it."  You can imagine how well that worked out.  Drowning in a sea of technical debt.  And programmers hiding from their bosses that they were - shockingly - sometimes spending time refactoring code that "worked".

I think the only fix for a morass of spaghetti code is to invest the time refactoring/replacing it, or to spend the time adding more spaghetti as you go and fixing the resulting bugs (meatballs?) that will no doubt continue to show up along the way. 

Or as they say, "pay me now or pay me later."  (I never knew that came from an oil filter commercial).

Good luck!

---

[ballardw]

If in data steps don't forget the SELECT statement. A couple of levels or do/end blocks within a When can sometimes reduce a lot of other code.

Some things it may be worth looking at:

Proliferation of data sets. I inherited some code that created a new data set for every variable added. It may be worth testing a data step that way but after verifying the code does what is intended move back into an earlier data step (one of the re-factor steps).

Another is proliferation of variables. If some one was creating a bunch of different similar variables, such as persons age by 5-year, 10-year intervals, and a couple of other ranges of interest then perhaps use of formats on a single age variable would work.

Normalizing data sets may be a good thing as well.

Are we talking about lots of macro coding? Sometimes normalizing data structures can reduce the need for or the complexity of macros.

I also would look at obnoxious data step code that perhaps is doing what procs like summary could be used for summarizing. Obnoxious MERGE code might be hint to investigate Proc SQL.

Have fun.

[PaigeMiller]

I also would look at obnoxious data step code that perhaps is doing what procs like summary could be used for summarizing.

I love telling this story. In 2006, I inherited a monstrous mass of code, that had virtually no comments, and the writer of the code had data steps of 15–20 lines, in many places, all seemingly doing the same (non-obvious) algorithm. So early on, I sat down and decided to bite the bullet and dig through this data step code and figure out what it was really doing. It turns out that this 15–20 line data step was adding zeros and ones. You may have heard me scream when I figured that out.

[novinosrin]

Excuse me "It turns out that this 15–20 line data step was adding zeros and ones" only???

Exactly the same situation here in adding zeros and ones using  proc sql case when. Just that yours was 15-20. Here it is 150-200++. I am gonna enjoy a nice strawberry yogurt to get over my frustration. Talk to you lovely people later. 

[Reeza]

It's definitely a slog. But it's also a good learning experience to teach you how to structure your code, how to read someone else's code and how to refactor a code base. It sucks when you can't do the refactor portion. I would suggest as you go through to add rough time estimates on how long it would take to refactor. When you're done, add up those estimates and multiply it by 3. if that's a reasonable amount of time, ask your boss if you can work on it. 

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

[ballardw]

---

@novinosrin wrote:

Excuse me "It turns out that this 15–20 line data step was adding zeros and ones" only???

Exactly the same situation here in adding zeros and ones using  proc sql case when. Just that yours was 15-20. Here it is 150-200++. I am gonna enjoy a nice strawberry yogurt to get over my frustration. Talk to you lovely people later. 

---

I laugh at your mere 200 lines 😅 I inherited some code that was searching for the value code in 20+ variables for each of 40 codes. Each block was an
If var1 = 1 or var2=1 or var3=1 .... repeat ad nauseum.

Turned this into 1) array code and 2) going over the variables and setting the indicator for the second array.

Reduced about 1000 lines of code to 5. For one set of variables. There were several similar though smaller blocks.

[Reeza]

It depends on the spaghetti code, but in general, I'll start by creating a control program. So first divide your programs into code that is utilities (things you use between projects) and code that belongs to specific projects/tasks. Then tackle each project/task/utility on it's own. 

I won't change the code, but I'll often create control programs that will execute the 'spaghetti' code as needed but then it's more clean. Personally, I like to separate my steps by:

• data import
• cleaning
• analysis
• reporting

This way, if my data source changes I change only my data import program, make it match the old stuff and move on.  The modular aspect means you can change things independently which helps a lot for maintenance and improvements later on. 

And always remember spaghetti code exists because someone was likely doing the best they could in the time they had. We have to work within the limits sometimes, as much as it sucks, but such is life. It does feel like you're working with your hand tied behind your back, but the person creating that code may have been in a similar position. 

Not sure if that helps at all, but good luck. 

Oh and for making sense of code - go through it slowly. Make a process diagram on the side such as:

• calculate means
• merge with main data set (could be replaced with XYZ)
• calculate rates here
• generate XLS files here (could be replaced with ODS EXCEL or XLSX now)

etc.

For debugging code that isn't running, start at the top. There's not really any other way. The binary search method also works for debugging complex code within a data step but remember you have to start at the top and keep and eye out for drop/rename/keep statements. 

[novinosrin]

Hello everybody, Just one feedback and suggestion from people who write such codes. They say "any code" that does the job is deemed good and is one self's coding style. hmm! What do we do? Take the moolah and be happy with a pint later in the evening. 

"Con-gress" is the opposite of  Progress"- as we all know 😞

[Reeza]

Programming is a tool to solve problems. Some people, like to solve problems in the most elegant fashion. Others are fine with sticking a nail through two pieces of wood and calling it done. 

It depends on the problem, amount of $ and quality of the pint/company it's in....sometimes, if it gets the job done, it gets the job done and you can send your time on more fun things??

[novinosrin]

"It depends on the problem, amount of $ and quality of the pint/company it's in....sometimes, if it gets the job done, it gets the job done and you can send your time on more fun things??"

Agree, unfortunately that level of diligence or energy isn't exhibited to what and where it alludes. However, C'est la vie!. On the positive side, I'm  getting credit risk mortgage training. 🙂 

PS Pint!!! lol Tea to coffee, and now pint. Never thought you had that sense of humor, will have to open another can for that haha