What are some indicators or factors in determining if your code is over-structured or under-structured?
Edit
Perhaps over-engineered / under-engineered would be close to synonymous for over-structured/under-structured. How do you find a balance?
This post refers to any language.
If you need to use a factory object to instantiate even a simple object and there is only one of them, it's overstructured.
Perhaps, this is what you are looking for, the old adage for C, for an example, if the code is more than one screenful of lines, then the code needs to be broken up a bit more..short, simple and sweet and follow the philosophy of KISS (Keep It Simple Stupid)...
Is that what you mean by understructured/overstructured..It would help if you say what language are you talking about...
Hope this helps, Best regards, Tom.
The same or very similar code appearing in lots of places is a sign of under-structuredness.
An overly large proportion of structuring code (factories, iterators, meta-programming, etc) to application code is a sign of over-structuredness.
But these are almost truisms. The real answer if it "feels" over or under structured, it is.
The notions of "over-structured" and "under-structured" are highly subjective. A developer who thrives on extensibility, reusability and higher-order programming will tolerate (or expect) much more structure than someone who typically "gets the job done" using cut and paste programming techniques.
The notions are also context dependent. For example, a long lived application is going to need more structure than a throw away prototype, in order to be maintainable in the long term. But, for a prototype, getting the job done is usually more important than getting the structure right. (If the extra structure helps the prototype developer, fine. Otherwise it doesn't matter.) And as @corprow rightly points out, project complexity and team size / maturity are also "contexts" that matter here.
EDIT : IMO, what I wrote equally applies to "over-engineered" versus "under-engineered" as the terms are typically used in IT. However, there are nuances of "over-engineering" that have nothing to do with code structure. For example putting in too many logging points, method/constructor overloads that are never used, writing verbose / useless javadocs, writing voluminous design docs (that are out of date 5 minutes later ... and never updated.)
In general, if you spend the time writing down what you particularly mean by overstructured or understructured, you will probably be able to figure it out for your own code.
There are architectural-size scopes to this that are probably relevant, and there are team-size scopes to this, but a lot of it, as Stephen C says, basically depends on context.
Over-engineered = The original developers cant easily explain it to another developer.
Under-engineered = Other developers (or you) that try to work on the code base have to do a rewrite in order to add to it or keep it running.