TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
PSR-1 and PSR-2
  • Will Kohana eventually follow the following guidelines? http://phpmaster.com/psr-1-and-psr-2-to-be-approved-as-standards/

  • "The nice thing about standards is that you have so many to choose from. "

    • Andrew S. Tanenbaum
  • Mmmh, but this one comes from PHP Standards group. Imho, if you want to push PHP to the next level, you should adhere to these.

    For Kohana, it would mean more interoperability in the least. Kohana is not your all-in-one framework, so extending is a must.

  • Will Kohana eventually follow the following guidelines?

    No.

    psr-1 and 2 have nothing to do with interoperability.

    Mmmh, but this one comes from PHP Standards group.

    Just a bunch of guys deciding their own rules :)

    you should adhere to these

    They don't actually do anything.

    For Kohana, it would mean more interoperability in the least. Kohana is not your all-in-one framework, so extending is a must.

    That's what PSR-0 was for. We implemented that.

  • Dear god I hope not - if it does I'll probably fork. Enforcing StudlyCaps and camelCase has nothing to do with interoperability, and in my personal opinion is horrible for readability (it's a matter of opinion of course, and another project is welcome to do so, but I shouldn't be forced to). Meanwhile, indenting with space rather than tab is a backward step and prevents developers from viewing code with a depth of indentation that works for their editor/viewer/etc as well as losing the semantic meaning of the indentation.

    Of course, the only real reason why the casing of classes matters a jot for interoperability is because of the fundamentally broken case sensitive filename mapping in PSR-0. If PSR-0 mapped class names to lowercase file names, then the casing of class names would have no impact.

    Beyond that one, the vast majority of the others will cause no impact on Kohana's ability to interop without adopting their style - most people already include some YuckyCased classes and methods if using eg Doctrine/Swift/etc within a Kohana codebase with no problems.

    I object to the attempt by a self-appointed group of developers from major frameworks (who are of course fully entitled to their own views on coding style in their own projects) to impose that on the wider PHP community and particularly by adopting the misleading "PHP Standards Working Group" name which implies to newcomers (and some oldcomers) a much closer relationship to core PHP than is in fact the case...

  • @zombor - phew! Hoped you'd say that...

  • The multiple occurrences of the word "MUST" in these, er, "guidelines" are a bit scary. Expect PSR-3 to focus on personal hygiene and manner of dress.

  • Urgh, so many MUSTs with so few justifications. Enforcing spaces for indentation is especially obnoxious.

    N.b.: Using only spaces, and not mixing spaces with tabs, helps to avoid problems with diffs, patches, history, and annotations. The use of spaces also makes it easy to insert fine-grained sub-indentation for inter-line alignment.

    And what problems are these exactly? Whatever they are, does it justify 4 x whitespace and larger filesizes, when using tabs with spaces works just as well for vertical alignment in the few instances where it's needed.

    I've never understood the Zend, Symfony and PEAR obsession with this - removing our ability to configure our own tab sizes and alignment in editors.

    I see there are only 20 people in the group allowed to vote! Guess where they're all comng from ...

    There is more good news in that PSR-1 and PSR-2 can be enforced with PHP-CS-Fixer [...] Thank you Fabien Potencier for your efforts on the sniffer; you did a great job.

    Yeah, right.

  • It's largely based on hear-say from what I can tell.

    Also, they are no "PHP Standards group" since they were self proclaimed and also have very explicitly stated they only care for their projects. In other words they are the "Symphoney/blah-blah" standards group with a very large ego. Their standards are also "orders" more then anything; there's barely any logical reasoning in PSR-0 too, it just happens that the main idea/implementation kind of works out. The idea of a "style standard" is absurd IMO.

    The only thing adopting their standards achieves is getting their approval. Which frankly, given their pompous ass attitude, I don't care for one bit.

  • Just read "3. Namespace and Class Names" in PSR-1... who the hell wrote this crap?

    It's pretty clear that these "standards" are only getting attention though abuse of leverage within the community.

  • What is the problem? Nobody is forcing you to use them. Whilst I disagree with a number of the requirements in the standards, I think it is a great idea.

  • Read more via @shadowhand's membership request at groups.google/php-standards

  • *** SPOILER ALERT ***

    Woody retracts his membership application.

    Still worth a read though.

    "Programming is as much art and craft as it is science." says Paul M. Jones. The word "art" has no place here, says me. Expanding the Jones logic would have "standards" formulated whereby novelists and poets must be constrained in their use of language. Forget art, let's code.

  • Now they're talking about badges to confirm compliance with the PSR-s . Just wait until clients start demanding this blindly. Certification next, I guess.

    Conspicuous by their absence: Kohana, CI, Fuel, Laravel, Yii. Why are Aurora and PPI in there - who uses those?

  • If you are a leader of a framework, and you agree to blindly apply all PSR initiatives to your project, you can become a voting member. The second part is why we aren't a part of it.

  • They changed the fact that you have to apply all the PSRs since @shadowhand last tried joining.

  • Aren't they just losing credibility by only adding voting members who share their views?

  • A classic example of confirmation bias unfortunately.

    One thing this reinforces for me though: a renewed commitment to Kohana. I just can't seem to stop coming back to it. :)

  • They lost me at the 1st or 2nd MUST :))

  • Interesting read. I'm afraid there will never be an agreement as niether side wants to give up its prefered coding style. The truth is, it's so easy to adopt a new coding style and actually like it. I'm currently using the zend/sym style and enjoying it. Now I find ultra hard to back to the ko style. It all comes down to how much you use a particular style, that determines how much you are attached to it and can't see it any other way. At the end of the day, it's the code that matters, not the formatting. No one gets hired for pretty code.

  • One thing that's really struck me with the Symfony and Zend components recently is how sparsely documented the code tends to be, and this seems to be a consequence of the coding style. They very much rely on tutorials and guides for API usage - which I must admit with Symfony are exemplary.

    The Kohana coding style by contrast seems to encourage much more detailed inline commentary, with an emphasis on explaining the different logic steps. This means that I've found Kohana code generally much easier to extend and adapt than Symfony's. Example:

    // This style encourages blocks of code preceded by brief comments
    if ($foo == $bar) {
      .....
      .....
    } else {
      .....
    }
    
    vs.
    
    if ($foo == $bar)
    {
      // Here it's easier to document the decision  
      .....
    }
    else
    {
      // And this one too, so the whole logic flow is clearer
      .....
    }
    
    

    So there are other aspects to this discussion of coding standards for me. It's notable that there's nothing in PSR-1 or PSR-2 about best commenting practices. I would have thought this would be a higher priority if interop was the driving concern.

  • The best kind of code needs no comments :)

  • The Symfony source code is pretty disgusting to follow through or try to make sense of things. Ko code is pretty much written in plain english with perfect grammar.

    @zeebee It's not really the coding style, they usually just don't inline comment that much. Kohana is overly commented, so we're spoiled :)

  • @goyote Although you can learn a ton of interesting stuff by reading Symfony 2 source code.

    Still, I like KO's coding style better, because I was doing it that way before KO even existed.

  • @feketegy, same.

    What is the problem? Nobody is forcing you to use them. Whilst I disagree with a number of the requirements in the standards, I think it is a great idea.

    The problem is it's written by people who aren't knowledgeable about how basic things work/are-suppose-to-work and have very little consideration on how much damage they are doing to (in this case) code readability. According to their little example there I'm suppose to have a controller X in \something\Controller\X and a model X in \something\Model\X where something is not even a unique identifier, but something stupid like "Vendor", "Application" etc (way to fail the basic requirement of "namespace"). X in this case is completely ambigous in a proper context (is it the controller? is it the model?).

    They then apparently don't know there are <?/?> tags.

    And then you got the whole "constants need to be UPPERCASE" issue. First of all, this whole constant/non-constant problem only applies to functional programming and the heavy use of globals. It's not "constants should be UPPERCASE" but rather "globals should be UPPERCASE". There's very little value in OOP since fundamentally you're doing a lot of information hidding so their use is very limited in scope, and also you're never going to use globals, outside of classes. Given classes (properly implemented) should not expose implementation details such as silly things like "public attributes" (we don't have package scope in PHP so it makes absolutely no sense), the only time you'll see Some_Class::something, it's always going to be a constant. You might think they're very inconsequential but really they aren't, besides being very hard to write, when you start going into really long ones (ie. 3+ words) they become really hard to read too.

    Moving on...

    The term "class" refers to all classes, interfaces, and traits.
    

    No it doesn't.

    A class is managing complexity allowing you adapt quickly on requirement changes.

    A interface is a contract between classes allowing to abstract implementation.

    A trait is simply a mechanism of sharing a implementation.

    For example, let's take a class Animal and a class Person. Even though Person shares some methods with animal: eat, sleep, etc, it also has a lot more methods that do not apply to an animal, ie. think, talk, etc. In this case having Person extend Animal is technically wrong, since whenever you extend something the idea is you are a specialized version of that which you extend, not share stuff with it. The POINT of OOP is you do not add complexity! That's why the parent class is also usually refer to as the super class, as in it does more. In cases like this you just want some of the behavior (or trait) and potentially want the Person class to implement an interface with said common methods. That way you have a DRY implementation, and also very little complexity since you won't have cases of managing chiken, people and fish, or other nonsensical situations.

    Regarding the whole camel case, brace style etc. The recommended way is to write in the common style, for your code base. So if you're writing some C and some javascript and some something else, it's best to find the common style between them instead of having a style for each one. Hence the whole idea of actually having a forced style is quite counter productive. In addition since some languages are much much better at lower tab widths, you want tabs 99% of the time.

  • @Akki So you're saying that animals can't think :))

  • According to their little example there I'm suppose to have a controller X in \something\Controller\X and a model X in \something\Model\X where something is not even a unique identifier, but something stupid like "Vendor", "Application" etc (way to fail the basic requirement of "namespace").

    "Vendor" means use your own vendor prefix eg. "Kohana", "Fuel", "Akki" not literally use "Vendor".

    They then apparently don't know there are <?/?> tags.

    They know they exist, that's why they require code to use a subset of the available opening tags. This is because the other tag forms can be disabled in php.ini.

    The term "class" refers to all classes, interfaces, and traits.

    It's just defining the term "class" for that subsection of the document rather than explicitly saying "classes, interfaces and traits" all over the place.

  • Does anybody actually use a tab-width of anything other than 4? Just curious since everyone keeps on mentioning the freedom of choosing a different value...

  • Personally I always use 2, mainly because I've often had to work on small screens and it's become a habit. If's line up better with 4 spaces, but else's line up better with 2, etc. Completely trivial, of course ... but some people care about these things. Choice is a good thing if it doesn't impact anyone else's work.

    Navigating through tabs is also easier if you don't have an editor that recognises e.g. 4 spaces as one indent on left/right etc.

  • I've seen 3 spaces, 2 spaces, 1 tab as 4 spaces (my personal choice too).

    I don't know why is this an issue with PSR-x... Just use tabs, and in any half decent editor you can set the spaces for 1 tab.

  • doesn't that make the 80 char limit confusing? if your tabs are set to 1 space, the line looks like it's 77 characters long! just saying ;)

  • Line lengths are one problem with using tabs. Since switching to ruby, I've been using spaces. It really doesn't matter.

  • By "switching to ruby" you mean using it on the side? :)

  • Um. No. :)

  • So who's in charge of kohana now?

  • I'm still involved. I'm still writing php on the side. I'm finishing AM v5 now.

  • Well, for line lengths just set your editor to compensate - change number of columns, move vertical rule, whatever.

  • That doesn't work ;) 80 is 80 spaces. A tab is x spaces. Set tab width to 75 (extreme example), all your lines are too long now.

  • The 80 character limit is exaggerated in importance.

    It's so easy to go over it once you just nest 4-5 if/for/etc's in some complicated logic and be so deep it doesn't even matter anymore. If your project doesn't give a damn about it, there's no reason to use spaces. With regard to different lengths: 4 PHP common, 4-8 C++ people, 4/2/3 ruby, etc And if you think it doesn't help, think about working on a project with 8 space indentation... fun fun fun. :)

    "Vendor" means use your own vendor prefix eg. "Kohana", "Fuel", "Akki" not literally use "Vendor".

    The second part in their example is still wrong though. Every component of a namespace should be a unique identifier; the 2nd, 3rd segments are only more loose because they just have to be unique in the name space defined by the previous segments.

    You do not skew part of the class name into the namespace. The 2nd and 3rd segments aren't code candy, and it makes no sense to use them as such as it makes the class ambiguous.

    It's just defining the term "class" for that subsection of the document rather than explicitly saying "classes, interfaces and traits" all over the place.

    Yeah read that part in a hurry. My bad. I retract what my complaint on that one issue; though I would expect of a "standard" not to be so cheap on words.

  • It's so easy to go over it once you just nest 4-5 if/for/etc's in some complicated logic and be so deep it doesn't even matter anymore.

    From the linux coding style guide:

    The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

  • From the same document:

    Outside of comments, documentation and except in Kconfig, spaces are never used for indentation.

  • @zombor

    The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

    Screwed how. I agree at over a certain number it's hard to read and you should just split an inner loop/if into a function but until that point it's much more readable to have it all in one nice block. Especially when the function only extends outwards and is otherwise very short.

  • Well I prefer tabs over spaces but both work I guess. But I like to be able to set my own indentation.

  • Screwed how.

    The point is in most cases, if you've gone past 3 levels of indentation, your method probably does too much, and should be refactored.

    and is otherwise very short.

    Why do you need more than 3 levels of indentation for a "very short" method?

  • My method could be 1000 lines long and less than 3 levels of indentation :)

    I guess I'm screwed anyway :) Saying that more than 3 levels of indentation is complicated code is just too naive...

  • My method could be 1000 lines long and less than 3 levels of indentation :)

    Yep, it could. So? There's no rule that says "only a method with more than 3 levels of indentation is the only kind of method that can be complicated or should be refactored". It's simply a logical guideline on what should be refactored because it is probably too complicated.

    Saying that more than 3 levels of indentation is complicated code is just too naive...

    How so? In most cases, I find it to be true. Remember, it's a guideline not a law of the universe.

    A method that has more than 3 levels of indentation is probably hard to read, probably hard to understand, so it should be refactored. A method that is 1000 lines long is probably hard to read, probably hard to understand, so it should be refactored.

  • @zombor

    Why do you need more than 3 levels of indentation for a "very short" method?

    Very complicated logic, typically requiring either maintaining some sort of state variables or performing various operations in specific order to get to the result. Hence why I said splitting it up into "helper functions" is just going to make things more complicated.

    it's a guideline not a law of the universe

    Then treat it as a guideline =P

    A method that has more than 3 levels of indentation is probably hard to read, probably hard to understand, so it should be refactored.

    I understand what you're saying because I apply it plenty, but I find methods that are overly split up (but "do just one thing") to be harder to read because you have to move though functions. Especially when those are just inner blocks and not even for the sake of keeping it DRY. Logic conditions being the exception because it's very easy to deduce the meaning from the function name with out even looking at how the actual condition was written as.

    Screens are also not 600px wide anymore... so I believe this to be very much hear-say.

  • People don't forget that most of the time you don't need indentation:

    function example($variable, $variable2)
    {
        if ($variable === TRUE)
        {
            if($variable2 === FALSE)
            {
                return TRUE;
            }
        }
    
        return FALSE;
    }
    

    vs

    function example($variable, $variable2)
    {
        if ($variable === TRUE)
        {
            return FALSE;
        }
    
        if($variable2 === FALSE)
        {
            return FALSE;
        }
    
        return TRUE;
    }
    

    Please remember that this is an example.

  • Actually, in that case it's more desirable to just do...

    function example($variable, $variable2)
    {
        if (static::my_variable_test($variable, $variable2))
        {
            return false;
        }
        else # not my_variable_test
        {
           return true;
        }
    }
    

    my_variable_test now isolates the actual logic of the boolean expression and allows it to be as long as it needs to be and easily maintained.

    This however is an exception. Not to say the case where you can't happens more often (because it doesn't), but rather that when it happens you don't have this choice, because you have various states and other variables that need to mentaioned as well as shortcircuit conditions, etc.

  • @Akki it's no use to "fix" an example.....

  • Giving an example doesn't mean you can just say anything you want... feel free to correct mine if you find faults in what I said.

    Your example is a very rare corner case (for the whole indentation talk). When the function is so simple you just have return <insert-condition-here>; When you have extra work to do in it, isolating any (complex) condition logic in a function is better (...in the long run).

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion