I do not want to be mean, but I honestly feel there is no 'right way' in case of PHP. There are communities that care about 'doing it right' and there are some that want just to 'get the job done'. I prefer the former, PHP always seemed to prefer the latter.
PHP the Wrong Way
21–30 of 194 posts
Re: PHP the Wrong Way
#22There is a grain of truth in what they're trying to say, but the conclusions are outright misguided. My favorite is "The wrong way: Thinking of patterns when solving problems." -- textbook reinventing the wheel / NIH.
I don't think it's saying exactly that. One should think up a solution first, then see if one needs patterns to fit that solution into the code base in language of choice. PHP certainly doesn't need all of Gang of Four recipes due to dynamicity and other factors.
Re: PHP the Wrong Way
#23I generally agree with the view of keeping your application simple and not using big frameworks but after seeing so many PHP programmers write spaghetti and insecure code, I pretty much recommend frameworks now. You can say the problem is not with writing PHP without any framework but with the programmers, the problem lies with the low barrier for entry into PHP. Frameworks atleast teach you how to make your code mod…
In my experience using a framework does not prevent spaghetti code.
Re: PHP the Wrong Way
#24I just skimmed the website, and I am still not sure if it's meant seriously or if it's some kind of joke? Feels a bit contradictory eg. "dont use framework" vs "make software secure by default". Isn't a security one of the gains of using frameworks, beside other things? You would need to be a security expert to cover all potential security issues when writing something from a scratch.
You may be drowning in the kool-aid. It is very easy to write tiny secure code in PHP without a framework. Of course if you're building a social network, then it will run into some of those potential security issues. But for most of the small problems you're using PHP to solve, you really don't need to be a security expert as long as you're not piping user input directly to your database or OS. It's kind of the point…
No it's not easy. You need to be sure you escape everything, setup a mecanism for allowed host, CSRF, anti click-hijacking and of course ensure your auth workflow is nicely designed.
And that supposes that not only you know about it, but also how to implement it properly. Not to mention the time to code it, document it, test it and maintain it.
Most custom PHP site I encounter are full of gigantic holes.
And then other developpers comes in, and have to learn how to use your non standard code, that is unlikely to be half as well written, tested or documented than standard solutions.
Of course custom code has also a cost, which means doing all that, even not very well, will take a toll on the budget, which you can't spend on other security aspects. All that while security is generally the last item on the budget list.
Re: PHP the Wrong Way
#25I do not want to be mean, but I honestly feel there is no 'right way' in case of PHP. There are communities that care about 'doing it right' and there are some that want just to 'get the job done'. I prefer the former, PHP always seemed to prefer the latter.
This is a massive overgeneralisation of a humongous amount of people and man-hours of work. Why do you feel this? Do you have anything to back up this statement?
Anecdotally speaking, I'm a Senior Software Engineer working with Go and PHP.
We use Go when working on performance critical code, because for us that's where it excels.
We use PHP when we need simple interoperability with the legacy Magento site our company runs and for jobs like running a CSV importer or some other oft-visited-task. We both get the job done and care about doing it right. You can write some truly beautiful code in PHP if you have the correct level of patience, process and experience behind you.
Re: PHP the Wrong Way
#26I generally agree with the view of keeping your application simple and not using big frameworks but after seeing so many PHP programmers write spaghetti and insecure code, I pretty much recommend frameworks now. You can say the problem is not with writing PHP without any framework but with the programmers, the problem lies with the low barrier for entry into PHP. Frameworks atleast teach you how to make your code mod…
In my experience using a framework does not prevent spaghetti code.
If you want to write spaghetti code, you can write it whichever approach you take. It's more about making it difficult to shoot yourself in the foot.
Re: PHP the Wrong Way
#27Earlier quoted context omitted.
You may be drowning in the kool-aid. It is very easy to write tiny secure code in PHP without a framework. Of course if you're building a social network, then it will run into some of those potential security issues. But for most of the small problems you're using PHP to solve, you really don't need to be a security expert as long as you're not piping user input directly to your database or OS. It's kind of the point…
No it's not easy. You need to be sure you escape everything, setup a mecanism for allowed host, CSRF, anti click-hijacking and of course ensure your auth workflow is nicely designed. And that supposes that not only you know about it, but also how to implement it properly. Not to mention the time to code it, document it, test it and maintain it. Most custom PHP site I encounter are full of gigantic holes. And then oth…
I think RyanZAG was referring to solving one small problem with a PHP script. That does not necessitate a web page or any of the security mechanisms you suggest.
Re: PHP the Wrong Way
#28I do not want to be mean, but I honestly feel there is no 'right way' in case of PHP. There are communities that care about 'doing it right' and there are some that want just to 'get the job done'. I prefer the former, PHP always seemed to prefer the latter.
This is a massive overgeneralisation of a humongous amount of people and man-hours of work. Why do you feel this? Do you have anything to back up this statement? Anecdotally speaking, I'm a Senior Software Engineer working with Go and PHP. We use Go when working on performance critical code, because for us that's where it excels. We use PHP when we need simple interoperability with the legacy Magento site our company…
99% of people who get paid to write PHP do not have the requisite level of patience, process, or experience to write a fibonacci method let alone write "truly beautiful" PHP.
Re: PHP the Wrong Way
#29Earlier quoted context omitted.
No it's not easy. You need to be sure you escape everything, setup a mecanism for allowed host, CSRF, anti click-hijacking and of course ensure your auth workflow is nicely designed. And that supposes that not only you know about it, but also how to implement it properly. Not to mention the time to code it, document it, test it and maintain it. Most custom PHP site I encounter are full of gigantic holes. And then oth…
I think RyanZAG was referring to solving one small problem with a PHP script. That does not necessitate a web page or any of the security mechanisms you suggest.
There is no such things as a "general purpose" framework anyone would use for such a small script. This would make no sense.
Re: PHP the Wrong Way
#30Earlier quoted context omitted.
The very existence of PHP is a contradiction, so I wouldn't sweat to much about it. But speaking of boolean logic, negating "always use a framework" does not yield your interpretation.
"The very existence of PHP is a contradiction" Uhm no for me coming from a C background I love PHP since its basically C with a lot of the boring/repetitive stuff abstracted away Good PHP code exists, it only got a bad name due to "web developers" with no formal programming education stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes. PHP is a hammer, bla…
PHP (the interpreter) used to be filled with bugs, design flaws and incoherences. It got better lately, but IMO it still caries a huge mess of legacy stuff that shouldn't even exist (mysql_real_escape_string anyone?)
In this case, both the hammer and the hammer's user can be blamed.