> Yes, like the shorter version might be overlooking many real world > situations and is naive code. As for generalization, if you bet that the > shorter one is later written, that's to me a generalization. I agree that > there is a change that after reexamining the code, and algorithm can be > written shorter, but I have also seen algorithms refactored for better > readability.
All very good points - I need to be more specific. I've been working on some data analysis stuff etc, lately - so I'm often time just reimplementing a specific algo or library I've written. The actual program as a whole generaly does get larger. But I was really thinking about a handful of data manipulation or aggregation algo's that were functionaly fine - but I realized could be done better. > > Two points here. I have since the beginning stating a HYPOTHESIS - a > > theory. One which my experince leads me think MIGHT be true. > > Enough to bet on it ;-) > I'm a gambling man, what can I say? > >> Yup, and this is exactly what frightens me the whole time in this > >> thread. People looking for quality rules based on line count. It's > >> wrong. > > > > Please note my original hypothesis was maintainability - not quality! > > Aren't those closely related? > Yep, but not the same thing. Maintainability is a subset of quality. > > important important distinction - and one I may have muddles myself as > > I got drawn into the conversation. > > And what frightens me are people who are so dogmatically convinced > > becasue of their long 10 years of experience - that they know exactly > > what does and doesn't matter, and have no intellectual curiosity > > anymore. There are no objective tests for maintainability that I am > > aware of. > > Because it depends a lot on the skill level of the maintainer. By just > counting lines and characters you can't measure quality IMO. It's a naive > way of measuring and it reminds me of the early days of search engines. > > And if you mistake understanding that it's not a good way to measure > things as having no intellectual curiosity, you're again mistaken. > All I would ask is what objective evidence does either of actually have? How can you know? What is a fair way to even count line numbers? From there how do we begin to objectively measure software quality? That's why this discussion interests me, and why I don't understand why you are so adamant it doesn't work. I'll agree that I have never seen line count/char count type data used for anything other than marketing swill and kitty litter. Doesn't mean it can't be used. But first things first... and this one I think is solvable - their has got to be an equitable way to count how much code was written - maybe it isn't lines maybe it is. In truth, since you are so opposed to the idea, I'd be curious if you can think of a way to measure the quantity of code objectively? ANd that's it - not can we make a qualitative statement beyond that. But simply can we quanitfy the amount of code in some fashion that allows a reasonable comparison? -- http://mail.python.org/mailman/listinfo/python-list
