Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Unquoted string subscripts for arrays

2010-02-13
2013-05-30
  • Micah Stetson
    Micah Stetson
    2010-02-13

    A lot of new code has been committed with array references using unquoted string subscripts (e.g. $foo).  I know this is a traditional syntax for PHP, but it now generates a notice in the error log, so we should avoid it.  More info here:

    http://www.php.net/manual/en/language.types.array.php#language.types.array.donts

    Thanks,

    Micah

     
  • Fred LaPlante
    Fred LaPlante
    2010-02-13

    I am the likely cause of this 'problem'. I have been making a deliberate to elimimnate 'unneeded' concatenation and 'excess' quotes in array references unless a new element is being created.  The intent was to improve readability of the code.

    I see the point of the writer, but the code is simply going to get more obscure. For me this would cause me to create temp references to array elements so I can get complex statements into readable form. I have always felt that code that reads like plain language text is less error prone.

    Fred

     
  • Micah Stetson
    Micah Stetson
    2010-02-17

    I don't agree with the clarity argument for unquoted array subscripts.  Yes, you're saving two characters of typing (and reading) on every array subscript, but those two characters are required in every other language I can think of that has remotely similar syntax, including Python, which tries to minimize punctuation, and Perl which is pretty cavalier with its syntax rules.  JavaScript requires them too, so if we drop the quotes in PHP, we have to remember (on top of all the other differences) to keep them in JS.  Even within PHP, I have to keep potential problem cases in my head so I can avoid them:

    $foo['bar']; # always works
    $foo[bar]; # very likely to work
    $foo[BAR]; # a bit less likely to work
    $foo['bar baz']; # always works
    $foo[bar baz]; # never works
    $foo[number1]; # very likely to work
    $foo[1st]; # does this work?  I had to check the manual
    

    I think the savings in punctuation is outweighed by the cost in confusion.  Stick to what always works.  If you need to use temporary variables to make some code clearer, do so.

    The use of concatenation as opposed to double-quoted substitution is more about security and stability than style - I agree the concatenation is ugly and hard to read.  But I think I may have found a solution that is less ugly than concatenation, while still allowing us to write solid code.  Stay tuned.

    Micah

     
  • Micah Stetson
    Micah Stetson
    2010-02-17

    I am less-than impressed with the forum's BBCode and lack of preview.  Let me try that again…

    I don't agree with the clarity argument for unquoted array subscripts. Yes, you're saving two characters of typing (and reading) on every array subscript, but those two characters are required in every other language I can think of that has remotely similar syntax, including Python, which tries to minimize punctuation, and Perl which is pretty cavalier with its syntax rules. JavaScript requires them too, so if we drop the quotes in PHP, we have to remember (on top of all the other differences) to keep them in JS. Even within PHP, I have to keep potential problem cases in my head so I can avoid them:

    $foo; # always works

    $foo; # very likely to work

    $foo; # a bit less likely to work

    $foo; # always works

    $foo; # never works

    $foo; # very likely to work

    $foo; # does this work? I had to check the manual

    I think the savings in punctuation is outweighed by the cost in confusion. Stick to what always works. If you need to use temporary variables to make some code clearer, do so.

    The use of concatenation as opposed to double-quoted substitution is more about security and stability than style - I agree the concatenation is ugly and hard to read. But I think I may have found a solution that is less ugly than concatenation, while still allowing us to write solid code. Stay tuned.

    Micah

     
  • Micah Stetson
    Micah Stetson
    2010-02-17

    AAUUGHH!  I give up.  You're on your own with the code examples.  Here are the last two paragraphs:

    I think the savings in punctuation is outweighed by the cost in confusion. Stick to what always works. If you need to use temporary variables to make some code clearer, do so.

    The use of concatenation as opposed to double-quoted substitution is more about security and stability than style - I agree the concatenation is ugly and hard to read. But I think I may have found a solution that is less ugly than concatenation, while still allowing us to write solid code. Stay tuned.

    Micah