IDE proponents love, in fact, an Integrated Development Environment that provides all the functionalities you need while writing and editing code; the followers of the Unix way typically write code in Vim while augmenting it via plugins where feasible and leveraging external tools that do one thing, and do it well. [...] Automated refactorings in PHP were out of the league of Vim and Unix users; thanks to Qafoo, however, a new open source tool is able to edit code with predefined refactoring recipes: PHP Refactoring Browser.

He goes through some of the basic features and functionality of the browser, setting expectations a bit. He shows how to get it installed (via Composer) and the results of some of his testing. Rather than including them all in the post, he opted to make actual commits on github of the changes.

Without continuous refactoring, code maintainability and extensibility will start to decrease fast, even if it has tests. Until now, only IDEs contained functionality to perform automated refactorings. And then even only PHPStorm contains the most important refactorings such as "extract method". Today we release the PHP Refactoring Browser, a refactoring tool written completely in PHP. It is based on several outstanding open-source libraries.

The browser currently supports multiple refactoring methods including the extract method, renaming of local variables and converting a local variable to an instance. They include some example code and the result from the execution of the tool. The output shows where refactoring would work best with some color coding and formatting.

You can find more about this new tool over on its github repository.

The downtime [of this week] provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there's no time to do: make the code better for better's sake. With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the "lost week" can be redeemed.

He has a few recommendations, each including their own brief summary:

• Test Everything First
• One Method, One Job (Also One Class, One Job)
• Don't Be Afraid Of More Objects And Classes
• Remove Dead, Unused, Unnecessary or Old Code
• Document Your Code

Check out the full post for the summaries and links to other useful resources.

Stopping development for weeks while you figure out how to add unit tests to cover your entire codebase is simply something that cannot be done (at least, not if you want to keep your job), no matter what future benefits it might bring. The good news is, adding unit testing to your existing project only takes five minutes - which is pretty much how long it takes to get a unit testing framework installed. That's it. Move on.

He puts the emphasis on unit testing to manage change in a code base, not so much to ensure that the current application runs as it should (not initially at least). He's found them most useful in bugfixing, refactoring and when adding new functionality. Current tests (and even tests written in TDD) can help with all of these. He includes reminders that if the tests aren't written well, they're useless and that once you've started testing, it needs to be continuous, even if they're not perfect.

Both solutions allow to instantiate an anonymous object with properties. They are used as value objects and have no other purpose than storing values, so no logic can be included and they don't come with methods. They can be used as function parameters instead of arrays, for instance. PHP 5.3.0 introduced anonymous functions and closures, so it is now possible to attach functions to these VOs (*). [...] The first thing to notice is that these properties are not methods but callable functions:

In his example, an anonymous function dynamically appended to an object doesn't have access to a property set on the object just one line before. There's a way around it with call_user_func, but it's not practical. His proposed solution is to create a type of Anonymous class that uses the __call method to catch the methods and translate them into calls to call_user_func_array automatically.

Recently while on a drive with a non-programmer friend, I talked with him about code complexity and manageability, how very complicated code is detrimental to productivity and stuff like that. Later on, I decided to explain it to him with actual code examples, although the most he has ever done was some HTML back in elementary school.

He starts with a basic PHP+HTML+MySQL script that mixes the three and shows how to break it apart in steps - moving the PHP away from the HTML, creating functions and making a "template" for the database fetch results to display in.

Shortly after Chris Hartjes released his new book Refactoring Legacy Applications Using CakePHP he contacted me and asked if I'd be willing to review it. I jumped at the chance and Chris emailed me the DRM free PDF. After posting it to The PirateBay, I settled in and gave it a read.

Overall, Matt found the content of the book good but had a few things he might change - the "too smooth" nature of the update to CakePHP and the inclusion of a "partial refactoring" section (one that talked about only updating part of an application to the framework and integrating it with the rest of the site).

Some of you may know that I have started writing a e-book about CakePHP. I'm planning on publishing it myself for the low, low price of $7. I thought I'd let people take a sneak peek at how it looks so far by publishing the first two chapters in very rough form.

You can find a rough draft here (pdf). Keep an eye out on Chris' blog for more (possible) preview releases and for the final product once its wrapped.

Refactoring neither fixes bugs nor adds new functionality, though it might precede either activity. Rather it improves the understandability of the code and changes its internal structure and design, and removes dead code, to make it easier to comprehend, more maintainable and amenable to change. Refactoring is usually motivated by the difficulty of adding new functionality to a program or fixing a bug in it.

He's broken it out into a few topics with the suggestions underneath - things like looking at the "Big Picture", avoiding "Extreme Abstraction" and ensuring that your "Error Handling" is up to where it should be.

I have had to go through a php application recently which has given me more than one headache and has required me to use all my possible patience. While working with it, I thought This is good material for an article, so that nobody else does the same in the future, and nobody else will need to experience the same displeasure as I have had to.

So here are the signs your PHP application needs a serious refactoring, right now

Included in the list are things like:

• Uses global variables
• Everything's an array
• The neverending switch
• Interface inconsistency

It hits on one of the thing that bugs me too, the problem of "Brackets galore" - so many subarrays that you have to resort to three or more sets of bracketed keys to get to the value you want. It's bad enough trying to follow someone else's code without having to "trace down" an array to figure out which of the values they're talking about.