what is core purpose of IDE refractor option? - php

To change name of folder or file NET-BEANS and ECLIPSE IDE both offer an option i.e. REFRACTOR
What actually is the core purpose of this option? or other way around how can we get benefit from this option while development
PLEASE explain it with some hello word type example.

Refactoring is a major feature in agile software development. It came about as the third step in test-driven development:
Write a test
Write enough code to pass the test
Refactor
To refactor means the code is working, but it needs to be cleaned up to be more maintainable and extensible. This could be something simple like renaming a variable or extracting common code into a function or something complicated like extracting an interface or adding a design pattern.
I don't have numbers, but I think the majority of developers don't do TDD. Still, you should refactor often to clean up technical debt (another agile term) and make your code maintainable and extensible. It is such a huge help when you need to add a bunch of new features in a short amount of time.
So all these IDE's, regardless of language or platform, offer automated refactorings to make your life easier. For example, changing a method name in a Java class and then changing it everywhere it is referenced would be a huge pain to do manually.
Hope that helps.

According to here:
"Refactoring is the process of changing a software system in such a
way that it does not alter the external behavior of the code yet
improves its internal structure."
The most common usages for this is usually the renaming of variables to something which makes more sense, the fixing of indentations and addition of comments, such as JavaDoc/nDoc.
In certain scenario, one would also require to rewrite some logic, or entire modules of the code. This usually entails either a bad design or else, that the solution had been changed so much that a re-write will ease any future maintenance.

Related

Code PHP Correctly, advice for a newb to OO programming

I'm about to start coding a new website. My problem is that I'm still stuck in using old school coding methods.
I recently downloaded some open source code from Question2Answer.org and was really intrigued in how it was set out.
Does anyone know of any sources? or something that I could possibly download, a template or example to help me get started with a new site?
The site won't be anything fancy but I want to start moving into Web 2.0 and OO programming.
In short I want to do it right. Any advice would be appreciated.
It seems like this question isn't getting many answers, so I'll try my hand at it (even though I'd recommend a different language, just because PHP is such a terrible language ). PHP was the first language I ever wrote anything big in, and the one thing that I wish I had known at the time was the MVC design pattern. It has some advantages like:
Separation of logic and UI means less ad-hoc code, more functions (try to follow the "each function does one thing" rule -- It makes things much easier when you go back and look at code)
Functions are easier to verify correctness than huge function-less pages
Functions can be unit tested (do this!)
It's easier to figure out where things are (database logic is in one file, HTML in another, and "controller" logic in another)
Here's a pretty good high-level intro to MVC.
Key points:
The model talks to the database (or whatever other storage you're using).
The view displays things (HTML)
The controller does everything else
I found two good-looking PHP MVC tutorials here and here. Hopefully they're not too complicated, and feel free to ask more questions if anything doesn't make sense.
Good luck!
PS - Don't forget the point about unit tests! If you can't find a way to unit test a function, it's probably too complicated.
There is a reason why people chose PHP as a server-side scripting language. It's extremely easy to pick up and offers many different coding options. Many functions are included without having to know prior importing, and you do NOT have to write OO code if you don't want to.
This all leads to a huge downfall as well, because there are less restrictions on the structure of the code, it's much easier to write bad code.
I suggest using a framework. It saves you time, energy, and the opportunity to write bad code:
CakePHP is a rapid development framework for PHP that provides an extensible architecture for developing, maintaining, and deploying applications. Using commonly known design patterns like MVC and ORM within the convention over configuration paradigm, CakePHP reduces development costs and helps developers write less code.
http://cakephp.org/
http://www.phpframeworks.com/
IMO MVC ( and this OOP ) is nothing really fancy. It's basically a function to register a pointer to a function in an array for example like a hook. This array is looked by another function to do some stuff. A good MVC should have a callback function. IMO this OOP thing is more a bussines logic to help you to monetize your application. It's not really something difficult to understand.

Writing refactoring-friendly PHP code

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.
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.
Avoid magic as much as possible: variable variables, eval, masking errors with # and storing code in the database will come back to bite you.
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.
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?
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.

How to fix an old coding style php script

Is there any advice on how to start fixing an old-fashioned-style php script?
A few days ago I received an offer for developing an old PHP project, and by old-fashioned I mean the structure did not use OOP coding method and it doesn't have a definite framework.
I am confused on where to start, and wanted to know what methods there are for developing an old script.
Note: They don't want to spend lots of money on starting a new project.
So what methods would you suggest for updating an old php script?
Joel Spolsky writes:
"[Netscape made] the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch."
So, whatever your course of action, priority is to work with the existing code. Refactoring will be one of the best methods you can use.
What can you not do, if the code base is not updated, that you absolutely must? How much and of what particularly do you need to upgrade for that action to be possible? Consider these two questions.
It depends what you mean by "old". Old as in written for PHP 4? Or old as in non-OOP? (Or both?)
Old as in PHP4:
As long as you sift through it and either suppress warnings or actually fix deprecated function calls everything should be fine. This is just simply boring work. Easy and cheap.
Old as in non-OOP:
One could theoretically develop a very stable and scalable app without OOP or a definite MVC (or other) framework. As a matter of fact, if the app is small in scale, there's no reason to add the spaghetti and meatball complexity of OOP or a framework. Re-writing everything in OOP with some framework is hard and expensive. And quite probably overkill.
Can you give us more detail, perhaps an example.
Even procedural code has elements of OOP in it. You can identify variables and procedures that relate to the same entity. You could go about rewriting it, but they're going to have a hard time finding value in it, especially if they are frugal, as you suggested.
When I do this, it's a multi step process. Typically, there's an existing product to keep running. Rewriting from scratch is rarely an option, even though you end doing it eventually.
Begin to ditch manual include statements and implement an autoloader, where possible (takes many passes)
Create a helper script to simulate magic quotes & register globals. This is so you can turn it off in PHP, while keeping the existing code running
Gradually remove excessive strip_slashes or add_slashes calls, if applicable. The helper script allows you to do this per file.
Ensure that your variables have proper scoping
Separate out your presentation code. Consider Smarty or alternate template system
Move the DB calls to PDO and use parameter substitution for everything
Look at the code and think about stubbing out a front controller
I then look at the project and determine how I'm going to alter the logic itself. Often, if there are no functions at all, my first pass is to wrap common behaviors into static methods. Get as much reuse without too much effort, so I'm not concerned with organization yet.
After the redundancy is reduced, then I get to organization. It's at this phase that I start planning out my class models and refactoring the functions into clean methods. This is also the time for automated tests (phpunit). Once I'm reasonably confident, I add some controllers and integrate the templates, then I'm done... barring one or two more passes.
For me, it's all about identifying where I am, where I want to be, and making a plan that can be executed in several small steps. Everybody has their own objectives, so there's no magic plan to follow except your own.
Perhaps Your code right now looks like this
And you want that it looks like this
Well if its just a script and not the whole Project i would convert it to OOP coding standard.
Read their code. Talk to them.
Look at the requested change in terms of the existing code. Talk to them.
Decide how little of it you change to do what what want. Talk to them.
Do that. Talk to them.
When they ask for functionality that can be more easily done by re-writing than by modifying, do that.
Work with an IDE that can assist with refactoring.

Why use a web framework (like rails) over php?

This isn't a question about what framework to use. I've learned both Rails and Django, and I write all of my webapps in PHP. My question is why bother with the frameworks? It's always taken me longer to use a framework than to reuse old MySQL code and build "models" with phpMyAdmin. I also like writing everything myself, because I know what's going on. I can still reuse functions, etc. and do things how I want, and this freedom seems to be missing from most frameworks.
I'm not saying that my way is right; in fact, I'm trying to figure out where my logic fails. The hype can't be just thin air. What am I missing?
The basic idea of a framework is to allow you to work at a higher level of abstruction and write only the code you have to write to implement your specific requirements. All the other repetitive stuff is handled for you by the framework, and probably with far fewer bugs and security holes than if you did it yourself.
It may feel like it takes longer to learn a framework than to just do it yourself using basic language features and standard APIs, but it's simply not true - not if the framework is good and the app is non-trivial, and especially not once you have learned the framework (using a different one for each new project would of course be idiotic) and factor in the time it would take to find and eliminate all the bugs and correct all the design mistakes that have long since been found, eliminated and corrected in the framework by its developer community.
Almost every developer has cowboy coder instincts that tell him "Doing things yourself is much more fun than using code others have written, and I'm sure I'm good enough to get it right the first time, so it will even be faster and better!". These instincts are almost always wrong.
Frameworks allow you to concentrate on the application itself rather than worrying about the boilerplate code that you'd otherwise have to write for every application. They allow you to structure you site in a much more logical (mostly object-oriented) way, using tried and tested design patters such as model-view-controller. The code in framework is generally more mature and of a higher standard than code you would write yourself for one-off projects as framework have a large community of developers perfecting the code perfecting the code over year. This means that framework-driven sites often perform better and are much more secure.
You also mentioned you like writing things yourself - I know where you're coming from. My solution to this was to write my own framework - I get to reuse and improve my code with every project I do and I know the entire codebase inside out.
Writing it your self may make it easier for you to understand things your self but unfortunately it can make it much harder for other developers to understand what is happening. Frameworks will often be better documented and have a larger community that can support a new developer that is working on the app that you wrote.
I think a big part of it is what you focus on. Frameworks standardize the parts that you shouldn't have to keep revisiting, which helps you focus on the application as a whole. If you reuse your own code all the time you're already using your own makeshift framework.
Your comparing a framework (Rails) to a language (PHP). A framework is going to give you pre-built components so you can spend time on what makes your project unique.
You may already have a code base that helps do this for you. Check out some of the PHP frameworks since that's where you are more comfortable. Take a look at CakePHP, CodeIgnitor and/or Zend Framework.
If you are building many small apps/sites, using a framework may make your life easier.
I think a good step for you is to create your own framework with the code you've programmed so far. ;)
Try to make your code parametrizeable, in other words: create components which you can reuse in different parts of a website (for instance: styled containers), or in different websites (form generators/validators).
You can even go further and create base-classes from which you extend new classes to build your websites. (for instance: data objects with generic select/insert/update/delete methods).
I bet this gives you the best view on why frameworks are so damn handy ;)
It'll take you longer to initially use a framework for the same reasons a PHP developer would take longer to initially use Ruby - you're not familiar with it.
Once you're familiar with them, frameworks can offer the ability to skip the mundane and focus on actually writing the important parts of the app.
You should also just use a PHP based framework like Symfony or CakePHP using them should reduce your production time considerably.
One reason to use a frame work is code separation. Take symfony for example. The model is all done with propel or doctrine libraries. Very little SQL needed. You instantiate a new object and user getters and setters, to store your data, and instead of writing SQL in your page code you create functions in the objects related to the query. When you need to access the same kind of data on different pages you are asking the model for it, keeping the business logic with the model where it should be, so there's never any difference. All the work is done in the "action controller function". You get all the data you need, and then put as little php in the display, basically just echoing the variables you got in the action controller, (with the exception of some for loops and if statements for conditionals. I have found this a more efficient way to code, and on my 2nd project saw the production time cut in half.
You don't need to learn a new language python/ruby just to use a great framework, just have to fin one that works for you.
First, PHP has frameworks too, so the question as stated misses the point.
Yes, you can write your own framework, and as Kris said, there's no shame in that. However, part of the leverage of code reuse is the collective value of the efforts of many. It's not just about reusing your own code. Frameworks encapsulate the common tasks and patterns we all share and provide well tested solutions with many iterations of improvements from the community. No individual effort is going to measure up to that, no matter who you are.
If you roll your own, it will only become world class due to the collective effort of world class people, and that will only happen if your idea merits the attention. The top frameworks out there are already proven on those criteria.
DHH is a smart guy, but the Rails we have today never could have been realized by him alone. Not even close.
If you like "writing everything yourself" as you say, then choose a framework with a core philosophy that matches yours, and start making core contributions in the areas where you can see room for improvement.
Depending on the functions of your Web Application, it can be faster to develop without a framework. For example when the Webapp is just some kind of data viewer.
But as soon as you begin to implement more advanced functions, you are much more efficient with a framework.
Try do do this from scratch:
- proper Form validation
- Handling of multiple Language and Date/Time formatting
- Authentication
See a framework as free tools and stable implemented function for you to use.
Sounds to me like you have already written your own framework in php, since you do mention code reuse.
I can imagine it being easier to use your own set of wheels instead of adapting to someone else's. No shame in that.
Frameworks are there mainly to help people who are semi-new to PHP (or the specific language it is built on) to be able to build a website to an extent that it is secure and easy enough to add on extra parts to the site without having to know a lot about the specifics like security, MySQL (or other database types). In my opinion it is a fairly good way to help break coders into a language, allowing for the fact that the framework isn't too complex of course.
EDIT The reason behind me saying they are for beginners is because myself, as a beginner has used frameworks to break myself into languages a lot better.

Tools for cleaning garbage PHP

I just inherited a 70k line PHP codebase that I now need to add enhancements onto. I've seen worse, at least this codebase uses an MVC architecture and is object oriented. However, there is no templating system and many classes are deprecated - only being called once. I think my method might be the following:
Find all the files on the live server that have not been touched in 48 hours and make them candidates for deletion (luckily there is a live server).
Implement a template system (Smarty) and try to find duplicate code in the templates.
Alot of the methods have copied and pasted code ... I don't know how much I want to mess with it.
My questions are: Are there steps that I should take or you would take? What is your method for dealing with this? Are there tools to help find duplicate PHP code?
Find all the files on the live server that have not been touched in 48 hours and make them candidates for deletion (luckily there is a live server)
By "touched" I'm assuming you'll stat the file to see if it's been accessed by any part of the system. I'd go a month and a half on this rather than 48 hours. In older PHP code bases you'll often find there's a bunch of code lying around that gets called via a local cron job once a week or once a month, or a third party is calling it remotely as a pseudo-service on a regular basis. By waiting 6 weeks be more likely to catch any and all files that are being called.
Implement a template system (Smarty) and try to find duplicate code in the templates.
Why? Serious question, is there a reason to implement a template system? (non-PHP savvy designers, developers who get you into trouble by including too much logic in the Views, or you're the one creating templates, and you know you work much faster in smarty than in PHP). If not, avoid it and just use PHP.
Also, how realistic is it to implement a pure smarty template system? I'd give favorable odds that old PHP systems like this are going to have a ton of "business logic" mixed in with their views that can't be implemented in pure smarty, and if you allowed mixed PHP/Smarty your developers will use PHP everytime.
Alot of the methods have copied and pasted code ... I don't know how much I want to mess with it.
I don't know of any code analysis tools that will do this out of the box, but it sould be possible to whip something up with the tokenizer functions.
What You Should Really Do
I don't want to dissuade you or demoralize you, but why do you want to cleanup this code? Right now it's doing what's is supposed to do. Stupidly, but it's doing it. Every re-factoring project is going to put current, undocumented, possibly business critical functionality at risk and at the end of that work you have an application that's doing the exact same thing. It's 70k lines of what sounds like shoddy code that only you care about fixing, no mater what other people are telling you their priorities are. If their priority was clean code, their code would already be clean. One person can't change a culture. Unless there's a straight forward business case for that code to be cleaned (open sourcing the project as a business strategy?), that legacy code isn't going anywhere.
Here's a different set of priorties to consider with legacy PHP applications
Is there a singleton database object or pair of objects that allows developers to easily setup seperate connections for read (slave) and write (master). Lot of legacy PHP applications will instantiate multiple connections to the same database in a single page call, which is a performance nightmare.
Is there a straight forward way for developers to avoid SQL injection? Give this to them for new code (parameterized SQL), and consider fixing legacy SQL to use this new method, but also consider security steps you can take on the network level.
Get a test framework of some kind wrapped around all the legacy code and treat it as a black-box. Use those tests to create a centralized API developers can use in place of the myriad function calls and copy/paste code they've been using.
Develop a centralized system for configuration values, most legacy PHP code is some awful combination of defines and class constants, which means any config changes mean a code push, which means potential DOOM.
Develop a lint that's hooked into the source control system to enforce code sanity for all new code, not just for style, but to make sure that business logic stays out of the view, that the SQL is being contructed in a safe way, that those old copy/paste libraries aren't being used, etc.
Develop a sane, trackable build and/or push system and stop people from hackin on code live in production
I don't know of any specific tools, but I have worked on re-factoring some fairly large PHP projects.
I would recommend a templating system, either Smarty or a strict PHP system that is clearly explained to anybody working on the project.
Take discrete, manageable sections and re-factor on a regular basis (e.g., this week, I'm going to re-write this). Don't bite off more than you can chew and don't plan to do a full rewrite.
Also, I do regular code searches (I use Eclipse and search through the files in my project) on suspect functions and files. Some people are too scared to make big changes, but I would rather err on the bold side rather than accept messy and poorly organized code. Just be prepared to test, test, test!
You need to identify a solid reason for refactoring. Removing duplicate code is not really a very good one; it needs to be coupled with a real desired improvement, such as reducing memory footprint (useful if the webservers are struggling).
Once you have that in mind, now you can start refactoring. And make sure you have a version-control repository, too. Just don't check in broken code.
Don't be too hasty about single-use classes. A lot of small PHP frameworks work like that. Often they could be abstracted better, though. Also, A lot of PHP code also doesn't understand data layer abstraction with the result that there is SQL code littered through the business logic or even the display code. This problem is often coupled with no custom database handler, which is a problem if you suddenly have to teach it about replication, or caching. This is the same abstraction problem from the other direction.
One very practical step: once you start abstracting repeated code away, you'll find reasons to have multiple files open. If you're using a shell and a Unix editor, then screen will help you immensely.

Categories