Code comments and execution time

Edit:


This thread was split from http://www.sitepoint.com/forums/gene...de-739087.html

-- ScallioXTX

Quote:

---

Originally Posted by deathshadow60

...
...
...
We aren't talking about compiled languages here where you can comment until blue in the face and it has zero impact on the binary.
...
...
...

---

I like PHP comments which are stripped from the final browser output of the generated HTML and CSS:

PHP Code:

---

// HTML
    <?php /* ===================== START BLOCK ======================== */ ?>
  <div id='new_left'>
      <?php if (! LOCALHOST) { ?>
      <br />
            <div class='advert_728x90'>
                <?php include 'adverts/_google_728x90.php'; ?>
            </div>
        <?php } ?>
        
        <div>
         ...
         ...
         ...
        </div> 
    <?php /* ===================== END BLOCK ======================== */ ?>


// CSS
<?php 
header("Content-type: text/css;charset:UTF-8");// http://www.barelyfitz.com/projects/csscolor/  
if(0){include'style.class_colors.php';} // http://www.typefolly.com/
if(1){include'style.style_fonts.php';}
if(1){include'style.style_dimensions.php';}
if(0){include'user_1.php';}// blood,tangerine,banana,ocean,grass,coal
if(1){include'user_2.php';}// blood,tangerine,banana,ocean,grass,coal
$bgg1='eee';
$cl2='900';
$cl3='090';
?>
body {background-color:#<?php echo $bf1;?>;color:#<?php echo $cl2;/* give this colour a whirl and see it is OK */ ?>}
#new_left {clear:both;width:88%;margin:1em auto;border:double 2px #<?php echo $clr3;?>}

---

Quote:

---

Originally Posted by John_Betong

I like PHP comments which are stripped from the final browser output of the generated HTML and CSS:

---

... and I HATE to break it to you, but /FAIL/ hard. REALLY HARD.

While you might not see comments in the output and bandwidth use, they DO take time to process on the server and as such slow down execution...

since php is an INTERPRETED language. Now, PHP is a two stage bytecode interpreter; which is to say that it does a byte-code style compile before executing, but the inital parse still takes overhead for comments which is why stupid pointless comments (like a row of nothing but asterisks) should be avoided... Certainly a code caching accellerator (APM, eAccellerator) helps by caching the byte-coded version, but if your code ends up flushed from the cache those comments will incur their penalty again.

Just because you don't see it in the HTML output doesn't mean they aren't incurring a penalty; in disk reads, in memory use, and in code parsing time on the server.

Because PHP isn't a compiled language EITHER... nor is Perl, nor is Ruby, nor is ASP.

Of course, switching in and out of parse mode like some rubbish "scripting" language doesn't help... there's a reason I consider any php code that does <?php ?> more than once to be a steaming pile of garbage.

Which is why your PHP samples from above are... freakishly bad.

Quote:

---

Originally Posted by deathshadow60

... and I HATE to break it to you, but /FAIL/ hard. REALLY HARD.

While you might not see comments in the output and bandwidth use, they DO take time to process on the server and as such slow down execution...

since php is an INTERPRETED language. Now, PHP is a two stage bytecode interpreter; which is to say that it does a byte-code style compile before executing, but the inital parse still takes overhead for comments which is why stupid pointless comments (like a row of nothing but asterisks) should be avoided... Certainly a code caching accellerator (APM, eAccellerator) helps by caching the byte-coded version, but if your code ends up flushed from the cache those comments will incur their penalty again.

Just because you don't see it in the HTML output doesn't mean they aren't incurring a penalty; in disk reads, in memory use, and in code parsing time on the server.

Because PHP isn't a compiled language EITHER... nor is Perl, nor is Ruby, nor is ASP.

Of course, switching in and out of parse mode like some rubbish "scripting" language doesn't help... there's a reason I consider any php code that does <?php ?> more than once to be a steaming pile of garbage.

Which is why your PHP samples from above are... freakishly bad.

---

I am aware and agree that processing on the server takes time and just included the repeated "===" for demonstration purposes only :)

A friend of mine used to argue the point about programming execution speed , cost of hardware and programming time to optimise code.

Fortunately I have a relatively fast server which manages to interpret and produce the browser output of eleven small images, Javascript Google Adsense, Google Analytics and quite a bit of text in under two seconds. The results can see on the the following link:

Pingdom Tools

If there is a faster way to produce HTML and CSS then I am always willing to learn, daily try to reduce the page speed and open to suggestions.

Quote:

---

Originally Posted by John_Betong

If there is a faster way to produce HTML and CSS then I am always willing to learn, daily try to reduce the page speed and open to suggestions.

---

I'm going to respond to this via PM in a few minutes as we're starting to drift OT... My bad :D

Quote:

---

Originally Posted by deathshadow60

Of course, switching in and out of parse mode like some rubbish "scripting" language doesn't help... there's a reason I consider any php code that does <?php ?> more than once to be a steaming pile of garbage.

---

So you use smarty I take it?

Mode switching has its place.

Quote:

---

Originally Posted by Michael Morris

So you use smarty I take it?

---

I'd sooner put a bullet in my head. :p

Though I hate templating systems of the normal sort -- most of the time I end up screaming "Oh for crying out loud, just let me write the blasted PHP"

Probably part of what I LIKE about skinning SMF.

All you have to do is look at the retard code example on the site for smarty -- no self respecting PHP developer would write GARBAGE like this:

Code:

---

<?php if(!empty($foo)): ?>
  <?php foreach($foo as $bar): ?>
    <a href="<?=$bar['zig']?>"><?=$bar['zag']?></a>
    <a href="<?=$bar['zig2']?>"><?=$bar['zag2']?></a>
    <a href="<?=$bar['zig3']?>"><?=$bar['zag3']?></a>
  <?php endforeach; ?>
<?php else: ?>
  There were no rows found.
<?php endif; ?>

---

The "smarty" version being:

Code:

---

{foreach $foo as $bar}
  <a href="{$bar.zig}">{$bar.zag}</a>
  <a href="{$bar.zig2}">{$bar.zag2}</a>
  <a href="{$bar.zig3}">{$bar.zag3}</a>
{foreachelse}
  There were no rows found.
{/foreach}

---

Which of course doesn't actually INCLUDE THE IF STATEMENT making the code vague/meaningless if it's automatically doing that.,... all to do this:

Code:

---

if (!empty($foo)) {
  foreach($foo as $bar) {
    echo '
      <a href="',$bar['zig'],'">',$bar['zag'],'</a>
      <a href="',$bar['zig2'],'">',$bar['zag2'],'</a>
      <a href="',$bar['zig3'],'">',$bar['zag3'],'</a>';
  }
} else echo '
      There were no rows found.';

---

With the <?php being once somewhere <on topic>way the **** **** up a the start of the program where it **** belongs</on topic> and the ?> occuring only once in the file <on topic>way the **** down at the ****** end</on topic> :D

I really laugh at the IDIOCY whenever I see dumbass nimrod coding like this particular part:

<?php if(!empty($foo)): ?>
<?php foreach($foo as $bar): ?>

What was that coder trying to accomplish other than writing garbage code with that nonsense?!? Of course I say that whenever I see IDIOCY like:

<a href="<?php echo $bar['zig']; ?>">

which goes hand in hand with the idiocy of trying to use double quotes to echo... which is rarely as useful as people think... and if you REALLY wanted to use double quotes

echo "<a href='$bar['zig']'>";

Would work too.... even if it does take longer to execute since you have the complex parser involved.

Card stacking is the only excuse/explanation of that code; using an example of piss poor coding techniques to make their convoluted bloated system of nothingness look more useful than it actually is.

Of course they try to sell that to you as reduced syntax time, failing to mention it's another layer of abstraction atop PHP that adds to the execution time defeating the entire POINT. :looko:

Off Topic:

This site really needs a facepalm smiley and a "crazy" smiley

Quote:

---

Originally Posted by deathshadow60

... and I HATE to break it to you, but /FAIL/ hard. REALLY HARD.

---

The idea of comments is to save time later on.

You should write your code and comments in such a way than when you or anyone else needs to do any changes to the code a year from now. Then you will undertand what the code section does the second you read over it.

With other words:
Create proper laid out code, using variable names that is self explanitary proper spacing between the different commands/sections and of course comments on vital parts.


That is what I prefer and so does any professional programmer. Having a piece of code that is self explanitary is worth A LOT more than the few ms of extra parsing time it costs.

Heck, if speed were an issue you would never be programming using these languages in the first place...

Quote:

---

Originally Posted by deathshadow60

Of course, switching in and out of parse mode like some rubbish "scripting" language doesn't help... there's a reason I consider any php code that does <?php ?> more than once to be a steaming pile of garbage.

---

Good for you!

Though there is no reason why you should not be able to do that when programming in PHP. The template system we use (PHP) was actually created for this kind of use.

Quote:

---

Originally Posted by deathshadow60

All you have to do is look at the retard code example on the site for smarty -- no self respecting PHP developer would write GARBAGE like this:

---

With the exception of the use of short tags, I personally feel the code in your first example was very good. Doing it this way has a big advantage of that your designers can easially update the template files with the new design without requiring any help from the programmers.

You might also want to check up your statement with single quote vs double quote strings in PHP.

Quote:

---

Originally Posted by deathshadow60

Would work too.... even if it does take longer to execute since you have the complex parser involved.

---

:nono:

I don't think you quite get how the PHP interpreter reacts to the opening and closing takes, " vs. ' and heredocs vs. nowdocs. The situation is at best unclear. The difference in execution time between

PHP Code:

---

echo 'Lorem Ipsum '.$var.' no dolem.'; 


---

and

PHP Code:

---

echo "Lorem Ipsum {$var} no dolem"; 


---

Is nominal. Further - counter intuitively - the parser does the second version slightly faster.

Second, it doesn't cost the parser time to move between PHP blocks. Any intervening text is silently converted to an echo statement. So moving between modes doesn't make the code dog slow.

I'm studying C++ because I do want to make the parser modal at include time and no one else is interested in coding the project. This isn't so much for optimization as allowing framework designers to more strictly control the types of files that are included. The mod I'm working on allows the language to do the following.

PHP Code:

---

require( "file.php"); // For backwards compat php.ini settings honored.
require( "include.php", PHP_TAGS_NONE ); // No tags will be allowed, whole file is assumed to be PHP code.
require( "template.phtml", PHP_TAGS_SHORT ); // Short tags enabled for this include.
require( "template2.tpl", PHP_TAGS_HEREDOC ); // No tags allowed, but variables such as {$var} will be evalutated as if the entire files was fed through the heredocs parser 


---

In the PHP.ini file the default tag mode can be set, and if set the existing ASP_TAGS and SHORT_OPEN_TAGS settings get ignored.

The goal is to allow the programmer to control the allowed parsing at require time with a goal towards further encouraging code separation and increasing security since dis-allowed markup cannot be placed in certain file types.

Off Topic:

Back off the bombastic arrogance please. It's annoying and insulting the the reader and a distraction from the content of your messages which is usually insightful and on point.

Quote:

---

Originally Posted by Michael Morris

The difference in execution time between

PHP Code:

---

echo 'Lorem Ipsum '.$var.' no dolem.'; 


---

and

PHP Code:

---

echo "Lorem Ipsum {$var} no dolem"; 


---

---

Actually that makes perfect sense for the latter to run faster, it's not allocating memory to perform a string addition BEFORE the output. Swap those periods for comma's and it runs faster than the latter.

Single quote parsing only has to scan for escaped singles and the close, double quote parsing has to scan for variables, multiple possible escaped values, AND inlined variables -- it's making the parser and interpreter do all the work...

Off Topic:

Quote:

---

Originally Posted by Michael Morris

Back off the bombastic arrogance please. It's annoying and insulting the the reader and a distraction from the content of your messages which is usually insightful and on point.

---

You know, I'm really sick of this... ok, I'm not going to say it; I'd be banned if I said my real response to that. Are people REALLY so thin skinned?

Oh wait, of course they are; so comfortable, so soft... and god forbid you say anything negative about ANYTHING.

I was taught that when something stinks you rip it completely to shreds and say it stinks -- that's how you have PROGRESS. People who cannot stand the idea of calling stupid stupid, idiocy idiocy and nimrods nimrods typically end up with the 'status quo' mentality; the antithesis of progress.

Though I like the idea of not allowing PHP includes to include markup... I wouldn't even BOTHER with the other ones, just make ALL php files be treated as your PHP_TAGS_NONE... I truly believe it was a mistake to EVER allow it to work any other way. I would love nothing better than to see <?php and ?> removed from the language ENTIRELY.

Off Topic:

Quote:

---

I was taught that when something stinks you rip it completely to shreds and say it stinks -- that's how you have PROGRESS.

---

Yes, but there is more than one way to say something stinks and still be clear that it stinks.

Oh, and how do you guys feel about taking out the PHP posts and making a new thread in PHP? I like where it's going so far, but it's not really about the professionalism (or lack thereof) of swear comments anymore.

And then it should be featured.

OK so here are my two penny worth:

1. Wiki's take on optimisation
Program optimization - Wikipedia, the free encyclopedia

2. Locate and analyse the major bottlenecks such as compiler (usually minimal), transmission, user output/display

3. Never ever forget the end goal and do not get side-tracked with inconsequential issues.

Quote:

---

Originally Posted by deathshadow60

Actually that makes perfect sense for the latter to run faster, it's not allocating memory to perform a string addition BEFORE the output. Swap those periods for comma's and it runs faster than the latter.

---

By how much?

At some point this begins to beg the question - why use PHP? If speed is such a great concern why not code in a faster language - say C++?

I mean, I've seen horrible coding lead to huge wastes of time in PHP - but using the PHP tags as intended was rarely one of them. In my template files I use PHP short tags and braceless syntax. This runs faster than smarty - but to get a noticable speed improvement I think PHP itself would have to be abandoned. While using commas may indeed be faster it won't be any huge breakthrough.

Meanwhile the legibility of the code becomes a major concern.

Off Topic:

Quote:

---

You know, I'm really sick of this... ok, I'm not going to say it; I'd be banned if I said my real response to that. Are people REALLY so thin skinned?

---

I agree that sometimes it is necessary to hit the mule upside the head with a 2x4 and my ignore list is full of twits that I put there because I imagine further conversation with them would net me a ban.

That said, it is better to be selective as to when you are being offensive. If every post you make insults someone or something, people start ignoring you even if they shouldn't. I've read enough of you posts to determine that they shouldn't - but it would hurt you to be more diplomatic most of the time, and save the venom for the truly spectacular examples of stupidity that come up.

Quote:

---

Though I like the idea of not allowing PHP includes to include markup... I wouldn't even BOTHER with the other ones, just make ALL php files be treated as your PHP_TAGS_NONE... I truly believe it was a mistake to EVER allow it to work any other way. I would love nothing better than to see <?php and ?> removed from the language ENTIRELY.

---

The plug in I am wanting to work on would allow you to configure the language that way on your own servers, but PHP as a whole needs to stay true to its heritage as a template engine. This means that option should remain - and while you might not like it I think it is one of the language's more powerful features.

In my view all these micro optimisations are pretty useless for 99.9999% of sites. Choosing how to echo a string because one might save you nanoseconds over the other, or not commenting code etc is pretty ridiculous.

The most important thing for me when I'm writing code is clarity and readability, so I always write to make things as clear as possible, to help future maintenance, including writing comments where necessary. To micro optimise like this hinders future work, and so is a false economy in effect.

If you are trying to solve a performance problem and you are looking at these things, you are doing it wrong. The problem is elsewhere.

I think you're missing what I'm saying about single quotes and about bloated nonsense like SMARTY... As it being faster is just part of it.

Single quotes:

Advantages:
Clearer code

White space neutral/white space preserving

much smaller/cleaner code than constantly doing <?php ?>

Fastest execution

Disadvantages:
must escape single quotes

Double quotes:

Advantages
Can inline a variable with less effort

Disadvantages
No white space preservation

Inherently slower since it needs to do more compares inside the loop.

Must escape double quotes, most people just make ugly markup by outputting singles instead

Smarty

Advantages
Even smaller code size

Disadvantages
Vague code through use of logic abbreviations

Vague code through cryptic abbreviations and changing standard functionality of common functions.

Significantly slower since it uses a pre-processor sitting atop PHP.

Requires installation of preprocessor that may not be available on all hosts. Said preprocessor adds overhead completely offsetting any code-size advantage.

I mean seriously, this:

Code:

---

<?php if(!empty($foo)): ?>
  <?php foreach($foo as $bar): ?>
    <a href="<?=$bar['zig']?>"><?=$bar['zag']?></a>
    <a href="<?=$bar['zig2']?>"><?=$bar['zag2']?></a>
    <a href="<?=$bar['zig3']?>"><?=$bar['zag3']?></a>
  <?php endforeach; ?>
<?php else: ?>
  There were no rows found.
<?php endif; ?>

---

Is an illegible train-wreck of badly written code. THIS:

Code:

---

if (!empty($foo)) {
  foreach($foo as $bar) {
    echo '
      <a href="',$bar['zig'],'">',$bar['zag'],'</a>
      <a href="',$bar['zig2'],'">',$bar['zag2'],'</a>
      <a href="',$bar['zig3'],'">',$bar['zag3'],'</a>';
  }
} else echo '
      There were no rows found.';

---

Is clean, simple, clear -- without resorting to installing some goofy preprocessor to sit on top of PHP adding just another unnecessary layer of abstraction. (seriously, whenever I see code like that first one I have the overwhelming urge to backhand someone)

Of course, I hate jquery on the same grounds. Probably stems from my not being particularly wild about C syntax languages and their needlessly complex and ridiculously vague and cryptic syntax. After thirty years of programming I don't much doubt that C and Unix are a hoax... I'd rather hand assemble z80 or 8088 machine language than deal with C dialect languages -- it's SIMPLER.

In fact, if it wasn't for the white space neutrality of single quotes, ease of interfacing to SQL databases compared to other languages, and robust in-built string handling I wouldn't be using PHP in the first place.

The first of those being why I don't understand why people even BOTHER with the "five hundred instances of <?php ?> for nothing" or the use of double quotes... it is NOT a good coding practice taking something simple and making it needlessly complex.

... but as a worshiper at the throne of Wirth, what do you expect from me?

Or as Micheal Abrash once said "Good coding practices make optimizations redundant". IMHO the "don't overoptimize" on things that are just sloppy/half-assed coding is a cop-out by the inept and the ignorant... especially when it's no more or less code to simply say "use single quotes instead of doubles" -- that's NOT overoptimizing or overthinking, that's good practice that if done from the start gives clearer code, marginally faster code, easier to maintain code, etc, etc... Overoptimizing is nonsense like white-space stripping -- which usually just seems to be used by people who can't code worth a damned in the first place!

Which should probably be filed alongside the other lame_excuses_for_not_being_a_web_professional

Quote:

---

Is an illegible train-wreck of badly written code. THIS:

---

If you're using vi.

If you're using an IDE, the former will be easier to read/edit due to syntax highlighting, tag matching, code completion and HTML error checking. Not to mention the code you demonstrate would likely be surrounded by large chunks of HTML.

I don't think I mentioned any of those, especially smarty (I didn't). I thought this discussion was about comments, and your claim that you shouldn't use them because it would slow the script down.

Quote:

---

Originally Posted by deathshadow60

Double quotes:
Disadvantages
No white space preservation

---

Blatantly false. Claims like this seriously undermine your credibility.

Quote:

---

Inherently slower since it needs to do more compares inside the loop.

---

The speed difference is so negligible that worrying about it amounts to phantom optimization.

Quote:

---

Must escape double quotes, most people just make ugly markup by outputting singles instead

---

Red herring. Every system must have a way to escape the delimiters. Any time those escapes are used things get ugly.

Quote:

---

I mean seriously, this:

Code:

---

<?php if(!empty($foo)): ?>
  <?php foreach($foo as $bar): ?>
    <a href="<?=$bar['zig']?>"><?=$bar['zag']?></a>
    <a href="<?=$bar['zig2']?>"><?=$bar['zag2']?></a>
    <a href="<?=$bar['zig3']?>"><?=$bar['zag3']?></a>
  <?php endforeach; ?>
<?php else: ?>
  There were no rows found.
<?php endif; ?>

---

Is an illegible train-wreck of badly written code. THIS:

---

If you are going to use short tags, use them correctly - not mixing them with long tags. Especially in an example trying to toot your point of view. You're taking the worst of both worlds and trying to paint it as the way things are which is disingenuous at best. Also your example fails to, in any way, take advantage of loop nesting. So let's look at a truthful version of this situation with markup likely to be found in the surrounding code in color context as most people use these days.

Code php:

---

<? if(!empty($foo)): ?>
  <div class="section">
  <? foreach($foo as $bar): ?>
    <ul>
      <? foreach($bar as $mar): ?>
        <li><a href="<?= $mar['href'] ?>" class="<?= $mar['active'] ?>"><?= $mar['text'] ?></a></li>
        <? endforeach ?>
      </ul>
  <? endforeach ?>
  </div>
<? else: ?>
   <div class="section empty">There were no rows found.</div>
<? endif ?>

---

That is no harder to read than its smarty equivalent. Your example is about the same difficulty to read up until we start adding a realistic amount of HTML markup in between the PHP variables. Then it is what becomes the eye bleeding mess.

Quote:

---

Is clean, simple, clear -- without resorting to installing some goofy preprocessor to sit on top of PHP adding just another unnecessary layer of abstraction.

---

:nono:

You. Just. Don't. Get. It. Do you?

Let me spell it out for you.

PHP Hypertext Preprocessor.

Right there in the damn recursive acronym name of the language. It has always been, and always will be, a preprocessor language. That will not change. Refusing to use the preprocessor features of the language doesn't remove them from the overhead of the interpreter. Either get over it or switch to a language that suits your ideas of perfection. Might I recommend Python?

Quote:

---

I'd rather hand assemble z80 or 8088 machine language than deal with C dialect languages -- it's SIMPLER.

---

The world disagrees with you there. If you were right the higher level languages wouldn't have needed to be developed. But oh look - here they are, and they're here to stay. Or you could put your money where your mouth is and build a website in assembly. I doubt you'd get as far as "hello world" in under a month.

Quote:

---

In fact, if it wasn't for the white space neutrality of single quotes, ease of interfacing to SQL databases compared to other languages, and robust in-built string handling I wouldn't be using PHP in the first place.

---

Given the pettiness of your gripes you shouldn't be using it. You would be happier with another language, so go learn one.

Hell, if you can grasp assembly then you can probably grok the source code of the PHP interpreter. Go take a look - given your elitist attitude you'll probably run away from PHP screaming in terror never to be heard from by the PHP community again.


Aside
In the short tag example above, note that the ending semicolon isn't present on any of the tags. This is because ?> is a line termination in PHP. ; ?> is redundant and equivalent to typing ;; at the end of the line. You can get away with it, but it isn't helping. I bring this up because a lot of folk aren't aware of the fact that ?> acts as a statement terminator. This is worth knowing because <? endfor ?> is ever so slightly easier to read than <? endfor; ?> or the like.

And indeed, that's all ?> does. It then starts an echo pass with the string being the contents of the text ecountered up to the beginning of the next <?php token.

Don't let deathshadow mislead you folks - the people who wrote PHP aren't idiots and there aren't thousands of wasted cpu cycles lost everytime the <? or <?php tag shows up, contrary to what he believes. Hell - he doesn't even realize that quotes preserve white space, which puts a lot of doubt as to how much of the internals of the PHP engine he really knows.

Quote:

---

Originally Posted by TomB

If you're using an IDE, the former will be easier to read/edit due to syntax highlighting, tag matching, code completion and HTML error checking. Not to mention the code you demonstrate would likely be surrounded by large chunks of HTML.

---

Most "IDE's" being just as faulty in coding practice as WYSIWYGS -- but then I realize I'm increasingly in the minority in HATING the illegible acid-trip induced color syntax highlighting, and in having my precious screen real-estate chewed up by useless toolbar crap, code completion an annoying waste of time I spend more time correcting than gaining utility from, and in finding tabbed editors a colossal step BACKWARDS in functionality as a multiple display user. (If I'm stuck on the crappy little 1024x800 netbook, THEN tabbed editors make sense -- on my quad display 1920x1200+1600x1200+2x 1024x1280 setup, not so much)

In fact MOST of what you listed are what I consider sloppy over-reliance on goofy tools that frankly often just get in my way... though if your color highlighting is worth a damn (and doesn't break just because you put <!-- in your .php file like 99% of editors out there) it should pick up the difference between strings and operators/delimiters and color code them appropriately...

But for my eyes, I can't use those. I get a headache after five minutes from the eye strain. Scary since I can look at one of the old green or amber CRT's for hours on end and be fine. You start switching colors ten to twenty times on a line... I can't fathom how anyone finds that useful; Though it could just be that I'm not punctuation blind -- There's a reason I use the CODE bbCode and not the PHP one here -- I prefer code not to be an illegible mess... case in point, your example of shortags is a confusing illegible mess to me... ENTIRELY because of the color highlighting... and all the in and out of parsing nonsense making it hard to tell what's even being indented or closed... when I have a block close, I like to SEE the block close as the first thing on the line, NOT <? making them all look the same.

Oh, and because of that your logic is flawed; you're outputting more </div> than you are opening. EXACTLY the type of common mistake I expect out of that coding approach.

But I'm 1TBS and find Allman/Whitesmith to be total illegible garbage too, and even want to backhand people for unnecessary spaces around operators. (making my eyes instantly think it's multiple operations and not one).

That said Vi/Vim is a needlessly cryptic tinkertoy that if I felt like dicking around with obscure keyboard commands from the 1980's I'd still be using Wordstar... ^kv ^kd, ^kq -- NOT. But then I say the same thing about linsux as a desktop OS -- If I wanted to spend hours dicking around on the command line for functionality I've had with two or three clicks since windows 3.1, I'd go down to my garage and boot up Xenix on the Trash-80 Model 16, CP/M on the Model 4p or OS/9 on the Coco. This is 2011, I though we'd be past that garbage by now.

Though it could just be I've been at this stuff for WAY too long... part of why I said screw this and took some time away from "modern" to write a DOS game with a CGA equipped 128k IBM 5150 as the minimum target. Go back to when programming made sense and people actually took a little pride in their work instead of just sleazing it out any old way.

Quote:

---

Originally Posted by Stormrider

I don't think I mentioned any of those, especially smarty (I didn't). I thought this discussion was about comments, and your claim that you shouldn't use them because it would slow the script down.

---

Thread cut issue -- check the other one; Someone said "I bet you use smarty" in response to my... distaste for <?php ?> on every bloody line -- which was wrong... and then I explained WHY it was wrong.

Since I'm not a big fan of "me too" "is not, is so" posting.

Ah, a programming grognard. I get it now.

Quote:

---

Originally Posted by Michael Morris

Ah, a programming grognard. I get it now.

---

I'll accept that as a fairly accurate description... Now I'm tempted to queue up Wierd Al's "When I was your age". There's a reason the Stupid Dutch Kitty calls me "Crusty".

It just annoys me to see so much of what's called "progress" seem like massive steps backwards; the answer to said bad sleazy/lazy practices being to "just throw more hardware at it" or to just throw more layers of abstraction atop it -- see X11, which if it didn't suck so bad there would be no Motif, GTK, QT, etc, etc, etc...

Like my having once maintained a 5000 simultaneous user 2 gig database of insurance records on a 486/66 running netware 3.12 with about a quarter of those users remote booting off that server -- when today a 4 gig dual Xeon can be choked to death by a crappy little 200 megabyte forum database with 100 users online at once.

I'm sure the Amish would agree - all progress is bad.

You are right about programming practices degrading - but it's not a grand conspiracy. With more people doing programming, there's going to be more *bad* programming done. That's just life.

I don't expect programming to straighten its act up until it has too - like when Moore's law slams headfirst into the laws of physics and silicone lithography can't get any smaller. Then the improvements will have to come in code or hardware structure. But right now the situation is that a programmer's time is more expensive than the faster hardware.

But yeah, I'm amazed at what was pulled off in the old days. The Atari 2600 only has 128 BYTES of memory, and yet look at what was done. But that doesn't make modern games and programs any less impressive. They're just different.

Quote:

---

Originally Posted by Michael Morris

PHP Hypertext Preprocessor.

---

I agree with you, but I should point out that this is actually a Backronym - it originally stood for Personal Home Pages Toolkit (PHP Toolkit) I think, this acronym came in a later version.

Quote:

---

In fact MOST of what you listed are what I consider sloppy over-reliance on goofy tools that frankly often just get in my way... though if your color highlighting is worth a damn (and doesn't break just because you put <!-- in your .php file like 99% of editors out there) it should pick up the difference between strings and operators/delimiters and color code them appropriately...

---

Firstly, [citation needed]? How many editors break? Lets do a poll to find out how many people find syntax highlitghting useful for productivity. I'm sure you are in a tiny minority.

My point was enclosing HTML in PHP strings will lose the HTML tag matching and highlighting. If you can't see the benefit in being able to quickly find the start tag for an end tag, or letting the editor immediately tell you when you're missing a </div> then you really are just stuck in your ways. Or are you perfect? Let me guess, you never make mistakes....

Quote:

---

Though it could just be I've been at this stuff for WAY too long... part of why I said screw this and took some time away from "modern" to write a DOS game with a CGA equipped 128k IBM 5150 as the minimum target. Go back to when programming made sense and people actually took a little pride in their work instead of just sleazing it out any old way.

---

I see. Nostalgia is your argument here. Great, can we actually discuss things which have a practical benefit? And no, code formatting preferences are not practical.

Quote:

---

But I'm 1TBS and find Allman/Whitesmith to be total illegible garbage too, and even want to backhand people for unnecessary spaces around operators. (making my eyes instantly think it's multiple operations and not one).

---

I have no idea what this means. It's a series of correctly-spelled English words and it parses as a grammatically correct sentence, but beyond that "it sounds like ********".

Quote:

---

It just annoys me to see so much of what's called "progress" seem like massive steps backwards; the answer to said bad sleazy/lazy practices being to "just throw more hardware at it" or to just throw more layers of abstraction atop it -- see X11, which if it didn't suck so bad there would be no Motif, GTK, QT, etc, etc, etc...

---

If sending electric pulses to one another didn't suck so bad there'd be no reason to use a CPU to process them. That silly level of abstraction is pointless isn't it? Lets not get started on HTTP being layered on top of TCP/IP. We should just make it so web servers communicate directly with the NIC and tell it exactly what bits to send in what order, how to package and route them.

Seriously, I am starting to wonder whether you are just trolling. If as a programmer, you don't see the benefits of abstraction, I think you're in the wrong job.

Quote:

---

Originally Posted by deathshadow60

since php is an INTERPRETED language.

---

This entire discussion has gone off course because PHP is NOT an interpreted language - it is a compiled language.

It isn't comiled just once though with all subsequent accesses using the compiled version. It is compiled every time someone accesses the web page and the compiled version is run just for that one access and is then discarded with the script being compiled all over again when the page is next referenced.

This is known as a Just in Time compile process (or JIT).

You can tell that PHP is compiled and not interpreted because if there are any syntax errors in the code at all you get a syntax error message and none of the code gets run. If you consider an interpreted language such as JavaScript all of the code that can be run will be run up to the point where a syntax error occurs because the interpreter runs each statement separately before looking at the next.

Now the compile step is going to run longer in order to skip over the comments in the code but the run step following will not have any comments to skip over.

This will make a difference to the amount of impact that comment placement will have within the code. With an interpreted language such as JavaScript a comment inside a function or loop will need to be skipped over and slow down the processing each time that the function or loop runs and so moving the comment outside of the function or loop will speed up the processing. With PHP though while the comments will slow the compiler down they should all have the same effect regardless of where in the code that they are placed since the functions and loops will not be run until after the compiler finishes compiling the code and the version that actually gets run will not have any comments in it anywhere.

So while each comment you place in PHP will slow down the processing it will not make any difference where you put the comments and comments inside a loop that runs millions of times will have the same effect as if the comment were outside the loop rather than being treated as a million separate comments the way it would in an interpreted language.

Quote:

---

Originally Posted by TomB

Firstly, [citation needed]? How many editors break? Lets do a poll to find out how many people find syntax highlitghting useful for productivity. I'm sure you are in a tiny minority.

---

Crimson, Notepad++, the M$ one for .net, gEdit... Of course since acid trip is one of the first things I turn off...

Quote:

---

Originally Posted by TomB

My point was enclosing HTML in PHP strings will lose the HTML tag matching and highlighting.

---

Which I don't need because I know how to use the TAB and ENTER keys, and generally don't have block level containers long enough for them not to line up on screen.

Quote:

---

Originally Posted by TomB

If you can't see the benefit in being able to quickly find the start tag for an end tag

---

I do, that's why I'm rabid about hitting enter, tab, or shift-tab, or letting the auto-deindent do it's job.

Quote:

---

Originally Posted by TomB

or letting the editor immediately tell you when you're missing a </div> then you really are just stuck in your ways.

---

Which just gets in the way when it's in two separate functions, or two separate files... and practice the 76 column rule for code but not content.

Quote:

---

Originally Posted by TomB

Or are you perfect? Let me guess, you never make mistakes....

---

No, but I do practice decade old tried and true methods for preventing me from making the simpler mistakes in the first place...

Quote:

---

Originally Posted by TomB

I see. Nostalgia is your argument here. Great, can we actually discuss things which have a practical benefit? And no, code formatting preferences are not practical.

---

No offense, but spoken like someone not only over-reliant on their tools, but vomiting up code any old way. Lemme guess, classes on H1's, style tags in the markup for static values like width:auto; vague/meaningless three letter classnames and presentational classes like "right"? PRobably have some nice pointless IE conditionals on a layout that shouldn't even need real hacks to work properly all the way back to IE 5.x?

Quote:

---

Originally Posted by TomB

I have no idea what this means. It's a series of correctly-spelled English words and it parses as a grammatically correct sentence, but beyond that "it sounds like ********".

---

So... been programming all of six months to a year and never taken a single course or read a book on the subject? Or are the fundementals of elementary programming practices just not taught anymore?

Indent style - Wikipedia, the free encyclopedia

Quote:

---

Originally Posted by TomB

That silly level of abstraction is pointless isn't it?

---

Abstraction isn't pointless -- abstraction without improvement or abstraction to avoid fixing something inherently wrong with what's underneath IS. The latter of those among programmers it's often called the "black box" syndrome -- rather than fix something directly, you just treat the core as invoilate and slap something else on top of it to handle the problem... Which in engineering parlance is basically duct tape, spit and bailing wire. It'll get the job done for a bit, but it usually comes back to bite you further down the road.

The former is just bloat for nothing -- and is why Smarty to me is pointless; it offers no real improvements despite adding the overhead of an extra preprocessor atop a... preprocessor... I say much the same about jquery as I see no real improvements over just writing the code directly, and for the most part it's useless bloat ruining just about every website it's on from both a maintenance standpoint and from a user standpoint...

Quote:

---

Originally Posted by felgall

This entire discussion has gone off course because PHP is NOT an interpreted language - it is a compiled language.

It isn't comiled just once though with all subsequent accesses using the compiled version. It is compiled every time someone accesses the web page and the compiled version is run just for that one access and is then discarded with the script being compiled all over again when the page is next referenced.

This is known as a Just in Time compile process (or JIT).

---

WRONG... and right... Wait, what? Lemme explain.

PHP does NOT compile to native machine language, the precompiler is to bytecode to run on a bytecode interpreter... so while it is "compiled" it is not TRULY compiled. Microsoft Gee-Whiz Basic did the same thing, we still call that an interpreted language! It may catch syntax errors before runtime; but that doesn't mean it's an actual compiled language. GW-Basic and most Microsoft ROM basics didn't let you enter lines of code with syntax errors on them or load ASCII copies of programs that had syntax errors -- nor did they store the code in memory as ASCII -- did that make them compiled languages? OF COURSE NOT! Hell, on pretty much every ROM basic and soft-basic interpreter "syntax error" is a EDITOR message, not a runtime error.

The code still runs on an INTERPRETER instead of as MACHINE LANGUAGE. See the difference? It's not like it runs it through GAS to make a executable binary.

It most certainly is NOT JIT compiled since the compile target is NOT machine language! It's bytecode compiled -- oh, and if you run a caching director like eAccellerator or APC, that bytecoded version of the page IS cached and not thrown away -- assuming there's room in the cache and it's frequently accessed enough! (I like to provide 256 megs of space to APC, which is more than the bytecode version of every .php file on my server combined)

If we call PHP a compiled language, we'd have to call the BASIC interpreter on a ZX80 compiled, and that's just silly... much akin to the people who call XML a "machine readable format" or XML based "languages" machine readable -- Said people needing to go back and learn something about computers! If you have to run it through a parser to turn those integers from ascii into integers, reals from ascii into single,double or extended and strings into machine format null terminating or length prefixed strings, they're NOT any more machine readable than C or Pascal code... or Assembly language source; until it's turned into machine code or formats that the registers and opcodes can handle directly, it's NOT "Machine readable". Might be SOFTWARE readable...

Bottom line -- compiling to bytecode to run on an INTERPRETER is NOT true compilation... and it sure as shine-ola isn't JIT compilation in any sense of the term.