• Sam (unregistered)

    Why didn't they just use Google's search API?

    .<

  • (cs) in reply to cod3_complete
    cod3_complete:
    ]

    HA yep there really are tons of l33t coders out there who genuinely believe that several statements packed on one line actually makes the code faster.

    Not to mention threadsafe.

  • captain obvious (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    I wonder if the author of this project is the same guy who wrote/customized my soon-to-be-ex employer's "ERP" (using that term loosely) system? While my project is written in VBScript and Classic ASP, the rest of the signs are pretty darn close.

    We need to shoot people like this, on sight. They ruin this field for the rest of us who actually know what the fuck we are doing.

    Sadly, at least half the people that recognise and say this are not much better themselves.

  • Daniel O'Connor (unregistered) in reply to Opie

    That's why simplexml and tidy are both available, now isn't it.

  • Jon (unregistered) in reply to Dave C.
    Dave C.:
    But I doubt there are "tons of 133t coders" who are old enough to even know what TRS stands for.
    It stands for Tandy Rules, Suckas!

    10 HOME 20 SWEET 30 GOTO 10

    10 Dude what's mine say? 20 Sweet what's mine say? 30 GOTO 10

    captcha: nulla

  • umm... (unregistered) in reply to Edward Royce
    Edward Royce:
    Dave C.:
    But I doubt there are "tons of 133t coders" who are old enough to even know what TRS stands for.
    It stands for...

    Actually what it stands for is:

    "You bought a TRS-80 Mod III with 16k RAM for $1,000 and the Commodore64 just came out? You're f**ked!"

    16K? pfff...high roller, I guess.

  • Mike K. (unregistered) in reply to Joon

    I'm impressed, no obscure TLA's, no misquoted Simpson's episodes, no accusations of incompitence, no grammatical abortions like "looks like it doesn't know there ass from a whole in teh ground". Instead, just good solid advice on how to code well.

    I for one, read this site to learn what not to do. I've been doing this stuff for a long time and I still occassionally find examples of things I have done before.

    It amazes me that those who instantly resort to nastiness can't see just how foolish and insecure they look. They'll be the first ones to blame a PM or business owner for bad direction when they're caught doing something stupid. And every one of us, without exception, will at some point be caught doing something stupid.

    Thanks for the good post.

  • Mike K. (unregistered) in reply to Joon
    Joon:
    nanoman:
    jumentum (tego):
    ... and YOU call YOURSELF a programmer??

    I don't know what YOU do for living, but if you code every day, you can't remember any detail of how you implemented things without taking a long, deep look at it.

    I must disagree. If you wrote your code well in the first place, you, or any other programmer, should be able to come back in 1 or 2 or 10 year's time and still understand what it is meant to do.

    And by "writing your code well" I mean: Process:

    • Document your architecture, not your implementation
    • Don't fall for NIH

    Code:

    • Define and stick to project standards. You should have standards for code format, implementation conventions, naming standards, architecture etc.
    • Comment only your intent
    • Use descriptive variable and procedure names
    • Write well factored code that does not duplicate things all over the show

    Case in point: not using the Quote feature.

  • Edward Royce (unregistered) in reply to umm...
    umm...:
    Edward Royce:
    Dave C.:
    But I doubt there are "tons of 133t coders" who are old enough to even know what TRS stands for.
    It stands for...

    Actually what it stands for is:

    "You bought a TRS-80 Mod III with 16k RAM for $1,000 and the Commodore64 just came out? You're f**ked!"

    16K? pfff...high roller, I guess.

    Yeah. Thought I was l33t for about 6 days. Then it was "WTF? You can program colors?!".

  • Matthew (unregistered) in reply to I walked the dinosaur
    I walked the dinosaur:
    That's exactly cleaner than some php code...and it's in a class!!!

    I was thinking, "Heh, this looks like all the PHP code I've ever seen. What's the big deal? At least it isn't full of HTML."

  • anonymous coward (unregistered) in reply to Matthew
    Matthew:
    I walked the dinosaur:
    That's exactly cleaner than some php code...and it's in a class!!!

    I was thinking, "Heh, this looks like all the PHP code I've ever seen. What's the big deal? At least it isn't full of HTML."

    Yeah, that's exactly what I was thinking about. In fact, quite a while ago I had to secure/bugfix a PHPNuke portal. This stuff is just so monstrous ( plain old php+html+sql spaghetti with unescaped GET/POST variable all over the place ) that there is a third-party tool called "fortress" ( smells like scriptkiddies stuff, heh ? ), which blindly tries to remove sql injections from get parameters, and still leaves huge holes in POST and cookies parameters. And I'm pretty sure one can find plenty of similar horrors in either commercial or free software. Compared to that, this PHP code snippet just looks average and boring.
  • (cs)

    For me, the gem has to be this line:

    if (substr($u,0,4)==='/url') ...

    I don't know under what undocumented circumstances substr() would return a type other than string, and even then, how whatever it returned instead could still == '/url'.

    As much as I like PHP, part of me screams that "===" is TRWTF anyway -- functions that can return 0 or false, and you need a dedicated operator to figure out what you got.

    As much as some people here loathe Perl, I'm finding far fewer genuinely stupid ideas like that in Perl. One strange gotcha is this:

    someFunc($a, $q->param('does not exist'), $c);

    You'd expect this to evaluate to the following:

    someFunc($a, undef, $c);

    but since actual parameters to a function are nothing more than a list, CGI::param detects list context and returns an empty array, so you get:

    someFunc($a, (), $c);

    which is the same as:

    someFunc($a, $c);

    Suddenly, your function has argument 3 where 2 should be, and argument 3 is missing.

  • (cs) in reply to Daniel Beardsmore
    Daniel Beardsmore:
    For me, the gem has to be this line:

    if (substr($u,0,4)==='/url') ...

    I don't know under what undocumented circumstances substr() would return a type other than string, and even then, how whatever it returned instead could still == '/url'.

    As much as I like PHP, part of me screams that "===" is TRWTF anyway -- functions that can return 0 or false, and you need a dedicated operator to figure out what you got.

    As much as some people here loathe Perl, I'm finding far fewer genuinely stupid ideas like that in Perl. One strange gotcha is this:

    someFunc($a, $q->param('does not exist'), $c);

    You'd expect this to evaluate to the following:

    someFunc($a, undef, $c);

    but since actual parameters to a function are nothing more than a list, CGI::param detects list context and returns an empty array, so you get:

    someFunc($a, (), $c);

    which is the same as:

    someFunc($a, $c);

    Suddenly, your function has argument 3 where 2 should be, and argument 3 is missing.

    Seconded. Well, I'm not going to test it out, but seconded anyway, because Perl does this sort of thing all too often. It'll be fixed in Perl 6, or so a man in a dark alley told me once.

    It's a multiple cock-up, really. Whereas the parameters to a function are (obviously) presented as a list, this surely does not mean that they should be individually evaluated in a list context. Thus, it really should be undef and not "an empty list."

    Next up, we have Perl's notorious list-flattening mechanism. Any other language would treat the (erroneous) empty list as a reference to an empty list in this context ... which, happily, would have the same result as the intuitive behaviour, in all but corner cases.

    This stuff happens all too frequently, largely because of Perl's supposed willingness to "do what you wanted to do" without complaining. Good concept, but slightly flawed when it actually does something radically different from what you wanted to do.

    I've lost count of the number of times I get caught out when interpolating some trivial Perl expression like $q->param('Urban Spaceman'), only to see gibberish like HASH(0xC34A701) appear in the output. These days, I just hoist anything and everything into a local variable ... not significantly slower, much clearer, and makes debugging with something like Komodo a hell of a lot easier.

  • (cs)

    Something I nearly wrote but didn't -- as I felt I'd only get flamed again -- was that in BBC BASIC, functions had no defined return type. Instead of DEF FNfoo$ or DEF FNbar%, functions could return whatever they felt like. I thought that this silliness was just a limitation of the 16 k paged slot for BASIC, but apparently Perl's CGI took this idea to heart. A function that can return either a list or a scalar to me is simply broken.

    You do have to be extremely careful with references. A reference to an empty list equates to true in boolean context and passes defined(), but contains nonsensical data if you were looking for a scalar. This is where your nice undef (e.g. disabled or not-completed HTML field) would end up "HASH(0xC34A701)".

    Overall, though, I am really enjoying Perl. I should have learnt Perl a long time ago!

Leave a comment on “A Rather Minor Change”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article