If you are running PHP in such a way as it runs as Apache's user (i.e. "www-data" on debian systems, "nobody" on CentOS+cPanel shared hosts, ...) then the owner of the file doesn't really matter from the PoV of being called via Apache - PHP and therefore the script will always be running as the Apache user not the user that owns the file.
If you run PHP as a module then this is almost certainly the case.
If you have PHP configured to run scripts as the specific user (via suphp, suexec, or similar - you may be doing this if you run PHP via the CGI or FastCGI methods) then having script files owned by a privileged user is a very bad idea.
As for "777" permissions, this should be avoided too especially if you are not the only user on the server. I would instead make sure that the directory is owned by the user Apache will be running PHP as and use "700" (or in a group that this user is also in and use 770). For greater paranoia, if your scripts will always know the filename they want and don't need to read the directory listing, disallow execute permission on the directory too.
Also never have scripts world-writable. Default suPHP setups actually protect you from this a little by refusing to run scrips that with permissions that are world-writable (or in directories that are).
As a general rule, I avoid using less restrictive permissions in development than would be needed in a live, publicly available, environment. This avoids accidentally leaving the perms too permissive when promoting code to live, and avoids introducing bugs where your code assumes more permissive access than it is allowed in the live environment.