Why have coding standards for OpenACS? And if the code works why change it to adhere to some arbitrary rules?
Well, first lets consider the OpenACS code base (all this as of December 2003 and including dotLRN). There are about 390,000 lines -of tcl code, about 460,000 lines of sql (in datamodel scripts and +of Tcl code, about 460,000 lines of sql (in datamodel scripts and .xql files), about 80,000 lines of markup in .adp files, and about 100,000 lines of documentation. All told, just about a million lines of "stuff". In terms of logical units there are about 160 packages, 800 tables, 2,000 stored procedures, about -2,000 functional pages, and about 3,200 tcl procedures.
When confronted by this much complexity it's important to be +2,000 functional pages, and about 3,200 Tcl procedures.
When confronted by this much complexity it's important to be able to make sense of it without having to wade through it all. Things should be coherent, things should be named predictably and behave like you would expect, and your guess about what something @@ -36,7 +36,7 @@ Follow the file naming and the package structure rules. Some of the file naming rules are requirements for things to function correctly (for example data -model creation scripts and tcl library files must be named properly +model creation scripts and Tcl library files must be named properly to be used), while some are suggestions (the object-verb naming convention) which if ignored won't break anything, but if you follow the rules people will be able to understand your package much more @@ -99,8 +99,8 @@