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
Be careful with this Kohana convention (AND vs &&) !
  • Kohana Conventions ( http://kohanaframework.org/3.2/guide/kohana/conventions ) recommends to use AND instead of &&
    You must be careful with that convention, because AND is not equals to &&, AND has lower precedence than && and has lower precedence than = too !
    So if you write something like this:

    $var = TRUE AND FALSE;
    //$var is TRUE !
    

    Probably this is not new for advanced developers, but I never used AND before adopting the Kohana conventions, I was always using && instead of AND because that's what I use in C++, AS3, and I thought they was the same thing.
    **Maybe you can add this warning to the conventions. **

    Regards !!!

  • For me, it is still faster to type && and || though

  • No offense meant, but Operator Precedence should be basic knowledge for all php developers. However a reminder for people that are new to php probably wouldn't be a bad idea.

  • You are right @Isaiah, but I learned PHP after C++ and I never noticed that difference.
    I thought it was just another weird synonymous in PHP for some type of compatibility, maybe with another developers who comes from another language (where && and || are not common), or just for readability.
    Even more, I don't understand why the Zend team did that, yes, you can save two parenthesis in some weird conditions with AND instead && that's wonderful and deserves the big confusion ( sarcasm = 0 AND 1 ).
    Do you know some example where is really useful to use "AND" instead of && ?

  • Do you know some example where is really useful to use "AND" instead of && ?

    AND is easier to read (in our opinion) than &&, and in most cases it does the same thing. There's been a thread on this already. Go read it.

  • @enridp, they actually make a lot of sense once you understand them. Also this isn't something special to PHP; Ruby, Perl, and I'm sure other languages also have AND/OR. Using AND/OR forces you to use parentheses in your code and this makes it much easier to read. For example if you are using AND you need to write if ($something = (operation AND operation) instead of if ($something = operation && operation. There is an interesting read on AND/OR that says it helps to think of them as control flow operators, not boolean operators. The bottom line is use parentheses and either one will work just fine 99.999...999% of the time.

  • Yes, here it is:
    http://forum.kohanaframework.org/discussion/9511/comparison-operations-coding-conventions/p1
    I understand what you said in that discussion @zombor, but I think in this particular case is not only about readability (which is obviously subjective, but that's OK).

    Pretty much all of the conventions are to increase readability, in our opinion.

    I mean, you are forced to use extra parenthesis or use && in some situations because AND it's a really weird operator.
    That should be taked into account in my opinion :P

    Anyway, I think I will back to my always faithful && :)

    I was trying to let my 2 cents, I opened a feature request here:
    http://dev.kohanaframework.org/issues/4279

  • @Isaiah, yes, that's a better reason, and that explains why AND and OR exists, thanks for sharing.
    Maybe that should be a convention too, always use parenthesis.
    Anyway I'm not a big fan of making an assigment inside an ìf even my IDE (Zend Studio) put a warning every time I do that.

  • @Isaiah, yes, that's a better reason, and that explains why AND and OR exists, thanks for sharing.

    Doesn't cover why you should use them however...

    Anyway I'm not a big fan of making an assigment inside an ìf even my IDE (Zend Studio) put a warning every time I do that.

    They are perfectly fine inside if. Just go into your editors options and disable the warning.

  • @zombor Same discussion, if people trip over this alot maybe you should let your ego float for once ;) AND imho isn't readable as && is :) it's just opinions! But if opinions don't sort things out you should always go with the one that has not got that much negative effects like AND

  • @nickobrien, exactly - it's all just opinions. In our (Kohana Devs) opinion AND is more readable, so we made it part of the kohana convention. Instead of changing because people don't understand how php works it would be better to educate them on it. A link in the userguide is an appropriate solution, changing the convention is not.

  • I think @Isaiah said it best earlier. If people are tripping up over the use of PHP operators then they really should be educating themselves to intricacies of the PHP language. Coming from another language and claiming it doesn't work the same way is a rather weak argument frankly. Kohana doesn't force people to use this convention in their code, unless they wish to contribute to the framework itself.

  • I tend to agree, while there's some decent arguments, it's not Kohana's job to teach you php syntax/intricacies.

  • What's more frustrating is the multitude of different standards employed by projects each with their own little twists. Personally it would make contributing much easier if projects reused existing standards. Take the Zend Framework standard, even though I don't consider it "correct", I would rather work consistently across many projects than be chopping and changing depending on what I'm working on. But that's just me.

  • @cs278 .. and while we're at it, everyone should use vim over emacs!

    While a single coding standard for all PHP projects would be nice, its just never going to happen.

  • @kiall I never said a single standard, that is unattainable.

  • Zend Framework conventions are awful anyway. They are not a good template. I know I'm totally bias, but Kohana's are almost perfect, with a few exceptions, like;

    if ($foo === TRUE)
    {
        // Correct
    }
    
    if (TRUE === $foo)
    {
        // Incorrect (but should be correct imho)
    }
    
  • @samsoir, if you think the last if is better (because i'ts safer) then you should say that is better to use && instead of AND.
    And you should say that is incorrect to use an assigment inside an if.
    why? because how @zombor said, the only arguments for Kohana conventios is readability.

  • @enridp I'm not bothered by either && or AND because I know how they work. Assignment inside an if statement makes perfect sense to me and I believe that my example is more readable than the current correct version.

    However, that is just my opinion. And the opinion of one does not necessarily influence the many. You should take heed from those words!

  • If you think if (TRUE === $foo) should be correct because it's more readable, then it's OK (it follows the rules for Koahana's conventions), but not if the reason to be correct is because it's safer (it protects against stupid errors when we are coding).

  • @enridp, I have to say I'm not too concerned either way, but just for the sake of it I'd mention that I think the two examples are different.

    if ($foo = TRUE) vs if ($foo === TRUE) is a typo. It's reasonable to have a coding standard that protects you from typos.

    if ($var = TRUE AND FALSE) vs if ($foo = TRUE && FALSE) is usage of entirely the wrong operator. I don't know that the coding standard needs to protect from correct usage of basic language structures.

  • but then you should avoid assignments in conditions. That's why IDE's like Zend Studio are putting a warning when you do that, because it could be a very common type, I mean:
    if ($foo = TRUE) vs if ($foo == TRUE)
    is the same type of typo than:
    if ($var = TRUE AND FALSE) vs if ($var == TRUE AND FALSE)
    so again, if you want to use if (TRUE == $foo) because it protects you from a typo. Then you should avoid assingments in conditions too, because it protects you from a typo too.
    But if you choose it just because it looks nicer, then you have the best argument ever proposed, how can we discuss about that? :)

  • @enridp, that whole argument is silly. The reason people like doing TRUE == $foo is because it's easy to accidentally only type one = when you meant to type two (or three) and hard to notice these errors. With && vs AND you only have problems when you don't understand how they work, using one over the other doesn't help with finding typos in your code.

  • Well, obviously my english is terrible :)

    First: if you read my posts again you will see that I never asked for a change in the conventions, even more, I opened a feature request (and this thread is tagged as feature request too) for adding a link or warning in the conventions (not for changing it!). I opened this just for adding my 2 cents, because I'm sure there are, or could be, more people who doesn't know the difference between AND and &&. Even more, I'm happy with that convention, because I never used AND before Kohana, so I learn something new thanks to that.

    Second: I asked just for curiosity (and probably learn something more) why you choose AND instead of &&. @zombor said the only reason was readability. That's OK, they are conventions after all.
    Then @samsoir commented about changing the convention for using if (TRUE == $foo).
    And I said if the reason for choosing if (TRUE == $foo) over if ($foo == TRUE) is protecting against a typo, then, following the same rule, you should add an extra convention for not using assignment inside a condition because it's vulnerable to the same typo.
    Even more, and thinking only in typo, if we give importance to this "typo protection", AND is better than &&.

  • Your English seems fine to me. Perhaps I just misunderstood what you were saying. My bad!

  • Then @samsoir commented about changing the convention for using if (TRUE == $foo).

    Actually, I was just showing my displeasure for that particular convention - not asking for it to change. A subtle, but important difference. ;)

  • I remember when we got a fight about the same question on IRC... The good, old times. :D

Howdy, Stranger!

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

In this Discussion