The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
There may be nothing at all wrong with what you are doing.
Procedural style can be the correct solution for a given situation. I once had a new programmer come to me and tell me he wanted to rewrite a program piece because it wasn't OO. Cool, go for it. While some of the resultant code was really quite good, a lot of it was un-needed and difficult to read.
Depending on the application, you sometimes start out thinking that a class is going to be the best thing on earth. Later, you find that it never gets reused, will be a lot shorter and clearer in procedural style, so why do it?
Passing 6 or more parameters may be just fine, but the question is have you overridden, expanded, extended, whatever the method beyond its scope and would multiple methods be more concise? It may be a place where the global vars are indeed correct. If properties are only there for 'set and get', you need to reconsider their existence.
In a certain sense, structures really are only a form of global. Their use is generally just clarity: tree.species, tree.color, etc. when they are not being acted upon to where a class is more appropriate. Passing it to a method(s) is probably a class function.
It boils down to architecture. What is the scope and scalability (i.e. future) of what you are writing? In a desktop business app with little or no interaction other than a database (still need all the db handlers obviously), 'down and dirty procedural code' may be just dandy in many cases. Of course, it may not work, as well. But we really can't tell that without an architect/analyst view of the project and entire codebase.
edit: Then there's waterfall vs agile vs continuous evolution. Sometimes you know everything you need up front. Small part of my world. My normal world is "the more you give them, the more they want" - a continuously evolving large codebase. Continual change means refactoring and reviewing that you are still writing effectively instead of creating a nice bowl of spaghetti. Anyone can make spaghetti but nicely layered lasagna is more work!
I understand what you mean. This is my favorite reply, as you were very thorough.
This despite the fact that I've evaluated a lot of what you wrote and it's covered ground for me- I used to be a software architect by trade after I was strictly a developer. Still I appreciate the time and effort, and so I'm sure do people visiting the thread. Thank you for this.
I have run into some maintenance issues, but not insurmountable. I don't like how the code will look to me in a month, and so some refactoring is in order, but I haven't figured out which way to go with it.
A lot of times when I need ideas, I tend to go my own way, having received inspiration from others nonetheless. Asking helps "unblock" me, so don't worry about not being able to address my code without seeing it. I appreciate the input.
I think this is still best procedural, but maybe some of the arguments I pass could be encapsulated as structs or even classes. The other option is to go full bore and make a complete and sensible model out of the whole thing but this requires a lot of code I'll never use, despite being one of my go to techniques. For example I developed a document object model for my regular expressions even though I didn't absolutely need it. It was useful in some cases though. I don't believe that to be true of this particular bit of the code generation process.
Either that, or i haven't landed on the Right Way(TM) to do this and that's why I'm running into anti-patterns. Maybe there's a concise model I just haven't figured out.
I'm great at modeling though. It's one reason I became an architect - the ability to think in several levels of abstraction and model complicated systems even in my head. However, I'd be a fool to think I was the smartest person in any given room, so it's always possible someone more clever than me came up with A Better Way(TM)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
My thought was you were an experienced programmer Your question style caught my eye because it was something I might write. I don't ask highly technical questions; you can always find those answers in manuals, wikis, or blogs.
You know, we all have those gremlins sitting on our shoulders: "Do this, it is the way of the future", "Don't do that, it's bad form". Meh.