Forum OpenACS Development: Re: ad_parameter deprecated in favor of parameter::get?

you make my point for me -- if you are naming variables based one what your dog did this morning, that is your problem and your toolkit should not attempt to bandaid it by naming its function parameters.
Collapse
Posted by tammy m on
Unless I'm reading someone else's code (or many, many someone elses' code written at all different phases of the frameworks life, when variable naming standards/fashions changed) for examples and their variables are named in some or other historic fashion that makes sense in the greater scheme of what they are used for (the overall goal of the package/form/etc they are writing) but not as individual arguments to every single OACS method call in any other package whose procs they call.

For instance I'm writing a package that sells hamburgers at a drive through window (lightening up the conversation a bit;)
My variables are called drive_through_car, window_guy and order (and so). These make perfect sense in the scenario I am coding for on an overall basis and make it so that I can call my objects what they represent in the real world instead of a language or data structure specific name (user_id, write_privilege_p, whatever).

Now that makes all the code in my package easy to follow and the same object is always called the same variable name across the board. However deeper in my code where I have to call other packages, should I make it clear like this each time I call other code?
set user_id $window_guy
set object_id $cash_register
set privilege_id $cash_register_access
[permission::permission_p  $user_id $object_id $privilege_id]

Or it could look like this:
[permission::permission_p -party_id $window_guy -object_id $cash_register -privilege cash_register_access]

Of course this is just an example and permission::permission_p AFAIK requires named parameters.

It just is not always clear even if you are the ultimate God of writing perfect code (and every other who contributes to the code base is too) and it shouldn't have to be assumed that variable names will make procs understandable. Just like docs and comments aren't always there when ya need them either.

Whatever, it's just an opinion different from your own from someone who might be representative of newer users to your system... who aren't perfect, mean well, and would like any bit of help the code standards might be able to offer them in following the code.