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

141–150 of 233 posts

Re: PHP: The Right Way

#141

Post by anthonyb »

zdw wrote: post #124
anthonyb wrote: post #88

Earlier quoted context omitted.

md5 is not going to protect you from much, especially if the md5 checksums are hosted on the same server. Also, pushing random code via apt-get is not going to win you any sysadmin friends. They like their servers to be stable, and their packages to be well tested.

Seeing as you can remove said code via apt, you'd likely win them over compared to the alternative of being told to install compilers or some other non package managed software bundler like cpan/rvm/npm that can't be canned and easily deployed.

But why would you remove it? Because whatever you've installed has broken.

Much better not to be broken in the first place.

Re: PHP: The Right Way

#142

Post by smsm42 »

ufo wrote: post #131
LnxPrgr3 wrote: post #96

Earlier quoted context omitted.

Sure, but you defined ptr outside of the loop. Who defined $object outside of the loop in the PHP example? Also note that, in C, you have to explicitly dereference pointers: ptr = 42; You should get a warning from your compiler if you try that. PHP effectively goes ahead and changes it to: *ptr = 42; Perl requires you to explicitly dereference references as well: @array = ('c', 'c++', 'java', 'perl'); $item = \$array…

WTF. Sometimes I wonder if I'm being unfairly prejudiced by not learning PHP myself and making my own decision about it but things like this make me change my mind.

You are completely correct - you are being unfairly prejudiced by judging PHP on explanations of people that do not understand it instead of learning it. If you learned it, you would know references work exactly like they supposed to, and do exactly what they are meant to do - just because they are not, as parent assumes, pointers, he misunderstands them and thinks they are weird. Moreover, he thinks since PHP in not like C and does not have C-like pointers PHP is weird. Please read http://us2.php.net/references if you want real information instead of collection of misunderstanding.

Re: PHP: The Right Way

#143

Post by smsm42 »

wvenable wrote: post #38
BadCRC wrote: post #14

These guidelines won't save you from some bullshit PHP "rules", such as: http://stackoverflow.com/questions/5810168/php-foreach-by-re...

The result is 100% logical. My own personal guideline is to never use references anywhere; even in a foreach loop you can use the key to modify the original array instead of a reference to the value.

References have their uses, but they are not the simplest concept. For people that think references are like C pointers it is indeed better and safer to never use them. For the rest of people, in about 90% of cases you think you need them you actually don't. But the remaining 10% is still there.

Re: PHP: The Right Way

#144

Post by Dylan16807 »

jasonlotito wrote: post #120
Dylan16807 wrote: post #77

Earlier quoted context omitted.

Look at the original post. "curl -s http://getcomposer.org/installer | php" It's not just about trusting Composer, it's about trusting every point between you and their server. If I want to know that I am actually executing Composer I need to use a secure download method.

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 part if you like. I don't know why you think I was 'trying to be witty' and ignoring context.

Re: PHP: The Right Way

#145

Post by huhtenberg »

dsl wrote: post #137
mcantor wrote: post #130

Earlier quoted context omitted.

Yeah... only idiots "sudo aptitude install" without reading and building from source first!

You really can't tell the difference between blindly executing input from an insecure HTTP connection, and installing packages with a tool that verifies cryptographic signatures against known good keys shipped with your distro? Mr. Cantor, I have added to the list of people to never hire I keep in my notebook.

The risk of picking up malicious executable from the legit server is far higher than that of picking up a malicious executable from an impersonating server. Practically speaking.

Re: PHP: The Right Way

#146

Post by wvenable »

smsm42 wrote: post #143
wvenable wrote: post #38

Earlier quoted context omitted.

The result is 100% logical. My own personal guideline is to never use references anywhere; even in a foreach loop you can use the key to modify the original array instead of a reference to the value.

References have their uses, but they are not the simplest concept. For people that think references are like C pointers it is indeed better and safer to never use them. For the rest of people, in about 90% of cases you think you need them you actually don't. But the remaining 10% is still there.

The only place I can see that references still have some value is for "out" parameters on functions. But, since it's easy to do multiple return values in PHP, even that is not terribly relevant.

Re: PHP: The Right Way

#147

Post by kellishaver »

mgkimsal wrote: post #60
kellishaver wrote: post #21

Earlier quoted context omitted.

Right. I think the main take-away from it is to be consistent and make sure everyone on your team is on the same page about the coding style. I see the PSR as a basic set of good recommendations, rather than something that must be followed. It's a good idea to follow it, but at least follow something . My only complaint with it personally is that I Can. Not. Stand. putting opening brackets on their own line.

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 going to make the code easier to debug when those tests fail and easier to extend when the library needs to do more. It's a simple matter adopt a coding style that works and stick with it, so there's really no good reason not to do it.

By comparison, it does seem like a trivial thing to obsess over. There are a number of coding styles which are all fine in their own right. I think people should worry less about the specifics and more about the overall intent-to write consistent, clean code. How many blank lines you have after block of code or where you put the opening bracket doesn't really mater in the end, as long as you follow the same structure across the whole code base.

Re: PHP: The Right Way

#148

Post by kellishaver »

xd wrote: post #46
kellishaver wrote: post #30

Earlier quoted context omitted.

With parametrized queries, that becomes a non-issue, but I still see no point in cluttering the database with data that's just going to be filtered out at some point - might as well filter it before it goes into the DB to begin with. The exception, of course, being those rare cases when some users need to see the filtered data and others need to see the raw data, but even then, you likely won't want to allow everythi…

Parametized queries are just another way of filtering input ..

Yes, but on the site, they make a clear distinction between parametrized queries with PDO and other types of input filtering. I misunderstood and thought you were referring specifically to the latter.

Re: PHP: The Right Way

#149

Post by kellishaver »

silentworks wrote: post #35
kellishaver wrote: post #30

Earlier quoted context omitted.

With parametrized queries, that becomes a non-issue, but I still see no point in cluttering the database with data that's just going to be filtered out at some point - might as well filter it before it goes into the DB to begin with. The exception, of course, being those rare cases when some users need to see the filtered data and others need to see the raw data, but even then, you likely won't want to allow everythi…

I am not sure if you are referring to the same sort of filtering mentioned in the document. The data is filtered before it hits the database layer, this saves resource being used.

That's what I meant. I just kind of articulated it poorly, my apologies.

Re: PHP: The Right Way

#150

Post by derekerdmann »

nikic wrote: post #27

I like the general idea of this, but think that it is nearly useless in its current form. It's way too superficial. To teach newbies how to do things right it doesn't suffice to link to a few resources and hope that they'll read them (hint: they won't). Instead one needs more concrete code examples, etc. Which would obviously be too much for one page :)

If you have ideas, the author points out that he's accepting contributions from the community: https://github.com/codeguy/php-the-right-way
Post reply on HN