Keith Devens .com
Keith Devens .com |
Monday, October 6, 2008 | |
| Never ascribe to malice, that which can be explained by incompetence. – Napoleon Bonaparte | ||
|
| ← mod_rewrite, SCRIPT_NAME, and PATH_INFO | Awww.... → |
Sparticus (http://iamsparticus.co.uk) wrote:
Elling wrote:
It depends...
I think, as long as you're not tight on resources, then code readability should be key. I often find myself writing things out instead of trying to compress it as much as I can.
Having readable code can be key when it comes to discovering bugs...
Keith (http://keithdevens.com/) wrote:
The second one is more readable. It's just one line instead of 5, and your intent is immediately clear. Remember this great quote by Dijkstra:
If we wish to count lines of code, we should not regard them as lines produced but as lines spent.
Elling wrote:
Well... Dijkstra talks about algorithms when he says that. And then it makes sense. In an algorithm where time or CPU cycles is an issue, then it's clearly an advantage to spend as few CPU instructions as possible.
But in all other cases, I personally think readability should be key.
In your particular case, it could be that the two examples are of equal readability, or maybe in some cases people will find the second example more readable... I don't know.
My own policy when programming is to keep things simple; usually do only one operation per line, and keep things orderly and logically separated.
I sometimes work with code where the author has spent much time to cram as many operations as possible into one line. And often that makes the code more difficult to figure out. If there's one operation per line, or maybe two... then in my experience it usuallty adds to the readability of the code.
Just my two cents... 
horaciod (http://blog.codigophp.com) wrote:
another way to write this more " readable " for me
$baz = ($foo==$bar)?true:false ;
ya !!
is not perfect but cpu cycles are cheapest than programmer salary
Scott Johnson of Feedster (http://www.feedster.com/blog/) wrote:
Hm.... I find that I'm in big disagreement here. Yes its shorter. Yes it may be more elegant but ... OY VEY.
The big question here that seems to be being ignored is what are your development staff like and will they get it? If the code will only be touched by you, do whatever you like. But unless that's either used universally so people always see it and know it, its going to be a maintenance problem.
Trust me I've had as many as 45 engineers as indirect reports (4 to 5 teams) and that one is going to be an issue.
Yes its one line but if you add this:
/*
Compare foo and bar and set appropriately
You just added 3 and I wouldn't feel comfortable with that line without it. Yeah that may be me but organizational life cycle of code is a really big deal. The person who follows in your footsteps isn't stupid -- but they aren't you either. Keep that in mind.
Aggelos wrote:
Reminds me of C.
Keith (http://keithdevens.com/) wrote:
Yep. I use PHP syntax a lot because that gives me syntax highlighting I gotta stick in some other highlighters.
Sparticus (http://iamsparticus.co.uk) wrote:
For those who say the first is more readable: Comments. Comments add practically zero to processing speed, so the code is still faster, shorter and more elegant.
Keith (http://keithdevens.com/) wrote:
I don't know why people are focusing on processing speed so much. This is such a micro-optimization that discussion of efficiency seems pretty silly.
The main plus for me is that it's much shorter and more elegant. It may not seem like this idiom is clear given the example with $foo, $bar, and $baz above. But here's a really simple example that shows that it can be easily readable:
Thursday, July 8, 2004
Permalink
<?php
$logged_in = ($user == $_REQUEST['user'] and $pass == $_REQUEST['pass']);
?>
One of the ways I think about it is that it's assigning the value (which is boolean) of that expression. It's exactly the same as if you'd said "$baz = foo($bar)" but it's with a logical expression rather than a function call.
Elling wrote:
Agree.... There are not any big problems with these two examples that you post. I just don't think that the short versions are that much to be prefered over the long versions.
I think elegance is nice. But I also think that elegance often gets in conflict with readability.
If faced with the choice between a multi-line boolean expression and a couple of nested if blocks, I usually go with the nested if blocks.
But... this probably is about taste too... So, again, I'm just saying what I personally think is the better approach.
Alan Green (http://www.cardboard.nu) wrote:
You are not alone
http://cardboard.nu/blog/2003_05_30/tips_for_using_java_booleans.html
http://cardboard.nu/blog/2003_06_06/a_boolean_coding_gem.html
Dave Edelhart (http://www.manateebay.com) wrote:
Sometimes its a good idea to USE cpu cycles, so that you have something to optimise later on. Also, why pass up an opportunity to write (php5 dependant) object code?
<?php
class are_they_equal
{
public function __construct($pVar_1, $pVar_2)
{
$this->set_var_1($pVar_1);
$this->set_var_2($pVar_2);
}
/************ PROPERTIES *****************/
private $loc_var1 = null;
public function get_var_1(){ return $this->loc_var_1;}
public function set_var_1($pValue){$this->loc_var_1 = $pValue; }
private $loc_var2 = null;
public function get_var_2(){ return $this->loc_var_2;}
public function set_var_2($pValue){$this->loc_var_2 = $pValue; }
/**************** METHODS *******************/
const ARE_EQUAL: 1;
const ARENT_EQUAL: 2;
public function are_equal()
{
if ($this->get_var_1() == $this->get_var_2()
{
return self::ARE_EQUAL;
}
elseif (!($this->get_var_1() == $this->get_var_2()))
{
return self::ARENT_EQUAL;
}
else
{
return 'A GIANT HOLE IN SPACE TIME HAS RENDERED
BOOLEAN LOGIC INVALID. SELL YOUR TECH STOCKS NOW.';
}
}
public static function test_equality($pVar_1, $pVar_2)
{
$tester = new are_they_equal($pVar_1, $pVar_2);
$out = $tester->are_equal();
unset($tester);
return $out;
}
}
?>
Feel free to post a comment below. Please see my comment policy.
Formatting Rules (No HTML):
Generated in about 0.121s.
(Used 8 db queries)
I stick my hand up here and say 'I've done that'! Thanks.