>...but! I do think we've got some solid steps in that direction. There's a lot of things we can calculate - LoC, symbol counts, "cyclomatic complexity" - so then as I see it, the gap is connecting those metrics to "goodness" in a solid enough way that it'd cross the threshold into "formal theory". Which might not be possible, if "goodness" itself can't be nailed down.

Lines of code? So less lines of code is better than more lines of code? So If I fit my program into one line it's better? That's not a good metric.

But then you say add it up with symbol counts and cyclomatic complexity and the average of the three should counterweight any inaccuracies that stem from each individual metric.... but does any of these metrics have anything to do with good design as our intuition defines it? I would say No.

The problem is our intuition of good design encompasses more than what all these things measure. The core principle that most people agree on that is fundamental to good design in programming is modularity. How do I design code so that any modification to the application is as much as possible more a reconfiguration of existing primitives rather then a rewrite or re-architecture? I want to design my coding primitives to be legos that fit together perfectly and any change is just reconfiguring those legos. However, in bad designs I find that my primitives don't act like legos. A new feature may often necessitate rebuilding and refactoring previous primitives and changing the way things work in order to get that feature in. Essentially new lego pieces are needed and editing lego pieces and changing the way lego pieces connect points to mistakes made in the initial "bad" design.

Note that None of the above has anything to do with cyclomatic complexity or symbol counts. You can have highly modular code with high cyclomatic complexity, you can have highly modular code with many LOC, and you can have highly modular code with high symbol counts. That's just one problem with your proposal.

This is the other problem:

Your "metric" is just a "metric". Theories don't deal with metrics as metrics are statistical measures... like how an average that hides the individual values. This approach is less "theory" and more "scientific" I would say. It has some validity but it treats the system as more of a black box and uses a very blurry metric to essentially guess how good a program is. But this is no theory.

>I guess, at the end of the day - I think we do have enough to propose some basic theories about program "goodness". SOLID could be one such theory, if it were rendered into much more formalized language.

It can't. SOLID is like color theory. It's made up. You know why color theory is bullshit right? It states that there are three primary colors, red, blue and yellow and all colors stem from those three primary colors when in reality color is a wavelength and our eyes only have cones for RGB. Yet people from both within art and outside of art fall for this theory because it presents itself in a beautiful way with the color wheel, secondary colors and tertiary colors. I mean somebody just made this shit up and it became convention in the field of art. Believe it or not much of computer programming outside of academia is full of color theory-esq bullshit. Take Solid:

The whole acronym SOLID is just as gimmicky. Someone chose certain words and decided to order those words so it spells "SOLID"... I mean that's more marketing then an actual attempt at a formal theory. It's just staring you in the face. It's not speaking to some foundational aspect of software design it's something someone pulled out of their ass. Like color theory it actually somewhat works, but also like color theory there are aspects of it that won't work and are utter bullshit.

You've probably been a staunch believer of SOLID for a while now. Impossible for people to change a long held view from logic alone. Such change takes time. I'm not saying SOLID doesn't work, it could be quite practical. I'm saying SOLID isn't anywhere near a formal theory nor does it have any chance of becoming an actual theory, it's like color theory... just rules of thumb for an artist and like color theory it's very very incomplete and likely not accurate to what's really going on with a "bad design".

The sad part here is that there's no alternative to turn to. Since there is no formal theory, bullshit stuff like SOLID or GOF Design patterns are much more likely to exist because we have no solid foundation to compare these things to.