|
|
thoroughly-arbitrary bias Saturday, February 25 2006
I spent most of my life today trying to implement a good system for allowing features to be added to and subtracted from a product in an online store. I'm continually amazed by what can be achieved with the use of an HTML IFRAME. It's like a poor man's AJAX. With a tool designed to edit database tables, an IFRAME is the perfect way to implement subtools, such as those that edit relationships between tables. You make the edit, the IFRAME reloads, but the mother page itself stays unchanged.
Much of what I was doing involved coming to an understanding with an open source shopping cart application such that I could modify it to suit my needs. It says something about my maturity as a developer that I've been finding the open source code to be mediocre and inconsistent. By inconsistent, I mean that some parts of the code take advantage of libraries while other parts act as though those libraries don't exist and re-implement the functionality of those libaries in multiple places. Some of what I did today was consolidate long blocks of illegible HTML-mixed-with-PHP into tidy properly-nested functions.
At this point I'd like to point something out stylistically about the coding of C-style languages (which includes Java, Javascript, and PHP). I find lots of people write such code this way:
function tep_draw_pull_down_menu($name, $values, $default = '', $parameters = '', $required = false) {
$field = '<select name="' . tep_output_string($name) . '"';
if (tep_not_null($parameters)) $field .= ' ' . $parameters;
$field .= '>';
if (empty($default) && isset($GLOBALS[$name])) $default = stripslashes($GLOBALS[$name]);
for ($i=0, $n=sizeof($values); $i<$n; $i++) {
$field .= '<option value="' . tep_output_string($values[$i]['id']) . '"';
if ($default == $values[$i]['id']) {
$field .= ' SELECTED';
}
$field .= '>' . tep_output_string($values[$i]['text'], array('"' => '"', '\'' => ''', '<' => '<', '>' => '>')) . '</option>';
}
$field .= '</select>';
if ($required == true) $field .= TEXT_FIELD_REQUIRED;
return $field;
}
This is the way I prefer to code:
function TableDropdown($strDatabase, $strDefaultTable, $strFieldName)
{
$sql=conDB();
$out="<select name=\"". $strFieldName . "\">\n";
$out.="<option value=''>none</option>\n";
$tables = $sql->showtables(array("db" => $strDatabase));
asort($tables);
foreach ( $tables as $k=>$v )
{
$tablename=$v;
$strSel="";
if ($tablename==$strDefaultTable)
{
$strSel="selected";
}
$out.="<option " . $strSel . ">" . $tablename . "</option>\n";
}
$out.="</select>\n";
return $out;
}
I prefer the curly-quotes to stand alone on their own lines and at matched indentation, both entering their "zone of impact" and also leaving it. That way I can quickly scan through the code and see the different zones of impact, places where a for loop is doing its work or where an if statement has blocked access to an $intVal equal to "". It's probably possible to see the zones of impact in the indenting of the first example, but the opening curly quotes are always lost to me with that style and I tend to make errors when I edit it. Still, much of code writing comes down to style and it's very easy to have an unshakeable and thoroughly-arbitrary bias, and then to find code that violates your personal standards illegible or even amateurish. But we all came from somewhere; at least I'm no longer writing code that looks like this:
document.write();
function tohex(i) {
a2 = ''
ihex = hexQuot(i);
idiff = eval(i + '-(' + ihex + '*16)')
a2 = onehex(idiff) + a2;
while( ihex > 16) {
itmp = hexQuot(ihex);
idiff = eval(ihex + '-(' + itmp + '*16)');
a2 = onehex(idiff) + a2;
ihex = itmp;}
a1 = onehex(ihex);
return a1 + a2 ;}
function hexQuot(i) {
return Math.floor(eval(i +'/16'));}
function onehex(i) {if(i==0) {
f='0' } else {if(i==1) {f='1'} else {if(i==2) {
f='2'} else {if(i==3) {f='3'} else {if(i==4) {
f='4'} else {if(i==5) {f='5'} else {if(i==6) {
f='6'} else {if(i==7) {f='7'} else {if(i==8) {
f='8'} else {if(i==9) {f='9'} else {if(i==10) {
f='A'} else {if(i==11) {f='B'} else {if(i==12) {
f='C'} else {if(i==13) {f='D'} else {if(i==14) {
f='E'} else {if(i==15) {f='F'}}}}}}}}}}}}}}}}return f}
//the next function is entirely the creation of the Gus!
function sineline(width, freq, greenvar, bluevar) {
var count=0;
document.writeln("<center><table border=0 cellspacing=0 cellpadding=0>");
while(width>count) {
document.writeln("<td bgcolor=" + tohex(Math.abs(256*Math.sin(count/freq))) + tohex(Math.abs(256*Math.sin(count/freq+greenvar))) + tohex(Math.abs(256*Math.sin(count/freq+bluevar))) +"><i[REDACTED]mg sr[REDACTED]c[REDACTED]=[REDACTED]../graphics/blank.gif width=3 height=22></td>");
count++;};
That was some of the first C-style code I ever wrote, in Javascript, back on November 18, 1997. Judging from the boasting near the end, the only part I actually wrote all by myself was that last function ("sineline"). Here you can see it being called 100 times in a javascript for loop, something that would have killed any browser available in 1997.
For linking purposes this article's URL is: http://asecular.com/blog.php?060225 feedback previous | next |