Closed (fixed)
Project:
WSCCI
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
25 Sep 2011 at 21:06 UTC
Updated:
25 Oct 2011 at 01:00 UTC
Jump to comment: Most recent file
Variables of the same type/meaning naming is not consistent in the API. Opening this issue to track them down and fix them.
It's better to have a poorly named variable but using a consistent name accross the framework than having 10 good names for the same things and always switching from one to another.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | better-variables-names-2.patch | 8.17 KB | pounard |
| #15 | better-variables-names.patch | 8.03 KB | pounard |
| #9 | context-to-contextvalues.patch | 3.49 KB | pounard |
| #8 | offset-to-contextkey.patch | 6.85 KB | pounard |
Comments
Comment #1
pounardFirst one spotted: in DrupalContext::registerHandler() first parameter name is $context: it should be $offset to be consistent with offsetExists() and offsetGet() methods.
All over the API all variables that contains a "context key" should be called $offset (or $offset should be changed to something else everywhere, including ArrayAccess methods).
$context may be reserved to DrupalContextInterface instances.
Comment #2
Crell commentedIf we end up dropping ArrayAccess, then all $offset references should probably fold to $context_key.
I agree with reserving $context to context objects.
Comment #3
pounardPotential second one: the $context property of DrupalContext is not a context, but context data, may be something like $contextData or just $data could be better?
Comment #4
Crell commented$data is a terrible variable name, as all variables are data. :-) But yes, it's a poor name. $contextValues, perhaps?
Comment #5
pounard$contextValues sounds good!
Comment #6
Crell commentedPatch welcome.
Comment #7
pounardWill do, don't worry, everything at its time.
Comment #8
pounardFixes #1 $offset removal.
Comment #9
pounardFixes #4 $context to $contextValues
Comment #10
pounardComment #11
Crell commentedThose are not going to both commit as patches, since they affect the same lines. Can you make a branch that has both of those as separate commits, one after the other? I can merge that in fairly easily, I think. Git is smarter than patch. :-)
Also, $contextKey is not a valid variable name. It's not an object property, so should be $context_key. $contextValues is fine as that's an object property.
Comment #12
pounardWhy do you stick with names with _ while the whole code is camelCased? I sincerely think it mixes multiple conventions and is confusing.
Comment #13
Crell commentedDrupal's coding standards say non-property variables are $lower_case_named. Until/unless that changes, that's what we use.
Comment #14
pounardI will respect the convention, but it does not prevent me from arguing them.
By the way http://drupal.org/node/608152 does not include any comment about variable in OOP code. While http://drupal.org/coding-standards remains strongly procedural oriented: I think there's some void arround the topic which makes it arguable.
Comment #15
pounardHere is a patch, fixes:
1. Some $context to $context_key (Context::registerHandler() signature)
2. $offset removal to $context_key
3. Context::$context to Context::$contextValues
Comment #16
Crell commentedProper spelling: Lazy instantiation. :-)
$handlerValue should be $handler_value.
Otherwise looks good.
Comment #17
pounardFixed and pushed in the 1290476-variables-naming new branch.
Comment #18
pounardComment #19
Crell commentedThanks, pounard. Branch has been merged.