Post #319,776
1/8/10 7:02:20 PM
|
Why would you rename variables?
The code I'm rewriting frequently takes request variables (submitted via the browser) and renames them to something else for use throughout the app. It seems to me the better idea would be to name the request variables the useful thing you want, rather than renaming it once it comes in. The way it is now, I keep having to check if the variable I'm sending turns into something else on the receiving end.
Is there some reason to prefer the current method? Since I didn't take CS in school it's entirely possible there's some "best practice" I'm not aware of. Or am I just cleaning up behind an idiot?
--
Drew
|
Post #319,778
1/8/10 7:33:55 PM
|
I'd suspect reuse of another routine.
I didn't take much in the way of CS classes, either, so have your salt-shaker handy.
Presumably the code was written over time, perhaps by several people, and they got sloppy about the naming. Or they cut-and-pasted code from other programs that had the needed functionality, and didn't refactor it.
My understanding is that Best Practices generally say that you should have private routines that pass pointers or values back and forth, and not depend on magic names to move data around through the code. Most of the guts of the work should be done with private variables. (IOW, Globals Variables are Bad - http://c2.com/cgi/wi...alVariablesAreBad )
I can't see any benefit of taking a variable that holds user-entered data and renaming it to use elsewhere (unless it's an attempt to minimize Globals). Ultimately, the information gets pushed onto a CPU register - the transistors don't care what you call a variable.
HTH a little. Corrections welcome.
Cheers,
Scott.
|
Post #319,779
1/8/10 7:44:46 PM
|
Oh, it's definitely *not* to avoid globals
I've got one function that passes 35 globals. The "design" -- such as it is -- seems to be: "Pass everything everywhere, because you never know what you might need."
--
Drew
|
Post #319,781
1/8/10 8:28:23 PM
|
Sounds like one of my old QuickBasic programs. =(
|
Post #319,782
1/8/10 8:30:28 PM
|
Re: Why would you rename variables?
perhaps to preserve uniqueness? The way they are doing this is a
getVar=uniqueName
newVar=$getVar
trundle about using $newVar everywhere
does that describe what is happening?
|
Post #319,785
1/8/10 10:33:09 PM
|
Not quite
$action = $_REQUEST['action'];
$Responder_ID = $_REQUEST['r_ID'];
$Search_EmailAddress = $_REQUEST['email_addy'];
$Subscriber_ID = $_REQUEST['sub_ID'];
It's a combination of hacked-in register_globals(), with a measure of short-to-long name conversion. It's like he thinks he's going to run out of space in the URL.
Oh, and the really fun part? $_REQUEST is already global. So it's adding an extra step to rename them, and then everywhere you pass it into a function you have to remember to global it again. --
Drew
|
Post #319,788
1/8/10 11:01:58 PM
|
anything special about $_request?
it may be he just wanted to determine a request from a different action for rememberability. I wouldnt do it that way
|
Post #319,790
1/9/10 12:32:30 AM
|
Special variable in PHP
$_POST is an array of any variables received via HTTP_POST. $_GET is an array of ... well, yeah. And there's also $_COOKIE. $_REQUEST is all of the above. All of these are there automatically, in global scope, and can't be modified.
The only reason (I can think of) to copy those variables out to something else is if you want to modify them. But that's not what's happening. He's just renaming them.
The amount of copy/paste is also impressive. I'm thinking total LOC could drop by ~30% just by refactoring without changing any functionality.
--
Drew
|
Post #319,791
1/9/10 12:50:44 AM
|
Actually, they can be modified.
I've got code that sets a value in $_REQUEST as part of the page initialization: it actually checks to see if an entry is set and if not, provides a default. This is because there is scads of code that just uses the entry in $_REQUEST without checking to see if it is even there...
(I filed a bug that PHP's default error level should include Notices turned on. They closed it as not a bug, citing the docs that say you should change it for development, but ignoring the fact that many developers never touch the php.ini file.)
I think what your programmer is doing is avoiding continually referencing $_REQUEST, perhaps under some impression that a direct variable lookup is faster than an array lookup. Or should I say, that it is faster enough to make a difference.
Wade.
Q:Is it proper to eat cheeseburgers with your fingers?
A:No, the fingers should be eaten separately.
|
Post #319,800
1/9/10 11:50:39 AM
|
Did not know that
It's been a while since I read the docs, so it's likely my recollection that "you can't change them" was based more on how you should do things than the mandates of the language. Changing a $_REQUEST value makes about as much sense as changing a $_SERVER variable. Even if you can, I really don't think you should.
--
Drew
|
Post #319,822
1/10/10 4:04:40 AM
|
I was rather glad it was possible.
But I don't like it, either. When I have opportunity (which doesn't happen as often as I would like), I refactor code that relies on that trick to not rely on that trick. Many other improvements often happen at the same time...
Wade.
Q:Is it proper to eat cheeseburgers with your fingers?
A:No, the fingers should be eaten separately.
|
Post #319,793
1/9/10 5:55:11 AM
|
If speed counts ...
As a general rule, 2 accesses via index or hash is the limit of how many times I'll touch a variable before I decide to rewrite an pull it into a local one and all accesses are from the local one that moment forward.
Also, some languages do reference by default so variables are modifiable and can be broken by accident, so some programmers get into the habit of doing a local copy for safety.
|
Post #319,816
1/9/10 9:18:57 PM
|
There is, but it doesn't look like that's what is being done
There's a rule of thumb: never modify your inputs. If you need to modify something that is passed as a parameter to a method, then copy it first (which involves renaming, natch).
Regards,
-scott
Welcome to Rivendell, Mr. Anderson.
|
Post #319,851
1/10/10 7:15:39 PM
|
Like I told Wade, I didn't think that was an issue here
Apparently you can modify the PHP superglobals, but I don't. This could be defensive programming, but even if it were, why would you keep renaming from "responder_id" to "r_id" and back again. It makes it confusing as hell.
--
Drew
|
