Dead code detection in PHP [closed] - php

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a project with very messy code - lots of duplication and dead code here and there.
Some time ago there was zero code coverage by unit-tests but now we're trying to write all new code in T.D.D. manner and lowering technical debt by covering "old" code by unit-tests as well(test-last technique).
Business logic's complexity is quite high and sometimes no one can answer whether some methods are used or not.
How this dead code methods can be found? Extensive logging? Higher test coverage?(It is not very easy because customers want new features to come out)

xdebug's code coverage tools allow you to test which lines of code are actually being executed, without needing to put trace statements in all of the functions/methods.
Example:
<?php
xdebug_start_code_coverage();
function a($a) {
echo $a * 2.5;
}
function b($count) {
for ($i = 0; $i < $count; $i++) {
a($i + 0.17);
}
}
b(6);
b(10);
var_dump(xdebug_get_code_coverage()); // array '/path/file.php' => array line_number => int 1 or 0.
?>

It's a little late now, but PHPDCD claims to do this statically, which should give you a much more informative result than having to profile actual code execution with xprof / xdebug.

I don't know of a way to detect code that is completely unused, that may be beyond the abilities of all the tools out there. But in terms of the tools out there, hit https://phpqa.io/ for a good rundown of them.
So far, one of my favorites in phploc which tears apart your code from an Object Oriented perspective and gives you details on how many classes vs how many functions vs how many tests vs average loc per function vs Cyclomatic Complexity.
My next favorite is phpcpd which is the "PHP Copy-Paste Detector". It tokenizes your entire codebase, looks for common signatures, and gives you a list of files with line numbers.
There are lots of other tools on that page, choose the ones that are useful to you.
We're actively using these tools in web2project and in the two years since we forked from dotProject, we've dropped about 35% of the codebase from refactoring, eliminating duplication (originally 12%, now about 2.5%), and generally structuring things better. And that's counting our 15k+ lines of Unit Tests. :)

I would recommend running through the system with xdebug profiler (http://xdebug.org/docs/profiler).
Run through the system the view the logs with http://code.google.com/p/webgrind/ and physically see what's being called.

Regarding profiling tools, if you decide to go that way you may take a look at xhprof http://developers.facebook.com/xhprof/
It has smaller size of the output files and web interface that you could embed into your app for continuous tracking. It is able to generate visual representation of call tree. I recommend it over xdebug for that purpose.

See the SD PHP Test Coverage Tool. You exercise your code any way you like, including (or not) running test suites any way you like. At the end of execution, you can see a display of what code was executed (there are screenshots at the website). Code that is not executed may be dead, and requires some more analysis on your part, but if you exercise the system well, unexecuted code is either error handlers or really dead stuff. The PHP Test Coverage tool does not require any changes to your PHP server.
The SD CloneDR tool finds duplicate code across very large source code bases. It is language sensitive (covering C, C++, Java, C#, Ada, Fortran as well as PHP4 and PHP5) so it isn't fooled by changes in formatting, whitespace or the presence or absence of comments. It will detect exact copy clones, and near miss clones. The website shows example clone reports for several languages.

I believe that someone has implemented a flavor of Structure101g that uses xdebug data - s101 will then detect any unused clusters, i.e. files that use each other but are disconnected from the main codebase.

Related

Writing a compiler in PHP [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
A few years ago I started working on a few ideas about a programming language and as I was so excited about them I just wanted to see how they would works, so I decide to write a very simple compiler for that. As I'm more comfortable and more experienced in PHP, I just took a look at to see if it's possible to write a compiler in PHP and very soon after that I found that yes, it's possible. So I start making that and fortunately everything was okay and now it's working fine.
Those days I just wanted a place to start working on my ideas, and as PHP was fast in development (no need to compile), I had MySQL on my hands also, and debugging was really easy, etc.
Now I want to extend this simple compiler, and that's where I need your advise. My main question is "Is PHP a right tool for a compiler project?". Just suppose that I'm not gonna release it publicly, so just think about the PHP abilities to handle the task, not further problems like distribution.
I believe that it has some advantages. It's fast in development, I just edit the code and press the F5 on browser and I had my binary output right after that. I also made a text box there where I could write my simple codes, press the submit and then I had my binary output again. It was also fast to keeping and working on the parsed data in MySQL. But now I'm more worried about the script timeout for example. If it's gonna compile 10,000 lines of source code, it would timeout I guess. I know I can increase the timeout, but still worried about that. Also I know that PHP as a scripting language is (as I heard) 10 times slower rather a compiled-application.
So, do you think I have to switch-off to the C? (which I'm also okay with that also) ... or do you have any ideas if I could continue with my PHP back-end, but to handle more serious things and without facing critical mistakes?
Update:
Yes! the project is personal and for fun. You may consider that also!
Regarding application for a PHP-based compiler, yes, it's not a real-world compiler, but imagine if you want to share your ideas with others, it would be great if you gave them a web form to write their code, press the button and download the binary code. It's not my goal, however, I just wondering about that.
Regarding Lex/Yacc, my ideas was more about optimizing the final binary code, so I needed something more than just generating a binary code via Lex/Yacc.
PHP is not the ideal environment for writing compilers. Is it doable? Sure. Should you do it? I am vehemently opposed to writing a compiler in a high-level language like PHP. I'm also opposed to unnecessarily reinventing the wheel.
If it's for fun, I say go for it, but I don't see any practical uses for a PHP-driven compiler at this time.
It is possible to write a compiler in any language (even some non-Turing-complete languages can be used). But in order to make life easier you'll need certain language features which are missing from PHP, and since it is a pretty low-level language, it is not quite possible to add such features to the language.
A decent language for implementing compilers must contain:
Some form of algebraic data types, it is relevant even for a fully dynamic languages (like Lisp)
Pattern matching, the more powerful and expressive - the better. Writing AST transformations without pattern matching is a pain.
This is a bare minimum. Having some decent native support for graphs is an advantage. Having an embedded support for parsing is quite useful (but parsing is not that important in general). Having an access to Prolog or Datalog in runtime is extremely useful (but it should be easy to implement your own Prolog in PHP).
Webjawns say: but I don't see any practical uses for a PHP-driven compiler at this time.
So????
Smarty - is a compiller!!!
If your compiller is just for fun, or specific, php-related use - it is good idea took the php as environment.
But if your compiller has a performance requirements or memory restrictions - it is very bad idea to use PHP for it.
There's a computer programmers gag that sounds something like:
Rookie: Why is C considered to "run faster"/"use less memory"/"insert other optimization comparison here" than Java?
Mentor: Because the Java compiler is written in C while the C compiler is written in C (with traces of assembly for optimization).
Almost all compilers are written in C. The same thing goes for operating systems which are also almost all written in C. Almost all of the main prepacked libraries that any high level language uses are written in C. Almost all high-load servers (Apache & MySQL included) are written in C. Basically almost every mission critical piece of software is written in C.
With that in mind id's say:
I'd write a Tokenizer -> Parser -> Transcoder chain in PHP for fun - maybe even one with database storage what the heck; but i would be outputting text (source code for another language).
I wouldn't write a Compiler in PHP because i wouldn't want to be outputting binary files from PHP - not because it can't but because I don't like using strings for binary arithmetics.
The Compiler I'd write in C.

Why are dynamic frameworks like this not scalable? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've always had a thing for dynamic code. Code that's really easy to add cool new features to, without doing much work. For that reason, I build lots of dynamic frameworks and use them in my projects. Some are small, some are big.
As an example, I built a small custom error reporting framework that I still use in almost all of my projects today.
Here's a quick example of how it works:
error_reportLibrary.php - This is where all the magic happens. The class and all the methods sits here. This is the file included when the framework is needed.
error_reportConfig.php - This is where my configuration goes (error types, ect). Here's an example of this file, which shall give you a pretty good explanation of how the small framework works:
(the comments in the code should explain what each element does as a setting)
# ------ Main Settings ---------
$error_handlingSettings['errorStat']=true;//set this to false, and I wont display any errors. I don't care what the other errorTypes have to say.
$error_handlingSettings['default_highlight_color']="red";//this is the default highlight color that will be used if no color is defined for a specific errorType
# ------ Open API -------
$error_handlingSettings['open_api']['status']=true;//set this to true and I'll show errors for the Open API
$error_handlingSettings['open_api']['highlight_color']="#0ff";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['open_api']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['open_api']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['open_api']['remote_addr'][]="127.0.0.1";//and this IP
# ------ SQL Core -------
$error_handlingSettings['sql_core']['status']=true;//set this to true and I'll show errors for the SQL Core
$error_handlingSettings['sql_core']['highlight_color']="orange";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['sql_core']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['sql_core']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['sql_core']['remote_addr'][]="127.0.0.1";//and this IP
So as you can probably tell, each error type is simply a different part of the project I'm using the framework on (for example, SQL Core is the database framework I use. So if any db query issues occur, this errorType will be looked at when printing errors).
So for printing errors, this is the syntax:
errorModule::doError("errorType","error messege");
As you can see, there are some extra little things I can do. Like display to certain IP addresses and highlight the error text, which I can confidently say: will not affect the scalability of the framework.
Remember, the above is just an example of the dynamic frameworks I create/use in my projects.
Now, to the question(almost): I've been told by a few of my colleges that dynamic frameworks like the above are terrible when it comes to scalability. Regardless of the fact that they are very maintainable. So if I used the above framework on a web app that got 1M+ requests a day, it would totally screw up...
Now I'm not apposing against their opinion (actually....) but I would like to know why this is? Why is a dynamic framework like the above considered bad for scalability?
I think you're missing the point when creating a 'dynamic framework.'
A lot of my earlier PHP code functioned sort of like this; a class with a bunch of methods and maybe a construct method that set up a state, using globals to track configuration in arrays. These all used a lot of memory compared to a wholly OOP approach; and while yes less memory and faster than an 'off the shelf' solution; nothing compared to the way I design frameworks now.
It doesn't appear you are taking advantage of things like interfaces, abstract classes, both class and interface inheritance and so forth. These types of frameworks do scale because the original code base is so small and take advantage of specific OOP functionality (like PHP 5.x's magic methods.)
Multiply a script that you felt was fast enough running on server that's not taxed very much by say 100 and, you've got problems; and you're running out of memory, hitting pages outs; and things will crawl to the point you're forced to reboot/throw more resources at the server.
Why? Poorly written procedural code that tries to act OOP, even tries to look like it, is just wrapping up old habits in a new package.
PHP is slow and clunky in general. It's high-level, which means each line carries "baggage". It's common that a single line of PHP code will convert to a slew of low-level instructions.
You can still scale 'dynamic' frameworks that rely heavily upon PHP's underlying system, and don't waste a lot of time or memory with high-level abstractions.
In my opinion, large, "convenient" frameworks often cause more problems than they solve once shit hits the fan in a production environment. My favorite teachers always reminded me to K.I.S.S. -- Keep It Simple Stupid.
Of course, If you want truly scalable performance you may want to compile your php with hiphop or write your application in a compiled language like C++ or D.

JavaEE vs PHP - why so many people thinks Java is better? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I need to valorate what technology use for a web project, the team is composed by 4 developers and the time of the project is 1 year.
I'm more familiarized with php but the client is asking me to do it with JAVA EE.
I always have the same perception with Java and its frameworks:
So much xml and class in order to do simple things. In codeigniter I've to use 3 files (model, view and controller) with hibernate + spring + JSF I need more than 10 files!!!
An abusive use of the server. The javascript code lose importance and it's not good nowadays. Of course we can add javascript code but It seems "java web guys" prefer do the stuff on the server instead of the client.
Not good-looking application. Richfaces seems like a web of several years ago.
When I see a java application like liferay, alfresco, they looks heavy and very slowly.
I think I can be a little confused because lots of people and big companies continues using JAVA for the web. Why? it's about integration?
On the other hand Java is faster than PHP, but JAVA's servers need lots of memory (more expensive). In a server with many request we can improve with a language like php with bigger time per process and less memory per process because the server never is collapsed because of memory. Sometimes a JAVA server could collapsed because of memory and the average of response time in a real production environment would be bigger than php.
I'm really pleased with Codeigniter, why so many people thinks Java is better?
Thanks in advance,
Alberto
well I'm not using CodeIgniter so my comparison is already incomplete.
Question one would be: why do they ask for Java? Often big companies only offer Java or .Net environments for productive systems so they might not have the people to productively run PHP applications. I know its not complicated but the maintenance people define what they are running.
Ofter people talk on languages and their features but when the first business use case has to be discussed no framework will save you that amount of time to make it count. Most programming language will somehow solve the issue.
Java is not only RichFaces or JSF. There is a lot to choose from. A LOT. Not an advantage.
Stuff often forgotten is the tool support. Java comes along with a JVM that can be analyzed in detail what it does with its memory, garbage collector, threads and so on. Profilers in Java allow you to identify almost any memory leak within a few hours.
Most of the JVM monitoring works in realtime (with about 5% overhead).
Talking about tool: refactoring support is far beyond what PHP IDEs come along with.
You are correct if the first look at Java compared to PHP looks like elephants and horses. (ok the logo of php is an elephant, perfect comparison...). Horses are more flexible to turn around corners but they might not carry that much around.
I think from a language perspective Java is still more advanced than PHP. Namespaces, Classes, Type-Safety. These are somewhat available in PHP but still quite new.
Frameworks like Spring allow you to leverage your application on an architectural level and are more than just libraries.
I'm not the biggest Java EE fan, so I'll not complain on that.
A simple approach for you could be Tomcat+Spring+SpringMVC and a template engine for the GUIs. There is also GWT (Vaadin) if you target higher speed client behaviour (still a lot more out there).
There are lightweight approaches in Java too. I agree the standards in Java do have a more fatty tendency.
In my experience Java has no major drawbacks compared to PHP. The language choice will only affect success of the project if people come with less knowledge than required and spend too much time in learning things. And trying to find the right book about Java could be a project by its own :)
(counting as an advantage)
But I have no doubts PHP would allow you to finish the project.
I would rather look into the goals and requirements before choosing the technology. This often implies or simplifies a decision.
I hope I did answer at least one question here :)

What are the architectural limitations of PHP? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I was reading the article "PHP Sucks, But It Doesn't Matter" by Jeff Atwood.
In the comments he writes:
That said, I absolutely think it's important for PHP devs to be aware of the architectural limitations of PHP, and understand the alternatives.
What are those limitations and how do they compare with other scripting / weakly typed languages?
Also, what are the alternatives in those conditions where limitations need to be avoided?
There are basically two real limitations I see:
PHP is a fully synchronous language. This has impact on which things you can easily implement in PHP and which not. For example implementing a Long Polling driven chat application isn't trivial, because PHP would need block one process per chatter. I'm not saying it's impossible, you can hack around this limitation using some PHP Daemon library. I'm just saying that this is one of the cases where other languages, like JavaScript, are more appropriate (NodeJS).
PHP is slow. Please don't understand this an an offense. It's a fact that PHP - as implemented by Zend - is slow compared to other scripting languages. This typically is no problem when building websites, but you obviously can't do certain things: Implementing a ray tracer in PHP is definitely a bad idea - whereas in JavaScript you could do this.
But apart from that, I think that PHP is pretty multi-purpose. You can use it for nearly anything - and I do ;)
Take a look at the date. The article was written in 2008.
It means, that if you'll see the PHP5.3 advantages, you'll find there many things, like closures and namespaces, which were in other languages before. Some of them is already affected the architecture of famous frameworks, like Symfony.
And that list will never be complete.
Meanwhile, I meet a lot of people who think that "weak typing" language is an architectural problem itself.
Then, some people think that inline regex syntax is good thing in, for example, JavaScript, but others think, that "different language" must be written down in string constants there, as in PHP. Etc.
I'll take a stab at this without getting too into the nitty gritty:
The initial design of PHP as a collection of functions still shows through.
Object-oriented patterns that have been implemented in the latest PHP 5 releases are still half-baked and lack multiple inheritance (or "mixins"), proper module support, and are designed to be backwards compatible with the CoF (collection of functions) design.
Method overriding and callbacks are not supportive natively.
Closures. They are there, but they are very weak.
Errors vs Exceptions — methods are inconsistent in which they use (thanks again to CoF design), and error-handling is half-baked.
I'm sure I'm stepping on someone's toes here and I'll get any angry mob, but I'm also sure that I still didn't hit everything. It's largely subjective, but it's easy to see what is to dislike when you stack PHP up next to Ruby or Python.
I don't find it odd anymore that all of "PHP SUCKS" articles are coming from developers accustomed to established Microsoft technologies.
What I do find odd are statements that indicate that PHP is a spaghetti code. It's completely up to the author of the code whether the code will be spaghetti or if it'll use certain design rules when approaching the problem.
The reason a lot of PHP code out there is spaghetti code is because examples and tutorials are such that they don't teach beginners the good coding practices. Also, people are quick to grasp examples like hello world or connecting to MySQL, doing a query and looping over the result - but that's it, that's where ALL tutorials stop. I still haven't found a tutorial that covers the following:
what is a framework and what it helps with
what are data structures and data types (explained in a way a normal human can understand)
what is an array, what are array dimensions, how do arrays work, what are arrays useful for
what is object oriented code, why object oriented code, how does PHP do it, what is considered good, why are there patterns out there and so on
As you can see, a beginner programmer won't be bothered to learn all of those points outlined above, I know that because I was a beginner too and did all the mistakes beginners do. However, even if someone doesn't know how to program, they can still create useful applications.
Many popular scripts were written by people who knew WHAT they want to achieve, however they did not know HOW to properly design the environment (framework) in which they'll deploy their php code.
That's why we see scripts that become incredibly popular due to the ease of their use as a regular user which are hard to extend looking at it as a developer, using weird function names, odd coding conventions and no commenting.
Also, what's ridiculous is saying PHP is slow which is absolute nonsense. When I come across such statement, I want to shoot myself in the head for reading such a blog entry.
One has to know several things before making such a statement:
PHP is a scripting language, that means the interpreter is invoked every time someone requests a PHP page which takes A LOT of CPU power. That has been addressed by using bytecode caching mechanisms such as APC which stores the copy of pre-interpreted piece of the script in memory. The results are impressive, and I kid you not - execution for some of my scripts goes from 20 milliseconds to 1 microsecond, where some benefit "only" 5 times. That's on a system that serves 1 thousand concurrent users. Now, if someone wants to tell me that 1 microsecond is slow (or 5 milliseconds) - I'll take that as bullshit.
PHP is not the only thing involved in serving a web page. There's also underlying server (Apache) which has its own issues, there's MySQL which runs queries - and who says all queries are optimal? There's the network, there's the hard disk, there's the CPU, there are tons of other processes. Configure Apache with PHP-FPM, optimize MySQL to perform good on 8 core machine with 16 gigs of ram, use APC, use Memcache - and voila, you're getting an incredibly fast, scalable system capable of serving an incredible amount of traffic.
Languages that PHP is being compared to are often "compiled" into the bytecode and then executed by
You can extend PHP yourself. Assuming a PHP function is slow, NOTHING prevents anyone from creating a .so in C that is able to do the job faster and then hooking everything up trough extension in PHP. Not that I know what would such job be that would require that, but such a thing IS possible.
Sadly, and I say sadly because I respect certain programmers and admire their work (and I'm by no means a PHP fanboy) but it hurts me when I see uneducated, inexperienced and subjective comments about a tool which spreads misinformation.
As for why big websites use PHP - because it's fast. Because they laid proper foundations before starting the projects. Because it's free, extensible and scalable. Because it follows C syntax. Because you can extend it when you need it to be faster. Because it runs on a free operating system. Because it's easy to use.
PHP is improving everyday. It is open source and used all around the world. That said, when you have a problem, it is most probable that you will find your solution or get help faster than any other language.
The very reason of this article, I believe it is simple. If you (or in that matter any other programmer) used to code in C++, Java etc.. they had a lot of possibilities such as OOP coding and PHP was limited in the beginning.
It is a good thing that PHP has many built-in functions / methods / classes so you don't have to spend hours to code some function / class / method which PHP already has.
You don't have to (and you shouldn't) try to memorize all these functions. It is useless to memorize all of them (which one is doing what, how to use it etc). Imagine you are working on some project which took you 4-5 months to finish (yeah big one (: ) You are not going to use all these functions in all the projects and eventually you will forget what they were doing since you don't use them often.
The point is, you should know the syntax of PHP. When you need to do something, check first if PHP already has what you want to do in its library. Check the manual to see how to use it. This way, you will also LEARN (NOT MEMORIEZE) the ones you use often and this information will be hard to forget.
PHP or any other programming language is just like a normal language which we humans use daily to communicate with each other. If you don't use it, you will forget.
PHP 5.3 and above brought many features. Static feature is one of the biggest feature for me. It made my life so much easier that I can't even begin to describe.
Since PHP is that famous and open source web scripting language, Facebook developer team created HipHop.
What HipHop does is, takes the data from PHP and sends it to C++. C++ does all the process and sends back results to PHP for outputting.
The whole idea of HipHop was to make Facebook use less servers & improve the page display times.
Now you tell me if this seems limited and / or slow to you?
i dont think there is anything like 'architectural limitation' for php. developer knowledge limitation might be the reason. read this http://www.quora.com/What-is-Facebooks-architecture . most of the time, non-world-class developer does not know how they could use php to its full capabilities.
I would assume he is referring to the fact the the OOP portions of PHP are not the greatest compared to languages that are purely object oriented.
Architecture Limitations in Addition to nikic's answer
Writing extensions for PHP is a PITA. Not as bad as with Perl or Java, but not as easy as it could be. The ease of extensibility champion is still TCL which hails from the early 90's. Nearly any C function taking char* can be made into a TCL extension.
Embedding PHP in other systems. mod_php, gtk.php.net shows it can be done, but Guile and TCL are much easier to embed.

Why is PHP considered to be the easiest web programming language to learn? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
It is widely believed that PHP is the easiest programming language to learn for a beginner. The argument goes that PHP is the easiest language to use for getting a quick prototype up-and-running.
Why might this be? What, specifically, makes PHP easier to use than other languages?
Would this remain true, even when learning to use the object-oriented aspects of PHP? Or is it actually the object-oriented aspects of PHP that make it easy to learn? How does it compare with other web programming languages?
PHP is native to the web. While Ruby and Python have much cleaner syntax, more elegance, and more power, there will always be a layer of abstraction between Ruby/Python and the web itself -- after all, they were designed for much wider domains than the web.
Newbies to programming are typically newbies to sysadmin, and getting to Hello World in a Rails or Django is pretty painful -- for some even prohibitively so -- compared to PHP.
For newbies, it's easy to conceptualize that typing in:
http://mysite.com/something.php
...will execute the code stored in the file:
/path/to/mysite's/webroot/something.php
This simple one-to-one routing also mirrors that of HTML and other static files.
Beware, however, because this one-to-one routing also leads to security problems (i.e. people tend to keep all of their executable code within the webroot -- even secure code, which may contain passwords, hash salts, and other Privacy-Important code). Combine this with a lack of sysadmin experience, and many sites on the web are a chmod away from being totally exposed.
Responsible PHP like Symfony helps people avoid this, but Symfony requires the same level of sysadmin chops as Rails and Django.
Object oriented programming is optional
PHP is forgiving
The script continues running on minor faults.
When E_NOTICE (or even E_WARNINGs) are suppressed, the errors aren't even noticeable.
But also in the small things like substr: In C# you'll get a big fat exception when you'll try substr($text, 3) on a $text with 1 character.
Great online manual
http://php.net/manual/
Quick and Dirty is the default
The language is filled with useful shortcuts.
PHP lets me express what I want without typing an essay.
Conceptual simplicity.
A php site can consist of one file representing one page, with the dynamic content embedded within the static markup as needed. You can scan down a simple php file and see everything defined and run sequentially.
With a simple php site, there is no learning curve where one has to figure out in what file a specific piece of logic belongs, or in what external file a function has been defined.
...
Of course there is a reason that frameworks like rails provide lots of files and a fixed structure, and I would definitely recommend using one for any sizeable (and probably almost every small) site.
I do think though that it's this very low barrier to entry that is responsible for a lot of php's popularity.
I don't think that there's any reason a better php style system couldn't be written in ruby or similar - think just directories and .erb and .haml files and nice 4.days.ago syntax. But most people who could do this see the value in the extra tools that a framework provides. Sinatra is a minimal framework, in which it's possible to define an entire site in one file, but even it has routing powered by code instead of just directory and file naming.
PHP have many web tutorials and books about it, it's free and popular which makes PHP communities bigger. And also it's intuitive.
While PHP is far from the best web programming language, it's the most common (in terms of availability in hosting packages), the most popular (even in things like tags here on SO), it has some of the best documentation, and it's one of the least strict in terms of having to follow any sort of standards.

Categories