>> It is plain that as of now, there are only 2 "strong/loud" arguments.
>> I am sure you all will agree that both of them are not overly
>> subscribed by any majority yet.
> Yes but there is only one idea on the table, and 1 set of criticisms
> followed by absolutely no suggestions on how to better the first idea.
> This was really my bitch about the first set of posts.
Then frankly, you misread.
1) All code must be commented. Ideally, this would be a priority such
that commenting existing code would be an actual project, but
realistically, the goal of "all NEW code must be commented" or perhaps
"every time you touch the code, a comment must be inserted" is doable.
2) The current (4.x) architecture uses a number of "common" functions
(so identified by virtue of living in the include directory) that are
not really common. An easy test is that if at any time a soi-disant
"common" function tests to see what module it was called from and then
acts differently based on the result of that test, it ain't common.
Those functions should be broken out of the include directory and moved
into the appropriate module directory - perhaps something like
modules/Foo/UI.php (although this naming convention is definitely open
3) Any time you go to the database, the actual SQL should be exposed; it
helps integrators understand the layout and function of the database and
makes extending the database much easier. It's OK to streamline db
functions somewhat though - something like:
$query = 'SOME SQL';
@2D_array = query_db($query) or handle_db_error;
3) All modules must be atomic. At no time is it EVER permissible that
changing the code in module FOO *changes* the functionality of module
BAR - with one exception; if module FOO ever *calls* module BAR, and a
code change to BAR has broken the interface, then it is understood that
FOO calling BAR will break (and shame on whoever changed BAR's
In some cases, this will actually move functionality INTO common code,
and that's a good thing. For example, currently HelpDesk calls code in
Emails to do its email notification stuff (HORROR!) This would be better
served by a function in utils.php that called some sort of generic email