Dave Crane looks into some Scriptaculous code. The main point is that Scriptaculous is easy for novice JS programmers to use, but the source code would be difficult, for novices at least, to understand. Which raises these questions:
In theory, the implementation of a library shouldn’t matter to developers using it. That’s because a good library should offer components that are open for extension, but closed for modification - the open-closed principle. Thus, you should be able to treat the library as a black-box and only care about the API it presents - you never have to maintain it, so why read the code?
But it’s usually not so simple. You might not need to change the code, but you do need to understand it. In an ideal world, there would be abundant documentation. But agile says that all that documentation is valuable, but self-documenting code is much more valuable. In similar vein, the availability of code is often justified as a reason for open-source projects to include less documentation (among other benefits). So open-source code had better be understandable, ideally self-documenting, but at least well-commented.
I have used (by “used”, I mean “wrestled against in a cage match”) a couple of very prominent Java EE frameworks where implementation code is confusing and badly in need of refactoring, with most of the code comments in “TODO” and “Weren’t you going to fix this?” territory. I was stuck and documentation was insufficient, so I could only turn to the source code for help. And that’s actually a pretty good place to work out what’s going on anyway. But, alas, the code did not come to my aid. ** Perhaps that’s the natural consequence of an open-source project becoming a startup with a support-based revenue model, but it makes a mockery of the code-as-documentation argument for open-source.**