--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
Definite +1 from me.
Switching from tabs to spaces looks like it might pollute the blame view.
I think it’s perfectly acceptable to have deprecated methods that don’t follow the conventions - we shouldn’t let coding style dictate upgrade pain after all.
- Use lowerCamelCase() for static methods. Given that we had a lot of static lowerCamelCase methods changed to snake_case in 3.x to suit the SS standards, this would be a bit of an embarrassing flip-flop, but embarrassment aside. Note that we would probably preserve the snake_case methods as deprecated methods in 4.x, and remove them in 5.x, to ease the upgrade pain. So 4.x wouldn't be strictly PSR-2 complaint but would be on the way.
We already have a code style, so I guess you could make your argument against having a code style at all, and not specifically against adopting/changing to a new code style. However, adopting PSR-2 as a code style means developers already familiar with this widely accepted style will not have any new code style to learn to be able to contribute to SilverStripe.
Nicolaas,What are the benefits to any code style? Consistent code styles reduce the cognitive overhead in code reviews, so errors can be easily spotted.
We already have a code style, so I guess you could make your argument against having a code style at all, and not specifically against adopting/changing to a new code style. However, adopting PSR-2 as a code style means developers already familiar with this widely accepted style will not have any new code style to learn to be able to contribute to SilverStripe.
The biggest benefit from using standard PSR-2:
There are tons of tools to do the formatting work for you. Every good IDE has it built in.
So you can automate converting your stuff to PRS-2 on save, on commit, whatever.
But as it’s a matter of taste this discussion is pretty useless. Either you like it or not. But you cannot discuss about taste!
So I’m happy with PSR-2, as it would make it easier for me to format my code (automatically) to fit the standard.
I’m also happy to leave it as is, but I cannot guarantee that my code fits 100% the current standards, but I try my very best.
And with every refactoring you might find better names for your variables ;)
Cheers,
Werner
--
The biggest benefit from using standard PSR-2:
There are tons of tools to do the formatting work for you. Every good IDE has it built in.