> It's not as easy as that. Not only is the code constantly improved, > our standards which idioms are considered good and which are considered > dangerous constantly evolve as well, slowly turning new, high quality > code into old code of lower quality - even if the code remains > completely unchanged. Actually, the quality of code diminishes in > time *in particular* when it remains unchanged.
I understand. And, the code itself is ultimately the specification. And that reason, why not select single component to be as a reference? And the reference component: "This is finest peace of code at the moment", "Make rest of the code looks like this", "Everything that is diffent to reference is wrong way to do", "If some convention just doesn't work, fixed it to reference first" > The best way to learn is to read code, understand it, find > weaknesses, suggest improvements, and when we agree on the > improvements, systematically audit the tree for similar > problems. Some of the improvements may require enormous amount of effort to apply whole tree, and requires also that when applying changes, have to continuously learn/keep in own knowledge different source components. I don't expect that everyone have interest to all of the components, so it doesn't motivate to hack all components. That must be taken into account Like you say, quality standards are rising all the time, I think it is good to have reference component and accept, that rest of the source tree may have little behind in quality. I have used this practice in my own code. Every time I learn new tool/language/framework etc. I make first component to reference and then apply all practices rest of the components. I've never tried this on larger scale, in open source projects.
