Login | Register
My pages Projects Community openCollabNet

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author hlellelid
Full name Hans Lellelid
Date 2006-09-21 07:03:20 PDT
Message Hi,

Cameron Brunner wrote:
> On 9/21/06, Ron Rademaker <r.rademaker@virt​ualbuilding.nl> wrote:
>> A few thoughts:
>> - On the comments before a function. How about always adding a @since
>> with the date the function was added and an @author who added the
>> function (makes finding the appropriate person for bugs / questions /
>> suggestions a lot easier than going through svn logs)
> svn blame, but agreed, author for the class and then if the author
> isnt the same for the function then it should be on the function as
> well, same rules for since

We can also get rid of Torque authors at this point (1.3 onward). I
wanted to attribute the origins of the code as appropriate, but the
classes have been reworked a number of times now -- so they'll probably
be bearing little resemblance to any Torque code from here on out.

>> - Personally, I like if styles like this:
>> if ($something)
>> return "something";
>> Two lined if's without {} that is, current coding standards don't tell
>> me if I can use them.
> ug, no, i HATE this, people rely on it for more than 1 line of code
> below the if too often, we should blow this out of existance!

Yeah, I tend to agree. My personal preference is a hybrid approach
where functions are like

public function myfunc()


but if-statements are on same line:

if ($foo === true) {

} elseif () {

} else {


But for the same of consistency, I'm willing to give up my functions
with { opening on their own line :)

For simplicity, we may just wish to adopt the PEAR coding standards,
since they are ubiquitous in the PHP world.