Danny,
> I subscribe to the XP view that a requirement for extensive commenting of > sources is in avoidance of writing clear code. I don't necessarily disagree with this view - on XP projects. As we discussed on the list the last time this came up, there are a number of XP methodologies that are precisely designed to spread the knowledge in lieu of code commenting (developer rotation, pair programming, design reviews, etc.). James developers don't have the benefit of any of these methodologies, so commenting is correspondingly more important as a tool for inter-developer communication. > Obviously this has to be tempered, in a OS project particularly, with the > need to make the code accessable to any would be developer, and frankly I > think James own code is not the inscrutable part of this, the steep > learning > curve for interested participants is James use of Avalon in all its > guises. Speaking as someone who recently came up to speed on the James and Avalon code, I'd have to disagree with this assertion. The Avalon code and lifecycle were very easy to pick up - precisely because Avalon is very well documented. I found the James code far more confusing and inscrutable. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
