Forum OpenACS Development: Re: Tipping of coding practices ?

Collapse
Posted by Dirk Gomez on
Maybe my wording wasn't good enough, but I didn't intend to speak about coding practices but about "who is going to get this done?". My criticism was/is geared towards a fact that we don't need a TIP if there is firstly noone to lead the work and secondly noone to do the work.

The points I sketched up are the guidelines I follow when working with OpenACS.

Thanks for your criticism, I hope someone who is willing to lead such a project will pick it up.

Collapse
Posted by Jeff Davis on
I think we need to develop a "coding standards" document as the first step of a code cleanup adventure (and to the extent that there are controversial issues there might need to be some TIPs; I would define controversial as something someone cares enough about to write a TIP on). It's definitely the case that many of the bad examples in the toolkit are copied into new packages on a regular basis and cleaning things up would make the toolkit both more robust and more pleasant to work with.

Dirk's point is a good one though, unless there are some people willing to do something besides just post on the forums about this it's unlikely to matter one way or the other. I will try to pull a draft together based on the various threads we have had in the past but I will be sorely disappointed if those of you who seem to care about this stuff are not willing to wade in and fix it.

The things can think of off the top of my head are datamodel create scripts, using namespaces, seperation of markup and code (and especially removing tcl from .adp files), package structure (which mostly needs to be updated, to be in line with tip 12), the ad_proc, ad_page_contract, ad_library javadoc tags, and declaring things public or private.

Also, I think we need a TIP for how we are going to remove deprecated functions (a la set_form_variables_string_trim_DoubleApos and util_PrettySexManWoman), since I would really like to clean out some of the really crufty stuff. I think remove anything two releases after it is -warn (i.e. remove the 4.6.3 -warn things in 5.1 and the 5.0 -warn things in 5.2) but that is probably something we need to talk about more and make a formal decision on.