Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP: The Right Way

phptherightway.com

Post reply on HN
Print view View original

171–180 of 233 posts

Re: PHP: The Right Way

#171

Post by VMG »

batista wrote: post #159
dlitz wrote: post #126

Earlier quoted context omitted.

Javascript is just Scheme with a C-like syntax and a limited number of bad design decisions (like automatic semicolon insertion and the == operator). PHP is a never-ending fountain of bad design decisions, because its core devs continue to make new ones.

really? add: floating point everywhere, objects that act like hashes but not exactly, fucked up scoping rules including global by default, the braindead Dom API, a severiously limited standard library, and brain damage coersions to the list...

I'd leave the DOM API out of it, that's not really the languages fault.

Re: PHP: The Right Way

#172

Post by mgkimsal »

kellishaver wrote: post #147
mgkimsal wrote: post #60

Earlier quoted context omitted.

I understand it's not an either/or situation but... I'd MUCH prefer people spend time writing tests for their code vs debating/arguing/refactoring code style. If your tests and good and coverage is high, there's far less chance I should ever even have to muck around inside your libraries, much less modify them. And again, one doesn't preclude the other, but I see so many people making a bit stink over style - tabs vs…

If a library works like it should, then you may never have to look at it - that's great. But if you're working on a team, you'll have to read and understand other people's code all the time, and even if you're not, someone, somewhere, is going to eventually want to make that library do something different. I agree that, of the two, good test coverage is more important than pretty formatting, but a good code style is…

One of the arguments/justifications for the PSR standards is to encourage interop of libraries (to be able to mix/match from various frameworks and projects).

Standardizing formatting for a team/project is not a bad thing, certainly, but if there's competing styles on a team, but they're making good progress - hitting deadlines, high test coverage, good/deep engagement with stakeholders, etc., code formatting is just not something I'd bother enforcing. It may be a later step to go back during a project post-mortem and get the code ready for 'deep freeze', assuming the project is 'done', but how often does that happen?

My perspective is probably a bit different than some here - I freelance, and work in multiple languages for different clients, often concurrently. In a 6 month period I had 2 PHP projects, 2 Grails projects and a Rails project, each running for several months and overlapping. I worked with a different group of people on each project, each with varying skill levels and backgrounds. I adopted my style/technique as best I could for each project, and didn't harp on formatting with anyone, because... it just really doesn't matter. What does bug the heck out of me is someone rechecking out my code, spending time reformatting it, then checking it back in, and counting that as 'work', when there's many many many other issues needing to be worked on.

Re: PHP: The Right Way

#173

Post by adeelk »

jasonlotito wrote: post #121
gbog wrote: post #101

Earlier quoted context omitted.

I used PHP for five years professionally, I consider myself as well positioned as many to have an informed opinion about PHP weaknesses and strengths. My diagnostic is that PHP weaknesses are structural, and no amount of guidance can fix that. If facing the choice, one should not choose PHP over other solutions. (It happens also that I am working in Chinese tech sphere, where many startup choose PHP just because it i…

> I used PHP for five years professionally, I consider myself as well positioned as many to have an informed opinion about PHP weaknesses and strengths. Yeah, that doesn't mean anything. In fact, to be frank, when I read that, I fill in the underlying context: "I used PHP for fives years professionally, and the code was horrible. Granted, it was code I wrote because PHP let me write code that way..." or "I used PHP f…

Any reason for the personal attack (based on unfounded assumptions)?...

Re: PHP: The Right Way

#174

Post by _ikke_ »

smsm42 wrote: post #128
kingkilr wrote: post #18

One point in and its already dead wrong, you never filter input, only output. Edit: Everyone talking about databases: paramaterized queries, check them out.

What's wrong with filtering input? If you expect a number, what's wrong with telling the user "strawberry pie" is not a valid value?

There's a fine line between filtering and validating. What's meant with filtering is things like add_slashes and mysql_real_escape_string, a uniform transformation on the input, regardless of it's destination.

Validating on the other hand is checking if the values satisfy the expected requirements.

You only want to apply certain filters if you know they apply the current output. (htmlentities if output as html, mysql_real_escape_string if embedded in a query).

Re: PHP: The Right Way

#175

Post by denysonique »

aw3c2 wrote: post #40

curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.

In terms of security this is no different than executing someones binary or building a big code base.

Re: PHP: The Right Way

#176

Post by corford »

dlitz wrote: post #125
billpatrianakos wrote: post #90

Earlier quoted context omitted.

We get it, man. PHP sucks, you're cool/smarter/better because you use something else, and you need to remind us all about it by jumping in every time the letters P-H-P are seen in sequence to let us all know how it sucks by retreading the same old lines used by the last fifty guys who said the same thing but to your credit you really tried to be clever about it. A good portion of why people like to mock PHP is due to…

> A good portion of why people like to mock PHP is due to the way people end up using the language rather than the language's ugly parts. Are you really going to trot out that old lie? Why not read this, instead? http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Because huge swathes of that blog post have already been debunked ad infinitum (here on HN, no less).

Re: PHP: The Right Way

#177

Post by jasonlotito »

adeelk wrote: post #173
jasonlotito wrote: post #121

Earlier quoted context omitted.

> I used PHP for five years professionally, I consider myself as well positioned as many to have an informed opinion about PHP weaknesses and strengths. Yeah, that doesn't mean anything. In fact, to be frank, when I read that, I fill in the underlying context: "I used PHP for fives years professionally, and the code was horrible. Granted, it was code I wrote because PHP let me write code that way..." or "I used PHP f…

Any reason for the personal attack (based on unfounded assumptions)?...

No personal attack. You used your experience to justify your position, which really means nothing. You then went on to describe practices that, if written accurately aren't in anyone's book of good things to do.

If you take it personally, thats your issue, not mine,

Re: PHP: The Right Way

#178

Post by jasonlotito »

jeltz wrote: post #152
jasonlotito wrote: post #69

Earlier quoted context omitted.

> the PHP world always does this wrong because they're too focused on HTML. No. The PHP world recommends, time and time again, using PDO and binding variables to queries. I've yet to meet an individual who does it the other way, other than people who are relying on extremely outdated tutorials (7+ years ago). Hell, even this document does. This document, unfortunately, uses the word filter in the wrong way, but the i…

I suggest removing the section about filtering entirely and making sure the section about PDO explains SQL injection briefly.

I'm not the op, but I'll keep that in mind fora push request. I think filtering just needs to be renamed to validation, and improved (but then that was the point of posting it here I imagine).

Re: PHP: The Right Way

#179

Post by adeelk »

jasonlotito wrote: post #177
adeelk wrote: post #173

Earlier quoted context omitted.

Any reason for the personal attack (based on unfounded assumptions)?...

No personal attack. You used your experience to justify your position, which really means nothing. You then went on to describe practices that, if written accurately aren't in anyone's book of good things to do. If you take it personally, thats your issue, not mine,

I’m not the OP.

Re: PHP: The Right Way

#180

Post by jasonlotito »

Dylan16807 wrote: post #144
jasonlotito wrote: post #120

Earlier quoted context omitted.

I'm looking at the post you replied to. So maybe you replied to the wrong post, or ignore context and tried to be witty or smart. In context, what you say makes no sense. Regardless, https would be better, but if you are that nervous as you suggest you are, then https doesn't solve your problem either. Neither does some hash thrown up on some site for you to compare against.

Here, how about I summarize my view of the conversation for you. aw3c2: 'curl | php' is creepy timaelliott: apt-get is just as scary kudos: no, it has signing udo: that's cargo cult me: no, it protects like https (meaning it authenticates and stops MitM) I was responding perfectly in context to point out how the protections apt-get have are useful. I also tied it back into the original comment but you can ignore that…

Ahh, gotcha, that better explains it.

Still, https doesn't validate anything. You could add a certificate, but then that only means you are talking to the server assigned the cert, not that the actual package is good.

I still stand by what I said: mountain and mole hills.

Post reply on HN