A command line refactoring tool for PHP | Hacker News Reader

A command line refactoring tool for PHP

qafoo.com

62 pointsbeberlei34 comments

Is this really needed? I get away with :%s/$abcd/$this->abcd/gc just fine.

When you leave vim and do this:

    $ php refactor.phar convert-local-to-instance-variable tests/FooServiceTest.php\
    6 dependency | patch -p1

I stay in vim and simply do this:

    :%s/$dependency/$this->dependency/gc

And hit y a couple of times.

Pros:

I dont need to install, trust and learn a new tool.

I dont have to worry if i broke somthing. Because of edge cases the tool did not handle or because I messed up the syntax.

You picked the simplest refactoring, for converting local to instance variable I agree with you, this is easy in Vim.

But still there are some potential problems:

1. The variable already exists in the class. 2. You accidently mark to much or to few lines with ":<,>%"

For refactorings such as extract method the number of preconditions and information to gather is much bigger, such as input and output variables, existance of return statement etc.

We plan to integrate the tool into vim as well, so that you can call the refactorings through vim directly.

I did not pick anything. It is your example. Right from your page. And the only one you provide. If you have a better one: show us.

The blog post shows extract method as well as a second refactoring

Edit: Also see the screenshot here for a more complex extract method refactoring: http://qafoolabs.github.io/php-refactoring-browser/

Ah, I missed the extract-method example.

Similarely to the convert-local-to-instance-variable example, to me it looks like overkill. I never had a problem, doing these things manually. But if you like doing it this way - I dont complain. To each his own.

I never had a problem doing things manually either. However, as soon as I can automate them, I do. If I can automate extract method to, in effect, a single keystroke, why not?

It's the difference between using hjkl for movement, and ignoring all the other commands vim as to offer. Why wouldn't want you to automate patterns in your work?

I think that a tool like this will, with time, become much more efficient than a simple search replace. As mentioned in my sibling, there are edge cases which need thought, and a proper refactoring tool will excel.

I'd love to see a tool like this start to support a bunch of complex refactorings, especially on a project level. With time, it could start to support a bunch of nice things which make it easier to use, such as aliases or readline support for auto-completion, etc. People may then write plugins or scripts for various editors such as vim to make various refactorings even simpler to use.

Of course, this is all wild speculation, but it is what I would love to see. I hope it works out very well, because I am a massive fan of the refactoring in the IntelliJ PHP plugin/PHPStorm.

I have minimal exposure to PHP, but recently helped a friend out with a small project on the weekends, that someone else he knew had built. When I first saw the codebase I found a veritable mess of very unreadable unmaintainable code. No functions - no OOP of any kind - no separation of concerns - nothing reusable - SQL calls (probably vulnerable to injection) mixed with HTML - a hulking mess of spaghetti.

Can tools like these fix code like that, or at least help? It would have taken me about a day per page just to make it readable - and there were dozens of pages. I don't plan on going back into that minefield if I can help it, but it would be good to know in the future.

--EDIT-- Thanks for all the helpful replies. Luckily I'm pretty sure the project is behind me. Seeing that PHP reminded me of old bad ASP (pre .NET) - it was easy to get away with lots of really bad stuff (on error resume next anyone?). It makes me wonder if auto-refactoring spaghetti is a crackable problem. When I dared look I did see lots of things that I could have fixed with a little bash and sed, but of course I am human so I understand the 'intent' of the code. Fascinating stuff.

Those problems are not related to PHP but to inexperienced developers. Refactoring such code is always a pain. So unless there is nice money involved: don't refactor, just fix what's broken.

I don't think refactoring of spaghetti can be automated. But there are other tools that can help you to find bad code. Some that come in mind:

  https://github.com/fabpot/PHP-CS-Fixer
  http://pear.php.net/package/PHP_CodeSniffer/redirected

Those tools are used for coding standards (PSR-x), but those standards are also helpful to track down bad code.

Good advice, with a couple of caveats about PSRs:

- They're not all about coding standards: only two of them are. PSR-0 is a class autoloading standard and PSR-3 is a common interface for loggers. The next PSR is likely going to be a common caching interface.

- PSR-1 and PSR-2 are controversial (although PSR-1 less so than PSR-2), and don't necessarily represent best practices amongst the larger PHP community. They're useful insofar as the PHP Framework Interoperability Group (PHP-FIG, http://www.php-fig.org/), the people crafting the PSRs, needed an internal standard and really shouldn't be represented as anything more than that. Much of both standards are an amalgam of individual practices produced via an internal survey of PHP-FIG member projects.

If you have nothing, PSR-1 and PSR-2 aren't bad places to start, but diverging from them is more likely to happen than not, especially if you're working with projects or teams that have existing coding standards.

    > PSR-1 and PSR-2 are controversial
    > Much of both standards are an amalgam of individual
    > practices produced via an internal survey of PHP-FIG
    > member projects.

Those member projects include codebases like Zend Framework, Symfony, Composer and Doctrine. Those standards are are a very accurate representation of the way the best, most popular open source PHP code is being written.

The only controversy I'm aware of is those petty pull requests opened by people who didn't like that they chose spaces over tabs, which eventually drove one of the founders of the group to quit out of frustration.

> Those standards are are a very accurate representation of the way the best, most popular open source PHP code is being written.

PHP-FIG members have repeatedly cautioned[1][2][3][4] that the PSRs (notably PSR-2) are not a set of best practices, but merely a survey of commonalities of PHP-FIG member projects. Even then, several member projects do not, and have stated they will not, implement PSR-1 and/or PSR-2. Treating them as the best or most accurate representation of how PHP is being developed at large is exactly the wrong thing to take away from the PSR process.

[1]: http://www.php-fig.org/faq/

[2]: http://paul-m-jones.com/archives/2420

[3]: https://groups.google.com/d/msg/php-fig/TRpoq0kdrZk/OkyD-J4u...

[4]: Matthew Weier O'Phinney's comment on http://brian.moonspot.net/php-coding-standards

Currently the refactoring available for extracting code is "extract method". "extract function" is not available yet and may even be implemented as "extract static class" or something, because it may be safer to achieve.

Can tools like these fix code like that, or at least help?

If you're working with PHP professionally, invest in PHPStorm. The time savings it brings - not to mention, the improved reliability - make it an instant win.

How is it better than Netbeans or Eclipse? I've been using mostly the former (after Zend Studio went AWOL). How does PHPStorm compare to those alternatives?

How is it better than Netbeans or Eclipse?

It's been a couple of years since I last looked at Netbeans/Eclipse, so take this with a grain of salt: PHPStorm just works.

The biggest issues I used to have were finding Netbeans very slow, and auto-complete in both Netbeans and Eclipse being somewhat unreliable - great when they worked, but that wasn't 100% of the time.

Essentially, PHPStorm is what I always wanted Netbeans/Eclipse to be.

As I say, though, it's been a long time since I last looked, and that's for a very good reason: at long last, I'm completely satisfied with my IDE.

Thanks, checking out their free trial now

PHPStorm is like the perfect gateway drug. I first became familiar with JetBrains products through PHPStorm, but have since upgraded to IntelliJ IDEA. IntelliJ IDEA is the perfect polyglot IDE, with support for the following either in-built or via plugin (and forgive me if I leave anything out, or add it in a reply):

- Java

- Scala

- Clojure

- Android

- PHP

- html/css/javascript

- Python/Django

- Ruby/Rails

- Groovy/Grails

- Actionscript/Flex

I'm a raving fan!

If you're working with PHP professionally, you probably have enough privilege in the world to be able to spare the few afternoons it'll take you to learn a real programming language and stop having to suffer such amateur-hour bullshit day-in, day-out.

Seriously, spend a weekend learning Python or Ruby. Your life will improve vastly.

Using a shiny and expensive IDE to make hacking PHP suck less is like buying a huge box of band-aids as the solution to the problem of your carving knife continually cutting you open.

Ugh, really? For what it's worth, I've been doing web development professionally for the last fifteen years, and actually really enjoy coding with PHP.

If you're suffering from amateur-hour bullshit day-in, day-out, I'd kindly suggest that you're doing whatever you do wrong.

Seriously, spend a weekend learning Python or Ruby. Your life will improve vastly.

Python never really did that much for me, but I probably should investigate Ruby one of these days. Right now though, I'm enjoying playing with Erlang, and want to take a look at Go at some point.

Horses for courses, I'd say.

Using a shiny and expensive IDE to make hacking PHP suck less is like buying a huge box of band-aids as the solution to the problem of your carving knife continually cutting you open.

Surely using an IDE, for whatever language, will generally make your life better?

Whilst syntax-highlighted Vim or even Notepad++ have their merits, you can't beat a lot of the features modern IDEs provide, PHP, Python, Ruby, Erlang or otherwise.

> For what it's worth, I've been doing web development professionally for the last fifteen years, and actually really enjoy coding with PHP.

Me too— except that last part. My first web app was PHP in 1998.

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Just because you enjoy it doesn't mean that you should.

If you know Python already, Django will change your life. Go try it.

I'm a PHP developer who knows Python. I tried to learn Django awhile ago and to be honest I wasn't that impressed. Super leaky abstraction... nearly every single error message was something about string manipulation inside the Django code itself, with no reference at all to my own code. It made it totally impossible to learn by doing. Also, this was probably a result of my lack of experience with Django, but the way I was told to organize my Django project (with functionality kept in modules) felt very wrong in a web app (as opposed to a website) where all the pieces are interconnected. I ended up having only one custom module that would be totally unreusable for anything else, which made me question the point of putting it in a module at all.

You're right: PHP silently converts your vars to strings and then does the wrong thing without ever telling you.

I think you misunderstood. I'm not talking about Python throwing errors about the types of my variables. Like I said, I'm already quite comfortable with Python. I'm talking about Django failing to check whether my Django-specific code (e.g., templates) is valid, so that Python gives me an error message that appears to originate inside the Django codebase, instead of Django giving me an error message about the syntax of my template.

I've only briefly tried CakePHP, but IIRC its error handling was excellent.

> It makes me wonder if auto-refactoring spaghetti is a crackable problem

I'm not sure it should be. It would probably still be a mess, just hidden and split over multiple source files.

It's not PHP's fault, mind you. PHP pays the price for its own success here, meaning that lots of inexperienced hacks think they can code a web application, leaving behind these steaming piles of suck. It's also important to note that PHP is just a language, not a framework - as such it leaves unskilled "developers" a lot of rope to hang themselves with.

You could in theory code the same nightmare you're describing with, say, Ruby on Rails. But in practice that doesn't happen because Ruby has a different clientele and Rails gives people a somewhat reasonable structure they can cling to.

I do a lot of my development with PHP, it's a quite capable language. My biggest gripe with it is actually its syntax and uneven naming schemes for internal libraries. But the runtime itself is quite good and it is possible to do some very elegant things with it.

> I do a lot of my development with PHP, it's a quite capable language. My biggest gripe with it is actually its syntax and uneven naming schemes for internal libraries. But the runtime itself is quite good and it is possible to do some very elegant things with it.

Indeed. I always wondered at how different the class syntax is from the rest of the language. In comparison to the rest of the language it looks... sane.

Yeah, but then you're still working in PHP.

I cannot state clearly enough, PHP will not help you. Neither in your project or in your career. If you are doing PHP, do everything in your power to switch to something else. There is no use case for PHP that is not better served by something else.

Seems like a neat and very clever tool, but why would you use a test case as an example? Maintainability in unit tests is nowhere near as important as with actual implementation code (refactoring eventually may even hinder the documentary aspect of test code).

I respectfully disagree. If you don't treat test code with the same respect as production code, rot sets in. Rot in the test suite discourages programmers from trusting, augmenting and maintaining it, until it eventually stops being used altogether.

The most common type of rot in test code is caused by lazily copy/pasting vast blocks of setup code. The reason this is bad is that when subtle architectural changes break that setup process, somebody has to waste hours fixing 50 tests. Refactoring such code into a setUp method is the usual way of avoiding this.

I disagree heavily.

Refactoring tests is as important as refactoring "production" code. Following the four elements of simple design (http://www.jbrains.ca/permalink/the-four-elements-of-simple-...) you can use test refactorings to find better names and detect need for abstractions.

Tests with lots of duplication, for example in the test setup, get hard to maintain and developers tend to abandon them more easily (my own experience).

Unfortunately, this is a very common mistake made by those that treat their tests a an after-thought. Tests should be cared for and maintained as much as (or perhaps even more than) the production code.

If tests are difficult to read or reason about, it is much more likely that they will become stale, brittle, or worse, be ignored. If one does not plan to keep tests well-maintained, might as well never add them in the first place.

Can it be integrated into an ide? I like it a lot better when I point at method or variable in IDE and can quickly rename it. BTW: there is already such thing for PHP: PHPStorm, although not open source.

I suppose it can be integrated into IDEs. We (the developers) are Vim users, so there is no immediate need for us to integrate it into anything except Vim.

We know that PHP Storm has many refactorings implemented very well, but a command line tool is much more flexible and useable for everyone, not just PHP Storm users.

Looks neat. :)

It would be pretty nice (if I may suggest that ;)), if you added add branch support so the patches are saved into a refactoring branch or maybe individual branches?

Reply on news.ycombinator.com