RE: [binarycloud-dev] binarycloud r2 pre-final docs

[Andreas A. <a.a...@th...>]

Hi Alex,

> The private method thing is a standard.
Agreed. This is also the I use it.

> /index.php?.foo=hello and get in php: $_foo
> which is quite useful, because you have a good way of always identifying
> what came in frmo the user, as opposed to "internal" variables.

Ok, good point. I did not consider that. Actually I was not aware that the
dot is translated to an undescore. Never used that this way.

> It's _very_ important to have a variable naming domain that identifies
user
> input, in my opinion.
Yuup. Better than only importing variables formerly defined as valid user
vars. Ok got that. $_global is good, at the cost of strange looking, but
thats worth it.

> But again, for those of you with suggestions, etc please speak up. Some of
> the code it written, but I'm happy to change it.

Ok. My suggestion is to use straight forward naming of methods and varnames:

Methods: setName() or set_name()
privat class methods: _setName() or _set_name()
Variables (global) , as discussed before: $_varName or $_var_name
Variables (other): $varName or $var_name
Classnames: Auth, ExecutionTimer

Personally I prefer the setName and $_varName, $varName case. Becaus the
seperations is more clear. Usage of "_" only for the extra "namespace" and
for private class methods, not for seperation. But thats personal taste I
guess. Important is to have a standard.


> heh, your app framework is called storm - which is the name of the
> binarycloud admin interface.
Yes, the name is borrowed (hope you don't kill me for that ;-)). Actually,
it's not a full working framework. Currently it's a colletion of libs I need
for smaller projects (metabase, smarty, template abstraction, session
abstraction, some language specific files) as a intermediate until bc r2 is
usable :-)

I also see why you find the $_global_variable_name standard yucky, because
you have it defined just the opposite in your docs.
Hehe ;-)

> convention. I have used .var with good results, it's easier to track the
> security of a codebase.
Ok, you convinced me in this point.

Andi