Mindflow wrote:

Who could you be to be absolutely sure there are no bugs, or you predict exactly what will happen in the future, heh, you must be the best beta tester in the world.

By being sure, I mean that the code runs well enough for the task I plan to assign to it. If my code does small number approximation, I needn't build it so that it can accept all weird inputs and make it a bloated all-around function. I need one simple functionality - I do it. That's it. Then again, what I meant mostly wasn't exactly obfuscation, rather 'compression' - it doesn't take that much space then (with all the formatting and the like removed). But then again I do obfuscate sometimes (putting computations in the 3rd for() clause, for example). But, like I said, I try to limit myself to simple, small blocks of code (things I can easily debug if I need to - to keep things manageable). Its all built from small blocks becoming bigger blocks becoming apps, isn't it? :) (I mean, just look at Linux ;P) I'm not trying to write perfect code and certainly not trying to be smarter than I am. :) I'd hate myself for that 3 montsh later. :P

I'm not sure either if there is a spec for PHP - I just read the manual and learn as I go. ;) As for the inc/dec operators, I've heard a discussion about which one was more efficient when used as a standalone operation, ie. ... i++; doSomething(); ... or ... ++i; doSomething(); ... and from what I remember, someone said that pre-inc/dec was more efficient, because it doesn't copy the value somewhere... I'm not really that good with C/C++, but with PHP no matter how many times I run what I've posted before it ALWAYS evaluates the way I expect it to. I guess that's what the whole hype's about with deterministic computing, etc. ... ;) But You are right in that we should be more explicit about what we want to do, and what we expect to get in return. I mean, ie. the strict-comparison (===) operator exists for a reason... :) Besides, that whole line ( $i = $i + $i++; ) is just plain wrong, as in 'close to obfuscated'... not that I've never done a similar thing, one way or the other... :-O -- modified at 23:06 Tuesday 3rd October, 2006

I stand corrected. :-)

Cees Meijer wrote:

it will bite you somewhere in the future (Sure, 100%...)

Yeah, especialy when you forget about it and add more to it. :/ You're lucky if there was an ELSE (the compiler should spit out an error about ELSE without an IF statement)...

From my personal experience I like to "compress" (ie. condense in an absolutely one single line of ";"-delimited instructions) pieces of code I am ABSOLUTELY SURE that works in itself. And I'm absolutely sure only after I've tested the ie. function for all kinds of situations I expect to have variables sent there (including, but not limited to, margin-style variables... what with Excel's 00. January 1900 (or 1901) bug being caused by a date of 0...) Still, I like to do that only when I'm sure this will be sent to wherever it has to be sent in that exact form, and I don't expect anyone to look into the code. I try to keep a fully-clearly-formatted-and-indented version somewhere on one of my backups, just to be on the safe side.

Setting a limit might be hard to do in PHP, since You really don't define the variable TYPE You'd expect. What with setting a limit at 2000 when a value could legitimately reach 3000? It can be done in C/C++ or any language with strict type definitons, however. That way You'd know that You're expecting ie. an INT, so it'd be a good idea to set the loopCounter somewhere around 65535 or seomthing... :) [in general, somewhere around the margin value the expected variable type can hold, be it positive or negative] -------------------- Just ignore me. ;)

"// PHP $i = 6; echo ($i = $i + $i++); echo "Result : " . $i; Displays 12 twice Not good. I think the first line should display 12 and second 13. I wonder how it would be displayed when compiled in other languages." I have Your bug by the balls, so to say :-) Here's how it works: a) "$i + $i" evaluates to 12 b) $i++ evaluates to 7 c) $i evaluates to 12 in other words, the post-incremenation comes BEFORE the assignment, so $i becomes 12 and not 13 (it's 6->7 then 12, not 12 then 12->13). The second example works, because ++$i evaluates to 7 first. The difference between pre- and post-incrementation is that the former increments before reading the variable, and the latter increments AFTER the value is taken into consideration in whatever computation. It's the same with pre- and post-decrementation. Actually, this is a textbook example of "not getting" these operators. :)

"if ((flag=value)==TRUE) ... " Now THIS could be adopted as a 'good practice' over that crappy "value == variable" thing! The latter won't work, for example, when You by mistake do something like if (variable_a = variable_b) { ... and since the names can be pretty long (no limits, really), it'd be tough to spot. With the former approach, one'd see the above as NOT being right, not being: if ((variable_a = variable_b) == TRUE) { ... Could be useful. Thanks :) On a side note, I like to do "if (variable_a === variable_b)", so that I can ommit one "=" and still get away with it (I like to be explicit about what I expect to get exactly, especialy with OOP which in itself obfuscates the code in its own way...)

"So 'i = 2' is actually an an ASSIGNMENT and the if-statement seems to evaluate assignments to 'true', at least in Java." in C also, in C++ also, in PHP also etc. The only language I know of where it DOESN'T evaluate ASSIGNMENTS to TRUE is PASCAL (what with assignment operator being := and all...)

Well, I don't. ;-) I code PHP, and I use that pretty often, ie. if ($file_handle = fopen("filename", "r")) { // do something } else { die("File cannot be opened!"); } That part above returns handle if opened (and that resolves TRUE when it's passed into the variable), and an error otherwise (which resolves FALSE). ...I guess You're going to smack me down for using the last for() element for computation, leaving empty {} brackets, too? :P