SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 33
  1. #1
    SitePoint Addict mgkimsal's Avatar
    Join Date
    Sep 1999
    Posts
    209
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    E_ALL reporting - good or bad?

    Hello:

    Recently started on working with a couple projects with another group of people who are adamant about error reporting levels being set to E_ALL. I think they will even do this in production.

    Having been doing PHP for years without this, it's a big upheaval in my routine. I'm looking for some real justifications from you guys. All I'm getting from this group is "it's better". They've only recently started PHP and are doing *many* weird things which go against the grain of PHP (I won't even mention them here for sake of time) but this E_ALL thing is starting to get to me.

    To kick this off, all the research I've done only comes up with "it's better because it catches possible variable name issues - $firstName being set but $firstname being returned, for example". That's about it. Seeing as how I *have never* had that problem (well, not for 4 years), it's a silly thing to wade through dozens of warnings about unitialized variables, and sillier to specifically initialize every variable before use (that's part of why PHP is good at being a rapid dev tool).

    Having said all this, I generally put most logic in objects. The object properties get initialized, so there's no problem there. And *generally* I'll write (or a colleague will) unit tests for those objects, which give a stronger indication of the utility of the code. The group I'm working with does no objects, and has actively discouraged me and my group from using objects (purportedly for 'speed' reasons).

    Anyway, my view on this is that you can spend an awful lot of extra developer time (which is expensive) trying to pre-initialize every variable you use as opposed for little (if any?) benefit. If the benefit is processor time, that's *much* cheaper than developer time, no?

    Someone enlighten me (or let the flames begin!)
    Michael Kimsal
    =============================
    groovymag.com - for groovy/grails developers
    jsmag.com - for javascript developers

  2. #2
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    +1

    I use error_reporting(E_ALL) all the time. Set it that way in the php.ini file. You can intentionally lower it in production programatically if desired.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  3. #3
    does not play well with others frezno's Avatar
    Join Date
    Jan 2003
    Location
    Munich, Germany
    Posts
    1,391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i use E_ALL during development and for production i go to '0' and use my own error-messages
    which were displayed to the user and a mail of that error sent to me (or webmaster).
    Same goes for mysql_error().
    That's simply because i don't want the user to see too detailed messages if there's a problem.
    We are the Borg. Resistance is futile. Prepare to be assimilated.
    I'm Pentium of Borg.Division is futile.Prepare to be approximated.

  4. #4
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I use E_ALL mainly because if I'm shipping code for other people to use, I want it to "work" whatever ini settings they have.

    Otherwise, it occasionally helps with typos that could slow me down e.g.

    PHP Code:
    <?php
    class Foo {
        var 
    $color 'blue';
        function 
    display() {
            echo 
    $this->colour;
        }
    }

    $foo = new Foo();
    $foo->display();
    ?>
    It that example it's easy to find the problem with or without E_ALL, but when you've got more complex code, it can help prevent head scratching.

    Agree the benefit of E_ALL is not so great. That said, for writing fresh code (as opposed to modifying a large app where E_ALL wasn't used), the only extra effort it causes me would typically be;

    PHP Code:
    if ( isset($_GET['action'] && $_GET['action'] == 'foo' ) {


    (before anyone says it, isset($_GET['action'] is faster than @$_GET['action'])

    As opposed to just;

    PHP Code:
    if ( $_GET['action'] == 'foo' ) {



  5. #5
    SitePoint Addict mgkimsal's Avatar
    Join Date
    Sep 1999
    Posts
    209
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm finding nested arrays to be a challenge (and a lot of extra useless code).

    if (isset($v['_attr'])) {
    if (is_array($v['_attr'])) {
    // foo
    }
    }

    rather than just if (is_array($v['_attr'])) { //

    $v['_attr'] IS NOT AN ARRAY (whether or not it's defined) so that should work.

    The other aspect of this is that generally the keys we're checking are lists of other data from some other set. There's not a lot of manual naming going on - just a lot of array manipulation. If I'm checking is_array($v[$name]) and it's not an array, that means $name is the wrong value, and since it's pulled from someplace else, there's going to be a lot of other problems simultaneously.
    Michael Kimsal
    =============================
    groovymag.com - for groovy/grails developers
    jsmag.com - for javascript developers

  6. #6
    SitePoint Addict mgkimsal's Avatar
    Join Date
    Sep 1999
    Posts
    209
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Speed

    PHP Code:
    <?
     
     $array
    ['fooo'] = '';
     echo 
    microtime()."\n";
     if (isset(
    $array['foo']) && (is_array($array['foo']))) {
         echo 
    "ww";
     }
     echo 
    microtime()."\n";
     if (
    is_array($array['foo'])) { 
         echo 
    "ww";
     }
     echo 
    microtime()."\n";
     
     
    ?>
    The second method is faster.

    0.71023600 1075910342
    0.71111000 1075910342
    0.71159700 1075910342

    First method is .9 milliseconds. Second method is .4 milliseconds.
    Granted, it's not a lot of time difference, but if you're doing thounsands of loops, that adds up. Also, it's *more typing*. So, more typing, slower code. What's the benefit again?
    Michael Kimsal
    =============================
    groovymag.com - for groovy/grails developers
    jsmag.com - for javascript developers

  7. #7
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by mgkimsal
    I'm finding nested arrays to be a challenge (and a lot of extra useless code).
    I have E_ALL on because I have made lot's of mistakes in the last 4 years . Another example is that It reminds me that when I try to delete a file that is not there, I know something very unexpected happened that I should have forseen.

    The excessive use of arrays would seem to be due the lack of objects. If a development team has the OO skills, it is insane not to leverage them. Anyone who quotes "performance" sure better have cost/benefit figures to demonstrate that the extra microseconds saved (if measurable) have added more value than developer time lost. Sounds like a (mis)manager has a bee in their bonnet about something.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  8. #8
    SitePoint Addict mgkimsal's Avatar
    Join Date
    Sep 1999
    Posts
    209
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The dev team mostly *doesn't* have OO skills. We do (working with their group) but they don't like them. It feels like a big mess right now. I've kinda answered my own question to some extent. The E_ALL thing is a few people here trying to demonstrate 'good developer skills' to others ("turn on your reporting to catch 'errors'!"), but actively promoting many other bad application design (bad on a large scale from a long-term maintenance standpoint).
    Michael Kimsal
    =============================
    groovymag.com - for groovy/grails developers
    jsmag.com - for javascript developers

  9. #9
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The second method is faster.
    no , the second method is nearly 3 times slower , you can't test the speed of the 2 operations in the same script (swap the order to see what I mean)

    PHP Code:
    <?php
    function getmicrotime(){ 
     list(
    $usec$sec) = explode(" ",microtime()); 
      return ((float)
    $usec + (float)$sec); 
     }
    $time_start getmicrotime(); 
    $array['fooo'] = '';
    for( 
    $x=$x<10000 $x++ ){
     if ( isset( 
    $array['foo'] ) && ( is_array$array['foo'] ) ) ) {
      echo 
    "ww" ;
     }
    }
    /*
    if (is_array($array['foo'])) { 
        echo "ww";
    }
    */
    $time_end getmicrotime();
    $time $time_end $time_start 
    echo 
    $time "
    ?>
    run that a few times substituting the 2 methods to see a clearer result.

    Whenever PHP has to stop and think & check if indeed an error exists it uses up cycles , stopping or supressing all errors simply makes your script run faster as PHP has less work to do, for the effort involved here that can only be good ?

  10. #10
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    to be balanced if $array['foo'] does indeed exist then the more verbose check is slower , however the difference in speed is minimal compared to the difference when false.

    So to be fair one may assume that mostly the test is expected to be true more often than false , so if you expect say 10,000 positives for every negative then you would win out that way, so perhaps my comment `that can only be good` is subjective from a performance standpoint ?

  11. #11
    SitePoint Addict mgkimsal's Avatar
    Join Date
    Sep 1999
    Posts
    209
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I stand corrected.

    Didn't check both ways (one first, then the other). Thanks. Still seems a bloody waste.
    Michael Kimsal
    =============================
    groovymag.com - for groovy/grails developers
    jsmag.com - for javascript developers

  12. #12
    SitePoint Addict mgkimsal's Avatar
    Join Date
    Sep 1999
    Posts
    209
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by firepages
    so perhaps my comment `that can only be good` is subjective from a performance standpoint ?
    From a pure performance standpoint, yes, it's good. My point in all of this is primarily developer time. My keystrokes take time, as do they combined keystrokes of many other people. More time = more money. It's more code to review on the whole, and serves very little purpose. Structured QA and unit tests would catch data errors resulting from mistyped variable names (there's a QA dept but no objects so unit testing is difficult).

    So, if this practice eats up a few dozen developer hours over the course of a few months (reviews, rewrites, etc) just to make things 'work' in an E_ALL environment, which really only serves to make things slightly faster, is it worth it? As I said (or maybe didn't) we're pushing for real data integrity testing procedures, but right now E_ALL-compliant code is the only 'real' thing people are doing, and it's a huge waste of time (did I say I think it's a waste?)
    Michael Kimsal
    =============================
    groovymag.com - for groovy/grails developers
    jsmag.com - for javascript developers

  13. #13
    Super Ninja Monkey Travis's Avatar
    Join Date
    Dec 2001
    Location
    Sioux City, Iowa
    Posts
    691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Fighting speed vs. development time is like fighting over religion in most cases. It's almost never that much of a speed increase or that much of a developer slowdown.
    However, I use E_ALL because of the warm feeling I get knowing that my code doesn't create any E_NOTICE errors.
    Travis Watkins - Hyperactive Coder
    My Blog: Realist Anew
    Projects: Alacarte - Gnome Menu Editor

  14. #14
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    yes keystokes take time, but you type them once and your server runs them literally millions of times , a few seconds typing (even if its an hour in total over a given project) seems a fair trade for that warm fuzzy feeling that Travis notes !

    In essence you are saying its OK to write less than perfect code (!and sometimes it is!) but I think that that should be a predetermined decision (for a given procedure/script) rather than a general practice.

    PS I probably have tens of thousands of lines of crap code myself ~ much of which will stay that way until the project is rewritten for some reason or other , but today I work with E_ALL for development and find that I hardly need to even think abut isset()'s & friends anymore as it becomes natural quite quickly (as did $_POST etc)

  15. #15
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I use E_ALL for development.
    I actually wish that PHP had a stricter mode that you could use where you actually had to declare you variables, like using "my" in Perl.
    Of course I know alot of PHP people would hate this.
    But I spent like twenty minutes the other day tracking a bug that
    went something like this:

    PHP Code:
    psuedo code:


    $error some_value;

    // later on down in my file
    $errror some_other_value;

    // later on down in the file
    doSomethingWithError($error); 
    I can't remember the exact problem, but basically because all variables "were" initialized, I didn't get any notices with E_ALL.



    Of course I know I'm probably the only PHP person on the planet who would like to see:

    PHP Code:

    my $error

    --ed

  16. #16
    does not play well with others frezno's Avatar
    Join Date
    Jan 2003
    Location
    Munich, Germany
    Posts
    1,391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    one of the problems with PHP that it is too loose and forgiving with non-declaring and/or wrong used variables & Co.
    That was one of the first things i had to learn in C and that helps me now
    We are the Borg. Resistance is futile. Prepare to be assimilated.
    I'm Pentium of Borg.Division is futile.Prepare to be approximated.

  17. #17
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by coo_t2
    Of course I know I'm probably the only PHP person on the planet who would like to see:

    PHP Code:

    my $error

    --ed
    There are two of us, actually. I used to program Perl, too. I always thought the inability to declare all variables was the one really stupid thing about PHP. But I have to admit that the number of bugs it causes is small, unless you let global variables float around all over the place. On the other hand, when you're used to my, you know it's very easy to do.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  18. #18
    SitePoint Zealot
    Join Date
    Aug 2002
    Posts
    178
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by coo_t2
    I use E_ALL for development.
    I actually wish that PHP had a stricter mode that you could use where you actually had to declare you variables, like using "my" in Perl.
    Of course I know alot of PHP people would hate this.
    But I spent like twenty minutes the other day tracking a bug that
    went something like this:
    --ed
    Maybe E_STRICT then?

  19. #19
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by nucleuz
    Maybe E_STRICT then?
    That would be a good place to put it. Has anyone proposed the idea that variables must be declared under E_STRICT ? The only thing mentioned in that thread that E_STRICT will do is warn about using deprecated functions. Unless I missed something?

    --ed

  20. #20
    SitePoint Zealot
    Join Date
    Aug 2002
    Posts
    178
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by coo_t2
    That would be a good place to put it. Has anyone proposed the idea that variables must be declared under E_STRICT ? The only thing mentioned in that thread that E_STRICT will do is warn about using deprecated functions. Unless I missed something?

    --ed
    Well:
    Not using var for member variables but moving to PPP
    was mentioned in the first post ( for classes - use ppp instead ), but I haven't gone through all threads yet.

  21. #21
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by nucleuz
    Well:
    was mentioned in the first post ( for classes - use ppp instead ), but I haven't gone through all threads yet.
    PPP means public/private/protected right?
    That's the only reference to declarations in the threads I seen.
    BUt it would be a start if you had to declare the variable with public/private/protected before using it.

    --ed

  22. #22
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    E_ALL isn't just helpful it's absolutely essential for development - at the same time you should log errors or turn down on a live site.

    The danger with uninitialised variables is if register globals is on. Anyone can set the var to any value they like, eg:

    PHP Code:
    if($access_level == 'admin')
    {
        
    grantHackersAdminAccessHellThey'reNotMyCreditCards();

    (Conversely, if you don't have any uninitialised vars, reg globs on/off doesn't matter - anything declared via GET gets overwritten by your own values).

    You've got involved with a very bad crowd my friend .

  23. #23
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Has anyone proposed the idea that variables must be declared under E_STRICT
    nope , I think that may come under the heading 'heresy' , as would typing etc

    if you develop with E_ALL then you either conform or have a page full of notices , enforcement itself ? ... I dont see how declaring my $error would help in the code you post (I appreciate that that was not the exact code)

  24. #24
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by firepages
    I dont see how declaring my $error would help in the code you post (I appreciate that that was not the exact code)
    Because I wouldn't of been able to use the typo'd variable without declaring it first.

    example perl script:

    Code:
     
     use strict;
     
     my $error = 'this is the real variable';
     
     $errror = 'this is assigning to a typo which I think is $error';
    WHen I try to run this Perl won't even compile it, it spits this
    message out at me:


    "Global symbol "$errror" requires explicit package name at noname1.pl line 5.
    Execution of noname1.pl aborted due to compilation errors."


    --ed

  25. #25
    SitePoint Guru
    Join Date
    Feb 2002
    Posts
    625
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Honestly i am suprised to hear that people develop without E_ALL. During development it does't hurt, and initializing variables is not something which you feel is a pain in the ***, but it simply good practice.


    Checking if a variable is set etc.. can be done in a standarized way, resulting in a lot less typing.

    Note: The following class is from someone who mailed it on the php mailing list, and has been mentioned in the Tips & Tricks section of a well known PHP magazine (not sure if i am allowed to mention the magazines name, so i'm not going to...).

    PHP Code:
    <?php
    /* Helper class for retrieving
       POST GET REQUEST SESSION and COOKIE
       variables */
    class req
    {
        
    /*
         * We don't need a constructor here
         *
         * This set will return the variable if it is set
         * or a default value if supplied, otherwise false.
         * $variable_name is the name as a string.
         * $default can be any type except a reference.
         */
        
    function get($variable_name,$default=false)
        {
            return (isset(
    $_GET[$variable_name]))?
            
    $_GET[$variable_name] : $default;
        }
        function 
    post($variable_name,$default=false)
        {
            return (isset(
    $_POST[$variable_name]))?
            
    $_POST[$variable_name] : $default;
        }
        function 
    request($variable_name,$default=false)
        {
            return (isset(
    $_REQUEST[$variable_name]))?
            
    $_REQUEST[$variable_name] : $default;
        }
        function 
    server($variable_name,$default=false)
        {
            return (isset(
    $_SERVER[$variable_name]))?
            
    $_SERVER[$variable_name] : $default;
        }
        function 
    session($variable_name,$default=false)
        {
            return (isset(
    $_SESSION[$variable_name]))?
            
    $_SESSION[$variable_name] : $default;
        }
        function 
    cookie($variable_name,$default=false)
        {
            return (isset(
    $_COOKIE[$variable_name]))?
            
    $_COOKIE[$variable_name] : $default;
        }
        
    /*
         * This set will return TRUE if the variable is set
         * and is equal to the supplied comparison value
         * otherwise returns false.
         * $variable_name is the name as a string.
         * $compare can be any type except a reference.
         */
        
    function getEQ($variable_name,$compare)
        {
            return (
    req::get($variable_name) == $compare)?
            
    true false;
        }
        function 
    postEQ($variable_name,$compare)
        {
            return (
    req::post($variable_name) == $compare)?
            
    true false;
        }
        function 
    requestEQ($variable_name,$compare)
        {
            return (
    req::request($variable_name) == $compare)?
            
    true false;
        }
        function 
    serverEQ($variable_name,$compare)
        {
            return (
    req::server($variable_name) == $compare)?
            
    true false;
        }
        function 
    sessionEQ($variable_name,$compare)
        {
            return (
    req::session($variable_name) == $compare)?
            
    true false;
        }
        function 
    cookieEQ($variable_name,$compare)
        {
            return (
    req::cookie($variable_name) == $compare)?
            
    true false;
        }
    }
    Now you can instead of doing the following:

    PHP Code:
    if(isset($_GET['foo']) && $_GET['foo'] == 'bar')
    {
        
    //process $_GET['foo']

    simply do this

    PHP Code:
    if(req::getEQ('foo''bar'))
    {
        
    //process $_GET['foo']

    Initializing variables also tends to lead to more readable code, but then again, your mileage may vary, and all of this is just my humble oppinion


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •