Wednesday, November 28, 2007

Some Metrics






LanguageAvg Methods/ClassMax Methods/ClassAvg Params/MethodMax Params/MethodAvg Fields/ClassMax Fields/Class
Squeak9.397800.64161.02100
Ruby12.696830.4270.7631
Java8.671810.91122.42343

I ran the metrics, that I talked about in my last post, in three environments and the results are above. Nothing really shocking, but the maxes did surprise me. I was mainly interested in the averages and the maxes were there just to see how huge the big boys really are.

I wonder what developers would think of a language that restricted the number of things that they could define. What if by looking at the numbers of above, I designed a language that didn't allow more than 256 methods/class, 8 parameters/method, and 16 fields/class. It would force the developer to write smaller entities, but would it annoy more than help?

Where I'm going with this is simply, what if the language enforced certain hard restrictions instead of allowing any incredibly large number of possibilties? If elements were kept to a certain size, would it make programming in the system more pleasurable since it would be difficult to create a god object? Objects would not get out of hand before refactoring thus making maintenance easier.

My gut instinct is that constraints would annoy and ugly code would still live. Developers would just figure out ways around them. I would love to think that by adding constraints, we could get better code. But, no matter what you measure quality by, there will be developers that will figure out how to get around it. Pessimistic, I know. But, it's simply human nature.

Still, I wouldn't mind if the language did have some limits, so that individual items stayed small. If the constraints were not dogmatic, it would make the need to get around them less attractive. Of course, with smaller things comes naming them and that would still be a problem. But, that's a problem with mammoth sized objects as well. I'll keep thinking on this. There's got to be a way to have flexibility to dream the impossible and yet gently nudge us into more maintainable programs at the same time. The problem with balls of glue is that slowly become that way. It would be nice to not allow them to become Godzilla.

5 comments:

Sammy Larbi said...

"There's got to be a way to have flexibility to dream the impossible and yet gently nudge us into more maintainable programs at the same time."

How about an IDE that gets slower as the classes/files become bigger?

Blaine Buxton said...

LOL. Don't we already have that with Eclipse? =) I don't mean to dog Eclipse since I do love it and can't imagine doing java without it.

Sammy Larbi said...

That's incredibly funny because Eclipse is what prompted the comment.
=)

Anonymous said...

World Of Warcraft gold for cheap
wow power leveling,
wow gold,
wow gold,
wow power leveling,
wow power leveling,
world of warcraft power leveling,
world of warcraft power leveling
wow power leveling,
cheap wow gold,
cheap wow gold,buy wow gold,
wow gold,
Cheap WoW Gold,
wow gold,
Cheap WoW Gold,
world of warcraft gold,
wow gold,
world of warcraft gold,
wow gold,
wow gold,
wow gold,
wow gold,
wow gold,
wow gold,
wow gold
buy cheap World Of Warcraft gold n3j6t7id

Anonymous said...

World Of Warcraft gold for cheap
wow power leveling,
wow gold,
wow gold,
wow power leveling,
wow power leveling,
world of warcraft power leveling,
world of warcraft power leveling
wow power leveling,
cheap wow gold,
cheap wow gold,
buy wow gold,
wow gold,
Cheap WoW Gold,
wow gold,
Cheap WoW Gold,
world of warcraft gold,
wow gold,
world of warcraft gold,
wow gold,
wow gold,
wow gold,
wow gold,
wow gold,
wow gold,
wow gold
buy cheap World Of Warcraft gold g3l6c7jc