• Paul (unregistered)

    The "guru"'s name was Todd, wasn't it?

    I worked (only briefly, thankfully) on a PHP web app, and one of the other developers (Todd) was a self-described PHP guru. He was building a OO framework (this was pre-PHP4) that he kept trying to persuade us to use. One of its odder features was its underlying use of single-character-named global variables (yes, global). As far as we could see, he used single character names to save time typing.

  • DeepThought (unregistered)

    I've always observed that regardless of the language or environment that a good programmer will generally write good, clean, maintainable code while a bad program will write crap almost every time.

  • jDeepbeep (unregistered) in reply to noob
    noob:
    Are you making fun of my name? That's not nice.

    TopCoder, is that you?

  • (cs) in reply to Kazan
    Kazan:
    Mike:
    Buddy:
    Kazan:
    Buddy:
    Pretty much. When a language evaluates (bool)'0', (bool)'' to FALSE ...

    or you could simply not be a jackass and realize that any-non-zero value is considered true and a non-empty string is considered non-zero. ...

    '0' is a non-empty string, (bool)'0' evaluates to FALSE.

    Yes, '0' is non-empty; however, it is not non-zero.

    he was pouncing on my generalize of non-empty strings being considered non-zero... because i simply didn't add "unless its contents are the number zero"

    But then shouldn't all zero-equivalent strings (0, 0.0, 0.00, etc.) cast to the same boolean? According to him, they don't -- '0' casts to false, while "0.0" casts to true.

  • (cs) in reply to snoofle
    snoofle:
    Kazan:
    that's exactly it - PHP is easy to learn.
    I know not PHP, but it seems to me that PHP only appears to be easy to learn. Judging from the stories, learning to use it properly is not.

    learning to express oneself and learning to express oneself well are often two different things. especially in computer science.

  • BEF (unregistered) 
        $sql = "SELECT * FROM ".$c.
           " WHERE ".$d." = '".$a.
           "' AND ".$e." = '" .$b."'";
    You following along? That's where $d = $a and $e = $b! Few things are more of a pleasure to debug. Nevermind the SQL Injection.

    Correct me if I'm wrong--but this doesn't necessarily lead to SQL injection. There's no evidence that $a,$b,etc aren't sanitized, or even that they are directly from form fields or query strings. Granted, there's no evidence that they ARE, but it seems like a bit of a leap.

  • (cs) in reply to Kensey
    Kensey:
    But then shouldn't all zero-equivalent strings (0, 0.0, 0.00, etc.) cast to the same boolean? According to him, they don't -- '0' casts to false, while "0.0" casts to true.

    it's been a while since I worked with PHP so I would have to check the behavior of floating point numbers in strings being cast to booleans.

    the point is you shouldn't be doing it :D.

    the operator === in php exists to check type and value [in a language that allows dynamic type changes]

  • (cs) in reply to BEF
    BEF:
        $sql = "SELECT * FROM ".$c.
           " WHERE ".$d." = '".$a.
           "' AND ".$e." = '" .$b."'";
    You following along? That's where $d = $a and $e = $b! Few things are more of a pleasure to debug. Nevermind the SQL Injection.

    Correct me if I'm wrong--but this doesn't necessarily lead to SQL injection. There's no evidence that $a,$b,etc aren't sanitized, or even that they are directly from form fields or query strings. Granted, there's no evidence that they ARE, but it seems like a bit of a leap.

    the evidence that they're not sanitized is in the rest of this guys code: it's braindead.

    you shouldn't be passing anything but values to query constructors, better yet you should be using your SQL servers prepared statements

  • Brandon (unregistered) in reply to Marcel
    Marcel:
    MrsPost:
    I've had the dubious pleasure of re-writing a bunch of procedures as we upgrade and have had to deal with half a dozen temp tables at a time, each with a primary key field name of .. id.

    Ok... and the problem is... ?

    The first Database I designed used tables with ID fields as the PK. the main reason was to have the join conditions easier to write: SELECT * FROM t1 INNER JOIN t2 ON t1ID = t1.ID

    of course, this all goes to hell as soon as you have more than one table with t1ID referenced in your query.

    (note, I don't do this any more, and I certainly wouldn't call it the worst design decision I've ever made, but it's not WTF worthy)

  • (cs) in reply to Brandon
    Brandon:
    ....

    everybody i know does the following pattern

    table by the name of $foo as a row named "$foo . "_id" (eval as PHP)

    This is because A) [existance] the auto increment id column is ONLY there for database manip and foreign keying purposes to ensure unique primary key B) [naming] clarity on multi-way joins.

  • (cs) in reply to Kensey
    Kazan:
    Buddy:
    Pretty much. When a language evaluates (bool)'0', (bool)'' to FALSE ...

    or you could simply not be a jackass and realize that any-non-zero value is considered true and a non-empty string is considered non-zero. ...

    $a = 0; $b = 'Hello';
if ($a == false && $b == true && $a == $b) echo 'Universe broken.';

    I still haven't worked out why, when performing int-string comparisons, PHP performs an int-int comparison (changing the code to (string)$a == $b causes it to work as you'd expect).

  • Chris (unregistered) in reply to strictnein

    sure php sucks... but a majority of the Internet runs on it, including many major sites(ie digg, facebook, wordpress, wikipedia,...) . Deal. Maybe because its free, and fast on cheap apache servers, with an abundance of developers(may be bad ones but more means cheaper) to hire. I still find it funny when I hear a VB or .NET programmer trying to act snub about a language when they are using crap themselves. Let the flame war continue!

  • (cs) in reply to benryves
    benryves:
    I still haven't worked out why, when performing int-string comparisons, PHP performs an int-int comparison (changing the code to (string)$a == $b causes it to work as you'd expect).

    How about this one?

    var_dump("0123" == 123); //outputs bool(true)
  • (cs) in reply to benryves
    benryves:
    Kazan:
    Buddy:
    Pretty much. When a language evaluates (bool)'0', (bool)'' to FALSE ...

    or you could simply not be a jackass and realize that any-non-zero value is considered true and a non-empty string is considered non-zero. ...

    $a = 0; $b = 'Hello';
if ($a == false && $b == true && $a == $b) echo 'Universe broken.';

    I still haven't worked out why, when performing int-string comparisons, PHP performs an int-int comparison (changing the code to (string)$a == $b causes it to work as you'd expect).

    dynamic type conversion, switch it to $b == $a and see what happens

  • (cs)

    Yeah! PHP sucks because someone can't handle the false != '0' comparison. Also, C sucks because its string handling is a wtf (zero-terminated chains). Oh wait, Java sucks, you have no pointers and shit. Hey, there's C#, it's properietary code! Let's burn it!

    JUST GET OVER IT ALREADY

  • (cs) in reply to JDeepBeep
    JDeepBeep:
    benryves:
    I still haven't worked out why, when performing int-string comparisons, PHP performs an int-int comparison (changing the code to (string)$a == $b causes it to work as you'd expect).

    How about this one?

    var_dump("0123" == 123); //outputs bool(true)

    that's PRECISELY the expected behavior. Int has the higher "type precedence" or whatever you want to call it.

  • Franz Kafka (unregistered) in reply to Procedural
    Procedural:
    jonnyq:
    Kazan:
    Buddy:
    DiverKas:
    Guru and php is pretty much an oxymoron isnt it?
    Pretty much. When a language evaluates (bool)'0', (bool)'' to FALSE but (bool)'false', (bool)'no', (bool)'0.0' to TRUE, you know you're in for a world of hurt.
    PS: PHP isn't a bad language, it's however an EASY language - easy languages get a higher proportion of bad programmers.

    As someone whose main qualification is PHP, I can say that PHP is a bad language. It's a very bad language that can be written well if you try hard enough.

    I'm always impressed by the fact that people who say that PHP is a bad language, for it promotes odd inconvenient structures, is full of exceptions and incoherent rules, can be so readily abused, and therefore would and should be unpopular if it weren't for the great unwashed masses always choose to state those facts in English.

    find me a computer that runs programs written in english.

  • Jay (unregistered) in reply to benryves
    benryves:
    Kazan:
    Buddy:
    Pretty much. When a language evaluates (bool)'0', (bool)'' to FALSE ...

    or you could simply not be a jackass and realize that any-non-zero value is considered true and a non-empty string is considered non-zero. ...

    $a = 0; $b = 'Hello';
if ($a == false && $b == true && $a == $b) echo 'Universe broken.';

    I still haven't worked out why, when performing int-string comparisons, PHP performs an int-int comparison (changing the code to (string)$a == $b causes it to work as you'd expect).

    I'm not particularly a fan of PHP, but I'd have to join in saying this is an unfair criticism.

    I think Java is a way cool language. But nevertheless, while new Boolean("true") returns true and new Boolean("false") returns false as anyone would likely guess, new Boolean("really absolutely positively true") is in fact false, or perhaps more subtly, new Boolean("T") and new Boolean("true ") are false. The rules aren't all that difficult to learn, and if they are inconvenient in a particular situation, oh well, too bad.

  • m0ffx (unregistered)
    ounos:
    For as long as he could remember, **one Millan C's clients**
    I hate to break the news, but your grammar skills are well below those of a baby ape. A baby jew ape, to be sure.

    The part of the article you quoted is grammatically correct. The word 'one' refers to "Millan C"; it's optional, but provides dramatic emphasis.

    It probably was meant to say 'one of', otherwise it states that multiple clients share one 'in-house PHP Guru', which is clearly impossible. But the current statement is grammatically valid.

    What isn't correct is

    "...their very own, in-house PHP Guru."

    The comma should either be absent or joined by another after 'in-house'.

  • (cs) in reply to Kazan
    Kazan:
    JDeepBeep:
    benryves:
    I still haven't worked out why, when performing int-string comparisons, PHP performs an int-int comparison (changing the code to (string)$a == $b causes it to work as you'd expect).

    How about this one?

    var_dump("0123" == 123); //outputs bool(true)

    that's PRECISELY the expected behavior. Int has the higher "type precedence" or whatever you want to call it.

    At first thought, I would imagine it to evaluate as false, due to that the following evaluates to false.

    var_dump(0123 == 123); //outputs bool(false)

    I would imagine that in the first example, "0123" would be converted to 0123, which is 83 octal, which is not equal to integer 123.

  • Capt. Obvious (unregistered) in reply to Brandon
    Brandon:
    The first Database I designed used tables with ID fields as the PK. the main reason was to have the join conditions easier to write: SELECT * FROM t1 INNER JOIN t2 ON t1ID = t1.ID

    of course, this all goes to hell as soon as you have more than one table with t1ID referenced in your query.

    Of course, it should be t2.t1ID (or T2.ixT1, if you're trying to be hungarian about it). Every table needs a primary key. Variable names are not places to be cute. Informally typesafing foreign keys is good. What's the issue, other than not correctly refering to t1ID?

  • (cs) in reply to Brandon
    Brandon:
    Marcel:
    MrsPost:
    I've had the dubious pleasure of re-writing a bunch of procedures as we upgrade and have had to deal with half a dozen temp tables at a time, each with a primary key field name of .. id.

    Ok... and the problem is... ?

    The first Database I designed used tables with ID fields as the PK. the main reason was to have the join conditions easier to write: SELECT * FROM t1 INNER JOIN t2 ON t1ID = t1.ID

    of course, this all goes to hell as soon as you have more than one table with t1ID referenced in your query.

    (note, I don't do this any more, and I certainly wouldn't call it the worst design decision I've ever made, but it's not WTF worthy)

    The solution to your problem you already know, you just don't realize what you are doing...

    SELECT t1.ID, t2.Field, t3.field FROM t1 INNER JOIN t2 ON t2.t1ID = t1.ID INNER JOIN t3 ON t3.t1ID = t1.ID

    Your biggest problem is "SELECT *" just dont do this, always list your fields, and if you have more than one table listed in your where clause, preface the fields with the table name, always. The maintainance programmer will thank you, even if it is you.

  • (cs) in reply to Kazan
    Kazan:
    the evidence that they're not sanitized is in the rest of this guys code: it's braindead.

    you shouldn't be passing anything but values to query constructors, better yet you should be using your SQL servers prepared statements

    Prepared statements or sanitize things and then use stuff like this:

    $query = sprintf("SELECT foo, bar FROM baz ORDER BY foo LIMIT 20 OFFSET %d;", $offset);

    No need for a PHP flamewar. Crap code is crap. Film at 11.

  • GreenGecko (unregistered) in reply to anonymous_coder()

    I use it as a replacement to shellscripting. I kept getting the $'s in the wrong places when switching between the two.

  • Dirge (unregistered) in reply to jDeepbeep
    jDeepbeep:
    Any person with formal training in writing code, problem solving, and logic, can write correct and reliable code in PHP. It's not about trying hard enough. It's about good habits, code clarity, and consistency.

    Anyone with formal training in symbolic logic (...or any training in/knowledge of logic) can tell you that just because it's possible to write correct and reliable code in PHP doesn't mean that PHP is necessarily a good language. I would argue that PHP is an abomination. If one of Lovecraft's Old Gods vomited an unholy Code From Outer Space into the world of men, it would be PHP, and it would also be the reason that R'lyeh is no longer above the waves. It's inconsistent, ugly, and full of terrible hacks preserved for all time. Back to the original topic, I suspect that the "guru" was an old-school programmer. Someone already suggested COBOL, but I remember the $a, $b (or $x, $y) thing from back in the olden days of 1980s BASIC as well. Maybe it was a holdover from math training? I even had a teacher back then who would use $left and $right any time he needed two variables, regardless of whether handedness was even vaguely involved in the program logic.

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    find me a computer that runs programs written in english.

    Here you go: http://www.dangermouse.net/esoteric/chef.html

    Pretty sure Chef runs on any modern computer...

  • GreenGecko (unregistered) in reply to Dirge
    Dirge:
    Back to the original topic, I suspect that the "guru" was an old-school programmer. Someone already suggested COBOL, but I remember the $a, $b (or $x, $y) thing from back in the olden days of 1980s BASIC as well. Maybe it was a holdover from math training? I even had a teacher back then who would use $left and $right any time he needed two variables, regardless of whether handedness was even vaguely involved in the program logic.

    Obviously not a fortran programmer, or it'd be i,j,k... for integers

  • Bluesman (unregistered) in reply to Brandon
    Brandon:
    Marcel:
    MrsPost:
    I've had the dubious pleasure of re-writing a bunch of procedures as we upgrade and have had to deal with half a dozen temp tables at a time, each with a primary key field name of .. id.

    Ok... and the problem is... ?

    The first Database I designed used tables with ID fields as the PK. the main reason was to have the join conditions easier to write: SELECT * FROM t1 INNER JOIN t2 ON t1ID = t1.ID

    of course, this all goes to hell as soon as you have more than one table with t1ID referenced in your query.

    (note, I don't do this any more, and I certainly wouldn't call it the worst design decision I've ever made, but it's not WTF worthy)

    Aliases!

  • Buddy (unregistered) in reply to Jay
    Jay:
    benryves:
    Kazan:
    Buddy:
    Pretty much. When a language evaluates (bool)'0', (bool)'' to FALSE ...

    or you could simply not be a jackass and realize that any-non-zero value is considered true and a non-empty string is considered non-zero. ...

    $a = 0; $b = 'Hello';
if ($a == false && $b == true && $a == $b) echo 'Universe broken.';

    I still haven't worked out why, when performing int-string comparisons, PHP performs an int-int comparison (changing the code to (string)$a == $b causes it to work as you'd expect).

    I'm not particularly a fan of PHP, but I'd have to join in saying this is an unfair criticism.

    ...

    It's not unfair. If a computer language can't define true and false consistently and logically then it's fundamentally flawed.

    The "universe broken" example, and one reply to use $b == $a (vs. $a == b), says it all. When the 'is equals' operator ceases to be commutative, then you're in for a world of hurt.

    There are some dynamically typed languages that get it right, and you can do the equivalent of:

    if ($booleanValue) {/* do something*/}

    For example, regardless of which DB you're using, and not have to worry about the internal details of how the DB handles boolean fields. PHP is not one of them.

  • MetaMan (unregistered)

    Just ask yourself, what would Jessica Simpson and Megan Fox do in a situation like this?

  • Procedural (unregistered) in reply to Buddy
    Buddy:
    Jay:
    benryves:
    Kazan:
    Buddy:
    Pretty much. When a language evaluates (bool)'0', (bool)'' to FALSE ...

    or you could simply not be a jackass and realize that any-non-zero value is considered true and a non-empty string is considered non-zero. ...

    $a = 0; $b = 'Hello';
if ($a == false && $b == true && $a == $b) echo 'Universe broken.';

    I still haven't worked out why, when performing int-string comparisons, PHP performs an int-int comparison (changing the code to (string)$a == $b causes it to work as you'd expect).

    I'm not particularly a fan of PHP, but I'd have to join in saying this is an unfair criticism.

    ...

    It's not unfair. If a computer language can't define true and false consistently and logically then it's fundamentally flawed.

    The "universe broken" example, and one reply to use $b == $a (vs. $a == b), says it all. When the 'is equals' operator ceases to be commutative, then you're in for a world of hurt.

    There are some dynamically typed languages that get it right, and you can do the equivalent of:

    if ($booleanValue) {/* do something*/}

    For example, regardless of which DB you're using, and not have to worry about the internal details of how the DB handles boolean fields. PHP is not one of them.

    I think the original commentator's point is that PHP is inconsistent when you try to cast string types to booleans. No-one here has made the case that PHP can't handle booleans. That would be ridiculous.

    If your boolean variables receive the result of boolean expressions, then of course this isn't an issue. But if you are the kind of developer who enjoys passing floating points by string or floating point representations of booleans (WTF!?) by the same mechanism, then of course you deserve what you get.

  • (cs) in reply to wee
    wee:
    Kazan:
    the evidence that they're not sanitized is in the rest of this guys code: it's braindead.

    you shouldn't be passing anything but values to query constructors, better yet you should be using your SQL servers prepared statements

    Prepared statements or sanitize things and then use stuff like this:

    $query = sprintf("SELECT foo, bar FROM baz ORDER BY foo LIMIT 20 OFFSET %d;", $offset);

    No need for a PHP flamewar. Crap code is crap. Film at 11.

    that's what i saw saying

    and im no so much pro-PHP just anti-moron. Use the language/environment best suited to the job.

    IMHO that's LAMP+Ajaj (Ajax but with JSON not XML) for web, C++ for pretty much everything else

  • Procedural (unregistered) in reply to Franz Kafka
    Franz Kafka:
    Procedural:
    jonnyq:
    Kazan:
    Buddy:
    DiverKas:
    Guru and php is pretty much an oxymoron isnt it?
    Pretty much. When a language evaluates (bool)'0', (bool)'' to FALSE but (bool)'false', (bool)'no', (bool)'0.0' to TRUE, you know you're in for a world of hurt.
    PS: PHP isn't a bad language, it's however an EASY language - easy languages get a higher proportion of bad programmers.

    As someone whose main qualification is PHP, I can say that PHP is a bad language. It's a very bad language that can be written well if you try hard enough.

    I'm always impressed by the fact that people who say that PHP is a bad language, for it promotes odd inconvenient structures, is full of exceptions and incoherent rules, can be so readily abused, and therefore would and should be unpopular if it weren't for the great unwashed masses always choose to state those facts in English.

    find me a computer that runs programs written in english.

    Put the screen to black and peer intensely; see the faint outline ? That's one of them. Of course it has some difficulties properly handling Boolean logic, so Buddy doesn't think it should exist, but I contend that it works pretty well nonetheless.

  • (cs) in reply to MetaMan
    MetaMan:
    Just ask yourself, what would Jessica Simpson and Megan Fox do in a situation like this?

    Ask Brian Boitano?

  • (cs) in reply to MetaMan
    MetaMan:
    Just ask yourself, what would Jessica Simpson and Megan Fox do in a situation like this?

    get naked and make me wish they actually ate something once in a while?

    goes back to his wonderfully curvy wife

  • (cs)

    oh and Buddy, ALL high-level languages that lack strict typing have some quirks in comparison operators between different types.

    the point is DON'T DO THAT. Just because you can doesn't mean you should or that a good programmer would.

    Your kinda thinking "ooh i can be cute and do this" has resulted in more WTFs in code that I've seen than any other thing. It's not the languages fault a programmer misused it without completely understanding what is going on

  • Americium (unregistered) in reply to Adam
    Adam:
    joe:
    ... I'm always impressed by the fact that people who say that PHP is a bad language, for it promotes odd inconvenient structures, is full of exceptions and incoherent rules, can be so readily abused, and therefore would and should be unpopular if it weren't for the great unwashed masses always choose to state those facts in English. ...

    And if that's how you write English, I'm glad I've never run into your code.

    Stupid Muphry's Law.

    /me wipes tears of laughter from his eyes. Can you not see the "Quote" button? How about the "Preview" button?

    Now, let us go to Wikipedia and learn of this man "Muphry"!

    Murphry's Law: Anything you do wrong will get commented on.

  • Paul (unregistered) in reply to Jay
    Jay:
    I think Java is a way cool language. But nevertheless, while new Boolean("true") returns true and new Boolean("false") returns false as anyone would likely guess, new Boolean("really absolutely positively true") is in fact false, or perhaps more subtly, new Boolean("T") and new Boolean("true ") are false. The rules aren't all that difficult to learn, and if they are inconvenient in a particular situation, oh well, too bad.

    Actually, the real wtf with Java Boolean is the public constructor. Why would you ever need to define a new Boolean? I've lost count of the number of times I've had to change new Boolean("TRUE") to Boolean.TRUE when maintaining someone else's code.

    The reason? new Boolean("TRUE") breaks the equality operation.

    System.out.println(new Boolean("tRuE") == Boolean.TRUE); // displays false System.out.println(Boolean.valueOf("tRuE") == Boolean.TRUE); /// displays true System.out.println((new Boolean("tRuE")).booleanValue() == Boolean.TRUE.booleanValue()); // displays true

  • caper (unregistered)

    When might you attempt to find the truth of "0.0" ?

    Arbitrary strings should have some other test applied. Arbitrary floating point numbers should have some other tests applied.

  • ell0bo (unregistered) in reply to JDeepBeep
    JDeepBeep:
    benryves:
    I still haven't worked out why, when performing int-string comparisons, PHP performs an int-int comparison (changing the code to (string)$a == $b causes it to work as you'd expect).

    How about this one?

    var_dump("0123" == 123); //outputs bool(true)

    I have obviously been programming PHP for far too long when I can look at your comments and simply think "so what is your point". You are using ==, not ===, so it's going to type caste the string to an int, and thus it matches. Maybe I need to start playing with C++ again so I remember how much fun it is to micro manage all those little things.

  • (cs)
  • anonymous_coder() (unregistered) in reply to GreenGecko
    GreenGecko:
    Dirge:
    Back to the original topic, I suspect that the "guru" was an old-school programmer. Someone already suggested COBOL, but I remember the $a, $b (or $x, $y) thing from back in the olden days of 1980s BASIC as well. Maybe it was a holdover from math training? I even had a teacher back then who would use $left and $right any time he needed two variables, regardless of whether handedness was even vaguely involved in the program logic.

    Obviously not a fortran programmer, or it'd be i,j,k... for integers

    Oh lord, I still do that. Guess it shows my age, and the fact that I first learned serious coding in Fortran. On a System/36. In the snow, uphill both ways, etc. etc. etc.

    Still, it makes it bloody obvious what a loop variable is - and there's no need for VariableWithVeryLongNameThatIsUsedToIterateOverThisArrayBackwards--;, and other such absurdities.

  • kevin (unregistered) in reply to Buddy

    Strings evaluate to true except for 0 and empty (no value). Not that complicated.

    Besides, why would anyone in their right mind do conversions like that?

  • Buddy (unregistered) in reply to Procedural

    Look, PHP is okay for simple things. IMHO PHP5 was a bad idea -- it encourages you to write OO, but as soon as try to implement a simple Factory pattern it falls apart.

    Anything more complicated than screen-scraping is a waste of time in PHP.

  • Cooksey (unregistered)

    This is some "my-tee-fine" [tm] self documenting code...

    function ICouuldBeaMoran($lhs,$rhs);

    The only question is was he more on or off ?

    And my favorite:

    This function return a value. <-- also written by gurus.

  • Buddy (unregistered)

    One guy I know uses only three character parameters and variable names and reuses temporary variables so that $tmp can be a string, then an integer, then something else during the course of one function. When I talk to him about maintainability, he feigns a language gap and pretends not to understand.

  • (cs) in reply to ell0bo
    ell0bo:
    I have obviously been programming PHP for far too long when I can look at your comments and simply think "so what is your point"

    I have obviously been programming in PHP for too long also, and this is why I brought that out. It is a classic example of what confuses those not expecting that for a result. No need to be defensive dude.

  • (cs) in reply to Buddy
    Buddy:
    When I talk to him about maintainability, he feigns a language gap and pretends not to understand.

    You do what now?

  • Some Wonk (unregistered) in reply to OldHand
    OldHand:
    I have the feeling I once had this deja vu experience of seeing some similar code...

    I have the feeling I have seen this comment before.

  • (cs) in reply to anonymous_coder()
    anonymous_coder():
    GreenGecko:
    Dirge:
    Back to the original topic, I suspect that the "guru" was an old-school programmer. Someone already suggested COBOL, but I remember the $a, $b (or $x, $y) thing from back in the olden days of 1980s BASIC as well. Maybe it was a holdover from math training? I even had a teacher back then who would use $left and $right any time he needed two variables, regardless of whether handedness was even vaguely involved in the program logic.

    Obviously not a fortran programmer, or it'd be i,j,k... for integers

    Oh lord, I still do that. Guess it shows my age, and the fact that I first learned serious coding in Fortran. On a System/36. In the snow, uphill both ways, etc. etc. etc.

    Still, it makes it bloody obvious what a loop variable is - and there's no need for VariableWithVeryLongNameThatIsUsedToIterateOverThisArrayBackwards--;, and other such absurdities.

    i,j,k are also taught to C/C++ programmers as variable names for trivial iterators

Leave a comment on “Can You Say Your $a, $b, $c's?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article