Sorry to add more salt to the open wound, but i am with Steve Rude on this one. when it comes to drupal, we should hang onto every chance to improve performance. even small things like changing upper case TRUE to lowercase. as some have mentioned: in a single request drupal might not have enough such cases to make a difference. but when your site receives a lot of traffic, something as small as this might make a difference.
It won't. Even if the capitalization parsing did trigger a speed hit, the 'worst case scenario' posted earlier in the thread still reveals a small enough difference that it vanishes into the realm of statistical noise. The execution time of a raw chunk of PHP is not where Drupal's problems lie, plain and simple. The problems lie in the memory and database footprint. As an experiment, look at the timing differences, then look at how much time it takes to execute a single SQL query. Think hard on that for a moment. By eliminating a *single SQL query* from your page load, you will save more time than can be saved by all the constant- capitalization-tweaking in the world. Hyper-optimizing for questionable gains due to undocumented idiosyncrasies of a particular language's parser -- especially when there are other well-known speed issues -- is a bad idea. You saw this in eons past with C and other languages, where the 'speed gains' of a switch statement over an if/then/else statement were cited. Those gains vanished as compilers got better, and any gains we'd receive from this capitalization change (if any) would be wiped out by the use of an opcode cache, something that's all but required for any site getting enough traffic to worry about these kinds of incremental gains. Drupal's existing coding standards are geared towards readability and consistency, and the use of TRUE, FALSE, and NULL as capitalized strings is good. I vote for changing coder.module to mirror the defined coding standards. --Jeff