Writing refactoring-friendly PHP code

Question

As far as I know, and have gathered from other SO posts, there are no proper tools for refactoring PHP code yet, so when it comes to refactoring, it's probably good old search-and-replace for most of us, with a good amount of praying that we didn't overlook something.

I would like to know whether there are any coding recommendations on how to write code friendly for manual refactoring. Never to construct variable names from strings, would be one thing that comes to mind because a construct like that is impossible to grep:

$object->{"field_".$fieldname}

I could imagine there are several such do's and don'ts. Maybe somebody knows good resources / articles on the issue. It wouldn't have to be PHP specific, either.

Answer 1

Unit tests always help me identify places where I've broken code due to a refactor. Unit tests in dynamic languages (PHP, Ruby, Python, etc.) provide assistance where static typing in other languages (Java, C#) would typically allow you to more safely refactor.

Answer 2

Your question makes a certain amount of sense. But—at the same time—it implies that the implementation is known to be inadequate, and written to be replaced. Why not just architect it properly the first time?

Answer 3

Well, The best way to write refactoring friendly code is to write loose coupled ,highly cohesive code and object oriented code.

You should try as much abstraction as you can, after all abstraction is the keyword while programming.

Moroever, you should be layering your code into presentation layer, business layer, data layer etc.. and Using design patterns is a pretty good solution.

I d recommend you to read Martin Fowler.

Answer 4

First, make sure your variable names make sense. If possible, go as OOP as you possibly can, or at least keep everything organized (image function file, database file, etc)

Second, and this is handy, check your IDE. Netbeans has options for refactoring. You can search in a file, in a folder, in a project, etc.

Answer 5

Avoid magic as much as possible: variable variables, eval, masking errors with @ and storing code in the database will come back to bite you.