Dienstag, 5. März 2013

NetBeans warning against multiple assignments in PHP

ETA: I originally thought that this warning came directly from PHP's E_STRICT setting, but later found out that it was actually a NetBeans warning. I have now updated the title and part of the content accordingly.

I have a test function (*) which contains the following code:


        $line = 'a,b,c';
        $delims = array(';', ',');
     
        $delim = $helper->determineDelimiter($line, $delims);
        echo " $delim/, ";
        echo "<br/>";

        $line = 'a;b;c';
        $delims = array(';', ',');
     
        $delim = $helper->determineDelimiter($line, $delims);
        echo " $delim/; ";
        echo "<br/>";


Now, NetBeans will complain about the re-assignment of $line and $delim.

While I totally understand and support the intention - multiple assignment to the same variable is a smell under most circumstances - it kind of makes me wonder. We're dealing with an imperative language here, local variables are essentially just junk that gets overwritten whenever we please (moreover, lots of core functions overwrite their parameters, but no-one complains about that). And on top of that very basic feature of an imperative language, we impose restrictions borrowed from the functional paradigm, to keep us from shooting ourselves in the foot.

It's not like one had a chance to turn this feature off for this one specific method, I guess?

I can't help finding this a little bit odd. Either the language does give me the chance to code as I please, and kill myself in the process, or it doesn't. Nobody expects assembler to warn you about arbitrarily increasing the instruction pointer, most likely blowing your program to pieces in the process. Having tons of little exlamation marks to the left of my code doesn't help me find the actual mistakes. It is only confusing me, nothing more. The IDE shouldn't add its own warnings on top of the warnings the language will produce... Actually, my original mistake in this posting resulted from me thinking that this was going on under the hood: NetBeans passes the text to a php process and evaluates the resulting warnings.

But alas, the good folks over at the NetBeans factory chose to be wiser than the PHP developers. I think that this was a mistake.




------------------------------------------------------------------------
(*) a very clumsy one, because I didn't get phpunit to run on my puter

2 Kommentare:

  1. Yeah I don't get that. If there was some command like "this is a NEW variable", then OK, if you do two of those, perhaps that calls for a warning (or perhaps not; perl doesn't warn in that case, to be honest I find that useful.)

    But in PHP there is no syntactic difference between "declare this new variable" and "assign a value to this existing variable".

    So I can imagine that the warning for the former (found in many languages) has been implemented as a warning for the latter.

    Either you're dealing with a pure functional language (which PHP is very not), or you're dealing with a language which deals with state. And if you're dealing with state, it's not a mistake deserving of a warning to issue an assignment statement!

    AntwortenLöschen
    Antworten
    1. Ah okay, I was actually wrong here. It's not a php E_STRICT warning, but a NetBeans warning. Which kind of moves the issue, but doesn't exactly solve it.

      It gets even funnier though:

      $a = 1;
      $a = 2;

      => Waring: You should only use one assignment (2 used)...

      if (true)
      $b = 1;


      if (true)
      $b = 2;

      => No warning. Well, obviously not, since expressions are not static.

      And, of course

      $ar = array();
      $i = 0;
      foreach ($ar as $a) {
      ++$i;
      }

      => No warning, for much the same reason as above.

      Fine and well, but it destroys the good intentions of the warning, because it can only warn you in the most basic case, in which you probably reassigned the variable on purpose, anyway. And it might lure you into a false sense of safety. Duh.

      Löschen