Anonymous Monk writes:

"...there still would be plenty of spaghetti left over that needs straightening out."

That is a feeling I am familiar with; but realize that part of the complexity of the code is due to not having a guiding data structure. The first thing I try to do is to enforce localization of data. Push the data to the right side of the function calls. Whether that involves closures, ties, manifests, configuration hashes or whatever, get the data separated from the control flow, the if/then/else on the left side.

Very often there is natural structure that is hidden behind the chaff. Often, to uncover it, you have to restructure the program to allow the data to lay together. For example, when dealing with multiple files, opening a group of files inside one loop then processing them inside another loop. Even multiple loops, each doing one step of the processing. This is perhaps more resource intensive but it groups the like data together. Once you have the like data grouped together you can begin to look for natural groups that can become objects. When you have groups of data together with their accessor functions, then you have an API.

"I realize that functions modifying globals is not a terribly good idea,..."

Only if the API for that data isn't well defined. This is what an object does, it associates the functions with the data and defines the scope of the interactions.

"...and don't want to rush headlong into creating classes unnecessarily."

Agreed, let the code tell you what it's objects are. That will happen as you force localization of data.

"So, what are the core points of good procedural design?"

Define the data structure first, write the code to the needs of the data.