Re: [chiPHPug-discuss] "10 Advanced PHP Tips"

[matt d. <mm_...@ya...>]

The ternary sieve-

$r = false;
if(!$r)$r = (strpos($hub,"PRJ")>-1)? true:false;
if(!$r)$r = (strpos($hub,"EAI")>-1)? true:false;
if(!$r)$r = (strpos($hub,"ST")>-1)? true:false;
if(!$r)$r = (strpos($hub,"PR")>-1)? true:false;




________________________________
From: Jason Rexilius <ja...@ho...>
To: Chicago PHP User Group <chi...@li...>
Sent: Monday, March 30, 2009 12:47:28 PM
Subject: Re: [chiPHPug-discuss] "10 Advanced PHP Tips"

Number 3 is a very good discussion.  I think the right way to think 
about it is more than just initializing variables.  Its an engineering 
mindset or coding method.. Maybe call it "code to fail"..  But the 
principle is to make the exception the success case rather than the 
error case.  This is how good, secure input validation is done, how 
firewall rules are usually done, etc.

The basic example he provides:

  if (auth($username) == 'admin') {
      $admin = TRUE;
  } else {
      $admin = FALSE;
  }

is rewritten as:

  $admin = FALSE;
  if (auth($username) == 'admin') {
    $admin = TRUE;
  }

He then talks about more complex nesting of if/else, but thats not the 
point..  Its really about ensuring that only expected results survive 
the processing.

so in a function like:

function ValidateUser($UID) {

  $return=FALSE;

  // LOTS OF STUFF

  return $return;

}


If you forget something or something else changes in the environment its 
going to break rather than pass on unintended results..

He does touch on a good performance trade-off in exiting with a return 
as soon as a fatal test occurs, such as:

  if (isBlacklisted($username)) {
    return FALSE;
  }




Number 5 is one of my biggest annoyances with PHP developers in that A 
LOT of them drop the brackets..  Its one of a short list of things I 
would kill dead in the language.  ALWAYS USE BRACKETS!  There are a 
large number of reasons but auto-code processing and readability or top 
of the list..


I disagree with Ben and agree with authors on Ternary operators.  Terse 
is often bad for survivable code.  And ternary operators are not easily 
understandable by people knew to a language (which if your code survives 
for more than a couple of years will inevitably happen).  Terse is only 
good for people who are experts in both the specific application and the 
language when printing it out for a hand code review..  Coding 
conventions (no short tags, use curly brackets, no ternary operators, 
consisten case and naming conventions, etc. etc.) really help the poor 
intern who gets stuck doing maintenance on your code 5 years from now.


Number 8 is a bad thing as a rule of thumb.. Frameworks can be good and 
can also be bad..  Its really situation dependent..



Thanks for passing this on Neil!






Neil Rest wrote:
> This may not be all that advanced to everyone, but some of it's interesting.
> http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/
> 
> 
> (Sorry, I LIKE the ternary operator)
> 
> Neil
> --
> Nei...@rc...
> 
> Don't worry about what anybody else is going to do. The best way to 
> predict the future is to invent it.
>  -- Alan Kay
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> chiPHPug-discuss mailing list
> chi...@li...
> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss

------------------------------------------------------------------------------
_______________________________________________
chiPHPug-discuss mailing list
chi...@li...
https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss