1

I have a file (or rather, a list of about 100 files) in my website's repository that is still requiring the use of register_globals and other nastiness (like custom error reporting, etc) because the code is so bad, throws notices, and is 100% procedural with few subroutines.

We want to move to PHP 5.4 (and eventually 5.5) this year, but can't until we can port these files over, clean them up, etc. The average file length is about 1000 lines.

I've already cleaned up a few of the low-hanging fruit, however the job took almost an entire day for 2 300-500 line files. I am in a quagmire here (giggity).

Anyway, has anyone else dealt with this in the past? Are there any strategies besides tracing backwards through the code? Most static analysis tools don't look at code outside of functions - are there any that will look at the procedural code and help find at least some of the problems?

5
  • What is the quality of the code except from the register_globals issue? Most of the time there are even bigger issues because of the register globals like shared functionality, code duplication etcetera. Would start with getting a good view on the rest of the issues outside of this issue. – Luc Franken Jun 27 '13 at 9:16
  • The code quality is poor. Code duplication isn't going to hinder my efforts in upgrading to PHP 5.5, but register_globals will. – Jonathan Rich Jun 27 '13 at 14:07
  • There are many different ways but it seems register_globals are not the biggest issue but the software as a whole is. The wish to upgrade to a more recent PHP version is understandable but I would suggest taking it up as a total project refresh. That way register_globals are not relevant anymore. Mostly because for example testable code does not work with register_globals so you will remove them at once in the process. – Luc Franken Jun 27 '13 at 18:24
  • The codebase itself is roughly 4500 files, of which there is a large percentage that are PHP 5.5 ready and aren't complete shit. These 100 files are legacy files, which work yet see few changes, which are currently a roadblock to upgrading PHP. – Jonathan Rich Jun 27 '13 at 18:31
  • Clear, that gives some more context to the question. If it is just the upgrade which is what bothers then it is the solution to go manually through the files. The thing which bothers me is the fact that you still have the work to refactor later so it feels like double work. But if that upgrade is really important to you that might be enough reason to do so. If you have enough development time available I would start doing full refactoring on them. If you just want the upgrade go manually. Quick: Extract $_GET, $_POST, $_SESSION at top of the script. Security stays about equal (bad) but works. – Luc Franken Jun 27 '13 at 19:15
1

This Operation Called refactoring

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a
series of small behavior preserving transformations. Each transformation (called a
'refactoring') does little, but a sequence of transformations can produce a significant
restructuring. Since each refactoring is small, it's less likely to go wrong. The system
is also kept fully working after each small refactoring, reducing the chances that a
system can get seriously broken during the restructuring.

Read about strategies for PHP Code Refactoring

And you actually have to do it your self there is no way to make the process faster Just search about PHP Big Refactoring there is a strategies to keep the code clean and might help you in your process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.