Re: PSR-1 and PSR-2 Cake 3

[José Lorenzo]

I think most of them are already included into current codebase, my only problem with those are spaces instead of tabs because it greatly changes the way I work and I think it is a step in the wrong direction.

At the end if we just have to change everything to spaces, so be it. Opposing is as silly and proposing it

On Thu, May 31, 2012 at 10:37 PM, Vinícius Krolow <kro...@gmail.com> wrote:

What about the PSR-1 and PSR-2 for CakePHP 3? https://github.com/pmjones/fig-standards/blob/psr-1-style-guide/proposed/PSR-1-basic.md https://github.com/pmjones/fig-standards/blob/psr-1-style-guide/proposed/PSR-2-advanced.md

is that possible or it's against this standard?

[Juan Basso]

Looking the rules, we currently follow the psr-1 fully. In the psr-2 we dont follow just few things, like tab/spaces and braces in new line for classes.

As Jose said, I am not a big fan from spaces and it can cause a huge impact in our codebase, once the merge between branches will cause a couple of conflicts.

Juan Basso

[rchavik]

-1 for space as indent char.

[Cauan Cabral]

I don't like spaces too, but I think the code "portable" and standardized are more important than just a preference of mine.
If code is only for me, I'll using tabs, but for a world class framework like CakePHP is not the case.

All moderns IDE and code editors can easily change between tabs and spaces, I don't think this will be so hard.

+1 for standards in CakePHP.

On Fri, Jun 1, 2012 at 10:38 AM, rchavik <rch...@gmail.com> wrote:

-1 for space as indent char.

--

Cauan Cabral
----------------

Como falar comigo: Google Talk: cau...@gmail.com Skype: CauanCabral MSN: cau...@gmail.com

Onde me encontrar:

[Graham Weldon]

I'm all for standards that help code be portable.

Cosmetic standards don't make sense to me, though.

PSR-0 is a great movement. Truly a good step towards standardisation and portable code.

The physical layout of the code is not important for this, and doesn't impact the usability of code across different packages and software.

Compliance with standards like PSR-1 and PSR-2 is not something that I will support personally. We've had an established standard for over 8 years, and we gain no benefit by changing it.

This is PHP, not an indentation-sensitive language like python.

-1

Cheers,

Graham Weldon

http://grahamweldon.com

e. gra...@grahamweldon.com

p. (+61) 0407 017 293

Skype: grahamweldon

[AD7six]

On Friday, 1 June 2012 17:34:28 UTC+2, Graham Weldon wrote:

I'm all for standards that help code be portable.

Cosmetic standards don't make sense to me, though.

 

I'm ok with PSR-1.

Cake mostly follows it anyway. I think the only exception is 

Method names MUST be declared in camelCase.

Because right now controller action names are underscored.

I'm -1 on PSR-2.

It's fundamentally cosmetic and an imposed preference. It's also not a standard - it's a guide.

If I agreed with the changes in PSR-2, I'd still be -1. It's a royal PITA to change existing code to match a new code-standard. I'm the guilty party of creating a huge amount of work for, mostly, mark by applying previous code-standard changes (such as a new line before all doc blocks) as such  it doing it again we know it'll create merge conflicts and general annoyance in normal workflow (releases). 

AD

[Cauan Cabral]

On Fri, Jun 1, 2012 at 12:40 PM, AD7six <andyda...@gmail.com> wrote:

On Friday, 1 June 2012 17:34:28 UTC+2, Graham Weldon wrote:

I'm all for standards that help code be portable.

Cosmetic standards don't make sense to me, though.

Sure. I agree with it. Are all cosmetic standard. But it's a standard.

 

I'm ok with PSR-1.

Cake mostly follows it anyway. I think the only exception is 

Method names MUST be declared in camelCase.

Because right now controller action names are underscored.

I'm -1 on PSR-2.

It's fundamentally cosmetic and an imposed preference. It's also not a standard - it's a guide.

Imposed preference is very relative. There are a group to discuss and approve it's standards, with representants
of all major PHP frameworks and cms: http://groups.google.com/group/php-standards
It's not a decision of one guy.

But I understand all your concerns.

If I agreed with the changes in PSR-2, I'd still be -1. It's a royal PITA to change existing code to match a new code-standard. I'm the guilty party of creating a huge amount of work for, mostly, mark by applying previous code-standard changes (such as a new line before all doc blocks) as such  it doing it again we know it'll create merge conflicts and general annoyance in normal workflow (releases). 

AD

[rchavik]

My reason is purely selfish.

I decided to use cakephp several years ago after looking
at several other frameworks. Aside from the elegant internals, the CS is one I was happy with: one I could use, contribute, and enjoy working with.

Forcing this style on me after using this for several years
will make me real sad. It won't make me use something else,
nor stop my contribution, but it would surely make it less
enjoyable.

Much less.

[ADmad]

I don't like spaces too, but I think the code "portable" and standardized are more important than just a preference of mine.
If code is only for me, I'll using tabs, but for a world class framework like CakePHP is not the case.

 

Not following PSR-2's recommendation for indentation and braces is not going to make CakePHP any less world class.

We should definitely follow all standards relating to portability and inter operatibility with other frameworks but changing the CS which we have been following for years has absolutely no benefit, only headaches.

[euromark]

just because 20 frameworks do it wrong, doesnt make it right

spaces are not meant to indent code. tabs are. maybe they will understand - in time.

therefore cake shouldnt adopt to wrong guidelines just because those now came to this single wrong conclusion.

so I agree with with ADmad

I am strongly against PSR-2 and what those "exports" concluded.

[Washington Luiz]

Why is it wrong to use spaces to indent code? Or why is it wrong to use tabs? I personally have been using spaces for a long time. But I dont see anything wrong with using tabs.

Also I guess theres no problem having both spaces and tabs to indent code on the same file.

[Jamie Nay]

It's not wrong to use either. Some people love spaces, some love tabs. It doesn't matter what you use, as long as you're consistent.

[mark_story]

I love standards too, but I think PSR-2 (primarily the space for indent rule) is going to be nothing but pain for CakePHP.  Updating a large codebase (CakePHP) and all the plugins is not something I relish.   With that said I think following PSR-0 and PSR-1 is pretty simple and something we should shoot for with 3.0.

-Mark

[shama]

-1. PSR-2 is not a standard. It is a style guide that conveniently conforms to most of the voting members. This will be proven when/if CakePHP and other frameworks refuse to strictly follow PSR-2 and yet still achieve interoperability.

My tabs and single line curly brace style choices will not prevent interoperability between frameworks thus it is an inappropriate standard.

- Kyle

[Ceeram]

For all the mentioned reasons:

-1 on spaces for indenting from me as well.

To conclude form earlier responses, am i correct to conclude the following??

CakePHP 3+ will be compliant to PSR-0
CakePHP 3+ will be compliant to PSR-1
CakePHP 3+ will be compliant to most of PSR-2 with exception of:
 - spaces for indent
 - braces on newlines? or will we change this in 3+ ?

basically this comes down to PSR-0 and PSR-1 and stick with current coding conventions


Op maandag 25 juni 2012 09:40:54 UTC+2 schreef burzum het volgende:

It is easy to type one space more or less by mistake. You can't configure spaces to appear as 1, 2 or 4 spaces width in your editor but you can configure that for tabs. So by using tabs everyone could set their preferred indent width by simply changing the width for tabs in the editor. Spaces were never thought and designed to be used for indention but tabs were exactly thought for that.

And the decision to use spaces over tabs in PSR is in my opinion just a pure selfish decision because most of the PSR members simply won't change their code.

-1 to spaces.

[Juan Basso]

You are correct. The braces in new line is also one thing we should not follow. It will not affect anything in the code quality or interoperability.

Juan Basso

[euromark]

I totally agree with juan.