Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

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

Original message

Author Cameron Brunner <cameron.brunner@gmail.com>
Full name Cameron Brunner <cameron.brunner@gmail.com>
Date 2006-09-21 07:25:26 PDT
Message On 9/22/06, Hans Lellelid <hans at velum dot net> wrote:
> 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.

Against just following the heard and using PEAR standards

switch ( $blah ) {

    case 'blah':

        echo 'asdf';
        break;

}

indenting the case is something i prefer over not for a start

$long_variable example... well, we could follow that but... painful for nothing?

These are just what I like and find easy to follow and read without
having to think much when i jump into new code. Mostly its just about
not being lazy and getting over typing a few extra lines to save
headaches maintaining.


Cameron