On 06/06/10 03:02, Nick Sabalausky wrote:
"Robert Clipsham"<[email protected]> wrote in message
news:[email protected]...
Being the only two languages I'd call myself fluent in, I'd definitely
call D easier to maintain than PHP... I guess this is easily debatable
though.
Easily debatable? Not without an existing brain injury ;)
I've used a lot of different languages. PHP's maintainability is one of the
worst I've ever seen. The whole design of it *begs* for bugs.
Or worse, security issues - heck, the examples on php.net are so easy
for someone new to the language to use to introduce a large number of
security issues with it's unbelievable. It doesn't take much to find a
number of SQL injections in the code most PHP devs write - it's so easy
to do! If only there were a language that made safe operations easy to
do and harder more bug prone things harder to do :3
Hell, PHP is the only (*cough*) modern (*cough*) language I can think of
where bugs can actually be introduced without any programmer involvement and
without even touching a single line of code. The sysadmin just needs to
change any one of certain PHP server settings (or move the code to another
server that isn't configured exactly the same), and suddenly random parts of
the code are silently broken and the programmer is screwed.
An old example is magic quotes - your code will magically (and silently)
break if the setting is changed without adjusting the code to compensate.
Yea, I know they're deprecated in PHP5 and removed in PHP6, but it's just
one off-the-top-of-my-head example of a bigger theme:
My favourite is register_globals - not only does it introduce bugs, it
allows for remote code execution! Gotta love that ;)
It's standard practice by PHP's creators to toss in language-changing server
settings, and without even having predictable defaults (the *defaults* can
be configured. Seriously, WTF?). These settings often either can't be
adjusted in the code itself (ex: magic quotes) or can only *sometimes* be
adjusted in the code depending on how the server settings are configured (I
think some session-management stuff falls into this category...and speaking
of PHP's session-management...well, better *not* to speak of it). So not
only does stuff change from one PHP version to another, but even within a
*single exact* version of PHP you *still* have 2^^n number of what are
essentially different languages, and no realistic way to work around it.
Fortunately you can detect what's disabled/how it's configured etc in
the script, it means you have to write 1000LoC of checks etc before
every php app you write if you want it to be supported by a selection of
hosts. Refusing anything less than PHP 5.2 helps here, there's still
loads of checks you've gotta do though. I generally find the best way to
avoid bugs due to different configs/PHP versions is to use
error_reporting( E_ALL | E_STRICT | E_DEPRECATED ); at the start of all
my code, even that has to check the PHP version though thanks to
E_DEPRECATED... and there'll still be some bugs that manage to slip
through :3
So to write good reliable code in PHP:
I was gonna make a witty remark here, I found it turning into a rant so
I removed it though :3
First, you have to have a deep understanding of every fucking setting
offered by every version of PHP that you use. Of course, many of the
important gotchas are completely undocumented and you have to go by hearsay
and anecdotal advice. So good luck with that.
This is completely true. Using some kind of PHP framework usually solves
this problem for you as they do all the checks etc generally, it's still
not perfect though, and the developer still has to be aware of what the
framework actually checks for.
Then you have to identify which of those settings might cause problems
depending on how they're set and make sure to set them properly at the start
of every single page (not always easy when your "package" system is one step
away from the C preprocessor).
If you can set them properly that is :3 Gotta hate safe mode/the ability
of clueless admins to disable functions which don't pose any security
vulnerability to the server but they're adamant they do.
Then, for the ones you can't change (because of either your sysadmin or PHP
itself), you have to find the common "safe" subset and not venture beyond it
(Ex: goodbye '<%%>' and'<??>', it's'<?php ?>' or nothing). When there
isn't a safe common subset you can rely on (ex: magic quotes) you have to
detect the active setting (if possible) and adapt. Of course, even doing
that isn't always possible.
trigger_error( "Your setup sucks, damned if I'm writing code that
supports it :3", E_USER_ERROR );
I love not having to write commercial code where supporting idiots is
mandatory, I'd rather not spend 90% of my time making sure my code works
on different setups :3
Then when the server's PHP is upgraded, you have to check everything all
over again (or just pray). Oh, and did I mention sometimes the OS and
OS-configuration abstractions leek? Needless to say, writing good reliable
code in PHP is realistically impossible (frankly, I don't even bother to try
anymore). And if you want to make a re-usable library...hah! Ha ha ha!! Ah
ha ha ha ha ha!!!
Fat chance of that if they've got register_globals enabled or
magic_quotes etc. You'll be lucky if they upgrade in a few years :3
This said, there are people who are *that* stupid.
So, PHP maintainability? Welcome to hell. PHP is evilness itself, given form
as a programming language. Given a choice, I would seriously consider
writing classic-ASP in VBScript on a WinME workstation running Microsoft Bob
with an IDE that included Clippy if the only alternative was to do a big
project in hand-written PHP.
I guess I'm lucky here, all the PHP I ever have to write now is
supported by a framework/CMS that some guy who knows what he's doing
made, I've yet to have any issues with it anywhere it's been run
fortunately. I'd put money on this not being the case for most people
though.
I would be curious as to how well D/FastCGI works, guess I'll have to
have a play at some point.
Robert
