With braces:
Code: Select all
<?php
IF ($p == 'news') {
$style2 = 'linkonnav';
} ELSE {
$style2 = 'linkoffnav';
}
echo '<font class="' . $style2 . '"><a href="main.php?p=news" class="' . $style2 . '">What''s New</a></font>';
IF ($p == 'online') {
$style2 = 'linkonnav';
} ELSE {
$style2 = 'linkoffnav';
}
echo '<font class="' . $style2 . '"><a href="main.php?p=online" class="' . $style2 . '">Online Books & Essays</a></font>';
?>
That's not meant to be a functioning script: I couldn't quite work out what you're logic is. For example I started to re-write it like this..
Code: Select all
<?php
IF ($p == 'news' OR $p == 'online') {
$style2 = 'linkonnav';
} ELSE {
$style2 = 'linkoffnav';
}
IF ($p == 'news') {
echo '<font class="' . $style2 . '"><a href="main.php?p=news" class="' . $style2 . '">What''s New</a></font>';
} ELSEIF ($p == 'online') {
echo '<font class="' . $style2 . '"><a href="main.php?p=online" class="' . $style2 . '">Online Books & Essays</a></font>';
}
?>
.. but couldn't see how $style = 'linkoffnav'; fits into the picture.
Braces around IF / ELSE make the code easier to read. I personally like to use whitespace (ie newlines) liberally as well for the same reason - I always add a newline after an IF or ELSE for example. The block of code inside the IF leg stands out much better - see m3rajk's question about the echo, above. One day you may be working in a team...
Upper case "IF" and "ELSE" rather than "if" or "else" possibly makes these items stand out better again enhancing readability.
I generally follow the PEAR coding standards
http://pear.php.net/manual/en/standards.php (apart from the "one true brace" style). Style might not seem to matter much when you are starting out (compared to scarier issues like inheritance or passing by reference) but it really does help to work out a good system. Easy-to-read code is much easier to work with.
Naming conventions are worth a mention in this regard. Descriptive names for variables and functions make life a lot easier - the code can almost read like pure English. For example $first_name is trivial to understand but $fn is not. Same applies to functions: listAddresses($string) or addlst($string)? In your own code it's not clear what $p stands for.
Commenting the code also helps to make it easier to understand. In a few months time you'll have forgotten all the script logic.
Note how I rewrote the strings with single quotes. Strings can be defined with either single or double quotes: $vars won't be parsed inside single quotes however so you jump out the string and concatenate with a "." (again some spaces help to make this more readbale but aren't essential). There are rare occasions when vars aren't parsed inside double quotes so I almost always take the time to concatenate a string. That doesn't sound quite right - but I have had the odd difficulty.
Also, notice how the syntax highlighting helps to flag up vars inside a string when you concatenate.
The advantage of single quotes are that you don't have to escape " in the html (eg in the <a href="etc">). It's also "faster" since a single-quoted string isn't parsed - but we're talking tiny fractions of a second so it doesn't make any real difference in practice. Don''t forget to escape any '' in the string: it''s easy to forget.
0.004 sounds fine. I normally get 0.2s - 0.5s or so on my creaky old 700 Duron desktop for forum browsing scripts or similar. The above script is of course much simpler - no db queries, BBcode processing etc.
The main speed issue with a page load on a live site is almost always going to be from graphics used in the page. As a rough rule of thumb, I'm happy if my scripts come in at under half a second (site search scripts excluded!) since that isn't going to create any noticable extra lag.
I've also found that with Zone Alarm on, scripts on my local server take almost ten times as long to run.