RE: [PEAR-DEV] Re: Package proposal Science_Weather

Ok, i prefer the way without the $var_name, i just wanted confirmation it was a feature and not an uplanned behaviour :) Arnaud. > Hi Arnaud, > > This is a personal choice. I have started using @param string blah > because of the risk of typos. PhpDocumentor 1.x does not return a > warning if a @params parameter name does not match an actual > parameter. > Why? > > /** > * @param string the format string > * @param string $args... an unlimited number of strings > */ > function sprintf($format) > { > } > > Variable arguments can't be documented if we are strict. Version 2.0 > will fix this (once error handling is fully fixed in PEAR, so that we > can raise notices) by raising a notice if a parameter name > does not match. > > I've found that when parameters change names, it is more > convenient to > avoid the $varname in the parameter, because it will shunt to a new > parameter definition, but that is a personal choice. If you are > meticulous, the way listed below works just fine. > > Greg > > LIMBOURG Arnaud wrote: > > > > /** > > > * Sets the neccessary account-information for weather.com > > > * > > > * @param string $partnerID > > > * @param string $licenseKey > > > * @access public > > > */ > > > function setAccountData($partnerID, $licenseKey) > > > > Which brings me to a question greg. > > > > I notice you write the parameter variable like $partnerID in the > > phpdoc. However, when it's not there but the @param tags are in the > > same order as they appear in the function() definition, > phpdocumentor > > parses this intelligently. > > > > So what is the ways to go ? > > > > @param string $var blah > > > > or just > > > > @param string blah > > > > I switched to the last one since it works very well. > > > > Arnaud. > > >