• bob (unregistered) in reply to Roby McAndrew
    Roby McAndrew:
    I can see this from both sides. The old code is verbose, but it's not THAT ugly and unmaintainable. I guess it evolved that way. Cutting and pasting working code to get unchanged functionality is kind of good practice.

    I can't believe that people are defending the original code. It is completely atrocious. Duplication of substantially the same code with minor variations is always a bad smell. One reason is maintainability - if something needs to be changed it has to be done in mulitple places rather than one. The other is readability. There is so much noise there that it is difficult to see what the differences is between the cases. That not only makes it more likely that errors will be made but it also hides the intent of the code which is much clearer in the rewritten version.

    And BTW are you serious about cutting an pasting being good practice?

  • Scrummy (unregistered)

    Now if they were using Agile, it would be perfectly acceptable to write that code as it appeared originally, so long as it was eventually, and iteratively, refactored to Derek's solution.

  • (cs) in reply to maw
    maw:
    In VB it would be "Image4.Visible = t = 1" Scary.

    I didn't even know you could do that! But uh... I wouldn't. Anyone who uses this kind of structure is setting the project up for maintenance hell. TRWTF is any language that lets it be legal.

    Oh, and the the other TRWTF is languages that need special operators to tell the difference between assignment and comparison. Don't forget the "===" operator...

  • (cs) in reply to Scrummy
    Scrummy:
    Now if they were using Agile, it would be perfectly acceptable to write that code as it appeared originally, so long as it was eventually, and iteratively, refactored to Derek's solution.

    Sorry, try again. We've all dumped shit code into a project to get it out the door, but it isn't ever acceptable.

  • Gary (unregistered) in reply to Your Name
    Your Name:
    Roby McAndrew:
    Cutting and pasting working code to get unchanged functionality is kind of good practice.
    This is TRWTF. Cutting & pasting working code eventually turns into "several dozen similar, but not quite the same" versions. Then QA wonders why a bug is fixed "here", but not in the other 20 places where it exists. And then your manager wonders why it takes so long just to fix a simple bug.

    Cut/Paste <> Code Reuse. There's a reason most languages support references to libraries, or at the bare minimum you use an "include".

    YHBT. YHL. HAND.

  • foo (unregistered) in reply to Jack
    Jack:
    Vroomfundel:
    Actually the delphi syntax makes more sense - the '=' sign has been used to express equality, not assignment, long before C was invented (or computers altogether, for that matter). Using '==' for that TRWTF and if your early programming days were not that long ago you might remember mistakenly using = instead of ==, just because it's more natural - I'm pretty sure everyone does that (except people who use Pascal/Delphi, that is)
    I'm pretty sure before programming, there was no concept of "assignment" in mathematics.
    No, they're called "definitions" (and also use ":=").
  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    TRRRWTF is that this thing has five buttons numbered 4, 9, 11, 7, and 5, in that order. Seriously?

    The other RWTF is that these index numbers are hard-coded into variable names, rather than being enumerated constants used as indexes into an array or similar kind of collection. Magic numbers are bad, mmmkay, but magic numbers hard-coded into variable names are worse.

  • foo (unregistered) in reply to James C. L.
    James C. L.:
    Also, I personally don't like the pattern of setting a value to the result of a comparison (Image4.Visible := t = 1;). It may be concise, but it isn't clear. Its not that hard, or that much more code to actually use an if statement, but its tons clearer.
    Quite the opposite: With an if statement, you have to verify that both branches set the same variable (and remember to change it in two places instead of one if you ever need to), and you'll mentally conflate it to the more concise expression when you try to understand it.

    "Image4.Visible := t = 1;" is perfectly clear once you're familiar with Boolean values and get used to treating them as first-class values. I.e., don't think of it as a case-distinction (even if the generated code may contain one, but that's the compiler's job, not yours), but think of it as a simple assignment: The visibility of the image (a Boolean value) is simply the condition "t = 1".

  • James C. L. (unregistered) in reply to Martin
    Martin:
    Remind again how this:
    begin Image4.Visible := true; Image9.Visible := false; Image11.Visible := false; Image7.Visible := false; Image5.Visible := false;
      Image2.Visible := true;
      Image8.Visible := true;
      Image10.Visible := true;
      Image6.Visible := true;
      Image3.Visible := true;
    
      Image12.Visible := true;
      Image13.Visible := false;
      Image14.Visible := false;
    
      semafor_pic1 := true;
      semafor_pic2 := false;
      semafor_pic3 := false;
      semafor_pic4 := false;
      semafor_pic5 := false;
    end;
    
    James C. L.:
    only sets values if things have changed.

    ?

    I'd be happy to. If you include the full text of the procedure you should notice something.

    if semafor_pic1 <> True then begin Image4.Visible := true; Image9.Visible := false; Image11.Visible := false; Image7.Visible := false; Image5.Visible := false;
      Image2.Visible := true;
      Image8.Visible := true;
      Image10.Visible := true;
      Image6.Visible := true;
      Image3.Visible := true;
    
      Image12.Visible := true;
      Image13.Visible := false;
      Image14.Visible := false;
    
      semafor_pic1 := true;
    
      semafor_pic2 := false;
      semafor_pic3 := false;
      semafor_pic4 := false;
      semafor_pic5 := false;
    end;
    
    There's an "if" statement. Does pretty much the same thing in every language I know. Not sure why he used "<>" every time or why he's comparing with a boolean, but that might just be a nuance of the language. Or something.
  • (cs) in reply to Flash
    Flash:
    'Phmph,' he grumbled, 'my way worked fine, too.'
    This old-timer just demonstrated that he hadn't learned an important lesson of writing software: that "working fine" is not enough. Our code has to be maintainable, too. It should be easy to understand for the next person who comes along. If there are bugs, they should be easy to find. If a change is needed, it should be easy to make.
    Not to defend the old timer's attitude or code, but from the story, it appeared that the code was relatively understandable for the next person who came along, who also appeared to have little trouble changing it.
  • Scrummy (unregistered) in reply to lanmind
    lanmind:
    Scrummy:
    Now if they were using Agile, it would be perfectly acceptable to write that code as it appeared originally, so long as it was eventually, and iteratively, refactored to Derek's solution.

    Sorry, try again. We've all dumped shit code into a project to get it out the door, but it isn't ever acceptable.

    The first draft of pretty much any code is shit. Agile just accepts that as a reality, and allows for making it better at an appropriate time. Otherwise, you're just fooling yourself.

  • n_slash_a (unregistered) in reply to TheSHEEEP
    TheSHEEEP:
    "Image4.Visible := t = 1;"

    Yuck.

    Every "x = y" where x ends up not being y is scary, to say the least.

    For easier debugging and possibly easier reading put // get which button is selected (1-5) // TODO: add an assert that only 1 button is selected bool is_button1_selected := (t = 1); bool is_button2_selected := (t = 2); bool is_button3_selected := (t = 3); bool is_button4_selected := (t = 4); bool is_button5_selected := (t = 5); // put a glow around the correct button // TODO: fix the default image names Image4.Visible := is_button1_selected; // first button Image9.Visible := is_button2_selected; // second button Image11.Visible := is_button3_selected; // third button Image7.Visible := is_button4_selected; // fourth button Image5.Visible := is_button5_selected; // fifth button // display the corresponding stock photo (for buttons 1-3 only) // TODO: fix the default image names Image12.Visible := is_button1_selected; // stock photo1 Image13.Visible := is_button2_selected; // stock photo2 Image14.Visible := is_button3_selected; // stock photo3

  • foo (unregistered) in reply to James C. L.
    James C. L.:
    There's an "if" statement. Does pretty much the same thing in every language I know. Not sure why he used "<>" every time or why he's comparing with a boolean, but that might just be a nuance of the language. Or something.
    So just add something like "if t <> last_t" around the new code (if it's actually an issue). It's much faster to do than all the bitching about this detail and it's irrelevant to the WTF of the original code.
  • foo (unregistered) in reply to snoofle
    snoofle:
    Flash:
    'Phmph,' he grumbled, 'my way worked fine, too.'
    This old-timer just demonstrated that he hadn't learned an important lesson of writing software: that "working fine" is not enough. Our code has to be maintainable, too. It should be easy to understand for the next person who comes along. If there are bugs, they should be easy to find. If a change is needed, it should be easy to make.
    Not to defend the old timer's attitude or code, but from the story, it appeared that the code was relatively understandable for the next person who came along, who also appeared to have little trouble changing it.
    So you have 1/3. What about the other two, finding bugs (esp. typos) and making changes?
  • (cs) in reply to Nagesh
    Nagesh:
    Chelloveck:

    I used to work in a C shop. All C, all the time. One of the old-timers complained when I used the '?:' conditional operator.

    x = (a > b) ? a : b;

    Like that, only with meaningful variable names.

    In my view, it is more sense making to have more lines of code for future maintenance guy to understand that code. The more cryptic code is difficult to understand. I am sure mr Atwood, mr [Ed]Spolsky and mr Skeet (A.S.S) team will get this point.

    Sadly, I find my self agreeing with someone identifying them self as Nagesh. Perhaps it's time to rethink my life. HOWEVER, the advantage that using the '?' operator does is it saves a bunch of space in your source file. The disadvantage being it makes the intentions of the statement cryptic. Kind of like the classic strcpy trick in C

    while (*dest = *(src++)) ;

    Perfectly valid... efficient... and it is important to understand how and WHY it works. However, so does:

    strcpy(dest,src);

    If you are wanting to a dick measuring contest by having the smallest most compact source code - great. But if you want to make it understandable to the next guy who's going to have to maintain it long after you are gone, don't be a dick. (full disclosure: I used to be one of those dicks)

    We're not working on PDP-11's any more. Memory and processor time is cheep. People's time is not. Chances are the processor is going to optimise:

    if (a > b)
    {
        x = a;
    }
    else
    {
        x = b;
    }
    

    the same way as the original example, any way.

  • Tom (unregistered) in reply to Code Slave
    Code Slave:
    We're not working on PDP-11's any more.
    Speak for yourself. I'm pretty sure we have one of everything around here. Including a PDP-11 I found humming along in a closet (and online) a couple years after its former owner moved to a different branch office.
  • Chandan (unregistered) in reply to first

    No the code was not just refactored but i am sure Derek would not go on copy n pasting the 280 lines everywhere but rather put it in a library n use it. The WTF is after more than 10 years of experience they preferred pasting 280 lines of code. or may be the WTF is it took Derek just 7 years to know what he was doing not up to the standards :)

  • (cs) in reply to lanmind
    lanmind:
    maw:
    In VB it would be "Image4.Visible = t = 1" Scary.

    I didn't even know you could do that! But uh... I wouldn't. Anyone who uses this kind of structure is setting the project up for maintenance hell. TRWTF is any language that lets it be legal.

    Oh, and the the other TRWTF is languages that need special operators to tell the difference between assignment and comparison. Don't forget the "===" operator...

    You seem to contridict yourself here. in VB you don't need an additional operator for assignment or comparison. The context of the "=" is what determines its function.

    In VB x=y=z the first = is always an assignment all following = are comparisons. this si always true. THe problem comes when there is an implied assignment, as in "If x=y Then" there is an implied assigment to a boolean resulting from the listed comparison of "x=y". This is where the confusion between assignment and comparison happens. But the rule stays the same, the first implied or literal "=" is always assignment, all other "=" is comparison when looking at a line in VB.

  • Ol' Bob (unregistered) in reply to Blargles

    Pascal? More like Delphi! Ah, great days - GREAT days! Back when men was men and women was women! Back when you could just go to the airport, WALK OUT RIGHT ON THE CONCOURSE with all the crew and the passengers and everyone, and you could meet people AS THEY GOT OFF THE PLANE! Back when you could drive to Canada JUST FOR THE HELL OF IT without a passport 'r nothin'! Back when, by God, you gave a man a rock and a club and pretty soon you'd be having yerself a wooly mammoth barbecue! Tough? Well, 'course it were tough - them beasts were migratory, y'know, but we had the teef fer it, back when!!! Not like the teef you get these days, no sirree, can't even chew a marshmallow with the teef you get today...<<mumble-mumble-mumble>>

  • Roby McAndrew (unregistered) in reply to M
    M:
    Roby McAndrew:
    Cutting and pasting working code to get unchanged functionality is kind of good practice.

    Not to be rude, but I can't disagree with this more. Cutting and pasting working code is a good way to introduce subtle bugs because you forgot to change the one variable that actually needed to be different. It also complicates things needlessly if the behavior ever needs to be changed globally.

    Good practice is: read the code, understand the code, rewrite the code. If you find similar code is needed in more than one place, you are missing a refactoring opportunity if you just cut and paste. Anyone who doesn't practice this should probably do the rest of us a favor and change careers. The old saying 'If it ain't broke, don't fix it' has no place in software development, or IT in general for that matter. IT is change; either embrace it or get left behind.

    Are you a moron? I thought anyone could see from a million miles across that it was a sarcastic comment.

  • James C. L. (unregistered) in reply to foo
    foo:
    James C. L.:
    There's an "if" statement. Does pretty much the same thing in every language I know. Not sure why he used "<>" every time or why he's comparing with a boolean, but that might just be a nuance of the language. Or something.
    So just add something like "if t <> last_t" around the new code (if it's actually an issue). It's much faster to do than all the bitching about this detail and it's irrelevant to the WTF of the original code.

    That's actually an excellent solution, and might do the trick. 2 things to remember, though:

    1. This is the dailywtf.com. "bitching about this detail" happens here. Get used to it.
    2. Changing the functionality of the code is a serious issue. I'm all for making code more concise, as long as its clear, and still does the same thing. The 2 versions in the article do not. It may not matter, depending on the environment, etc; but then again, it just might. Better check on that before you publish/deploy/etc the change.
  • Roby McAndrew (unregistered) in reply to bob
    bob:
    Roby McAndrew:
    I can see this from both sides. The old code is verbose, but it's not THAT ugly and unmaintainable. I guess it evolved that way. Cutting and pasting working code to get unchanged functionality is kind of good practice.

    I can't believe that people are defending the original code. It is completely atrocious. Duplication of substantially the same code with minor variations is always a bad smell. One reason is maintainability - if something needs to be changed it has to be done in mulitple places rather than one. The other is readability. There is so much noise there that it is difficult to see what the differences is between the cases. That not only makes it more likely that errors will be made but it also hides the intent of the code which is much clearer in the rewritten version.

    And BTW are you serious about cutting an pasting being good practice?

    I can't believe there is one more moron who knows enough to write a huge paragraph, but cannot comprehend obvious sarcasm.

  • M (unregistered) in reply to Roby McAndrew

    [quote user="Roby McAndrewI can't believe there is one more moron who knows enough to write a huge paragraph, but cannot comprehend obvious sarcasm. [/quote]

    I can certainly believe there is one more moron who has yet to learn that sarcasm isn't an automatic feature of the written word simply because they intended it to be. There are idiots who espouse things like copy & paste coding and even worse. So we're supposed you're not one of them, how exactly? Because of your genius wit? That is amusing...or wait, was THAT sarcasm? <--- That is sarcasm.

  • AN AMAZING CODER (unregistered) in reply to Scrummy
    Scrummy:
    lanmind:
    Scrummy:
    Now if they were using Agile, it would be perfectly acceptable to write that code as it appeared originally, so long as it was eventually, and iteratively, refactored to Derek's solution.

    Sorry, try again. We've all dumped shit code into a project to get it out the door, but it isn't ever acceptable.

    The first draft of pretty much any code is shit. Agile just accepts that as a reality, and allows for making it better at an appropriate time. Otherwise, you're just fooling yourself.

    Incorrect. You don't seem to under

    Agile is not meant to "make shitty code acceptable", it's meant to "make a project better over time". Making a project better over time ENTAILS making the code better over time, but doesn't mean it's ok to write shitty code that will slow the rate at which you can make the project better over time.

    You don't get better code by allowing shitty developers to write shitty code for someone else to fix (or break further) later. The point of going agile is to know that you don't have to have perfectly flawless code with all of the bells and whistles the first time, and spend 6 months building it just for the requirements to change 4 weeks in.

  • (cs) in reply to Tasty
    Tasty:
    Sizik:
    TheSHEEEP:
    "Image4.Visible := t = 1;"

    Yuck.

    Every "x = y" where x ends up not being y is scary, to say the least.

    In other languages, that'd be "Image4.Visible = t == 1;".

    Wirth deliberately gave Pascal those operators as a teaching tool. Assignment is not commutative and the colon in a := b; makes that clear. Equality is a single = in ordinary algebra, where (a = b) is the same as (a = b).

    Just because something is not common doesn't mean it's not better!

    French is rubbish because they say "oui" rather than "yes". German is not quite as rubbish because they say "yah" rather than "yes" which is nearly "yes" so it's not quite as rubbish. Russian is really rubbish because they say "dah" rather than "yes". Spanish is quite rubbish because they say "see" when they mean "yes". American is really rubbish because they say "yo", "yep", "yeah", "yup" and all sorts of other silly things when they mean "yes".

    See that paragraph above I just wrote? That's you stupid fucking programmers arguing about which of your stupid fucking programming languages is the best. Fuck off and sweep streets the fucking lot of you cunts.

  • (cs) in reply to Code Slave
    Code Slave:
    Nagesh:
    Chelloveck:

    I used to work in a C shop. All C, all the time. One of the old-timers complained when I used the '?:' conditional operator.

    x = (a > b) ? a : b;

    Like that, only with meaningful variable names.

    In my view, it is more sense making to have more lines of code for future maintenance guy to understand that code. The more cryptic code is difficult to understand. I am sure mr Atwood, mr [Ed]Spolsky and mr Skeet (A.S.S) team will get this point.

    Sadly, I find my self agreeing with someone identifying them self as Nagesh. Perhaps it's time to rethink my life. HOWEVER, the advantage that using the '?' operator does is it saves a bunch of space in your source file. The disadvantage being it makes the intentions of the statement cryptic. Kind of like the classic strcpy trick in C

    while (*dest = *(src++)) ;

    Perfectly valid... efficient... and it is important to understand how and WHY it works. However, so does:

    strcpy(dest,src);

    If you are wanting to a dick measuring contest by having the smallest most compact source code - great. But if you want to make it understandable to the next guy who's going to have to maintain it long after you are gone, don't be a dick. (full disclosure: I used to be one of those dicks)

    We're not working on PDP-11's any more. Memory and processor time is cheep. People's time is not. Chances are the processor is going to optimise:

    if (a > b)
    {
        x = a;
    }
    else
    {
        x = b;
    }
    

    the same way as the original example, any way.

    What you do to make it readable is package it up into a function "max (a, b)" and then you only have to write it once. Then it can be as longwindedly-written as you like - or leave it as it is and comment it.

    As for the "strcpy trick": fail. Put it in a function with a meaningful name, pricklips.

  • Nickster (unregistered) in reply to Chelloveck
    Chelloveck:
    "What's this? That's not even legal C, that's just a proprietary compiler extension! What do you mean, 'it is legal'? Prove it! So what if it's in Kernighan and Ritchie? Who are they? Anyway, no one understands it. You need to change it to an if..else block."

    I got an answer: "How about NO?"

    "x = (a > b) ? a : b; is legal, it's clear, it's concise, it's standard, it's well established...and if you didn't learn it by your third day of studying C, you are a shitty excuse for a C programmer, so STFU before I kick you in the nuts!"

  • dogmatic (unregistered)

    Wow, both versions are a bit hideous. The second, while more compact isn't betterer because it fires every single time the mouse moves over the form, which should cause performance issues. I haven't used Pascal since a course in junior high in the 80s which is where code like this should've stayed. I just checked and yes Delphi actually does have classes.

    //TODO: Give Image1...100 meaningfuller names like Button1Off, Button1On, Picture1, etc. //TODO: Store view elements in arrays and assign mouse event handling logic in a for loop. //TODO: Perhaps create a generic button class that internally handles on/off/selected logic.

    Pseudo code (I don't know Delphi, but you should get the idea...):

         
    buttonCount = 4;
    begin
        For i := 0 to buttonCount do
            procedure TForm1.ImageMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer); begin
                For k := 0 to buttonCount do
                    begin
                        TForm1(FindComponent('Image'+k)).Visible := false;
                        TForm1(FindComponent('Button'+k+'On')).Visible := false;
                    end;
                
                //Get index from Sender name
                senderName = TEdit(Sender).Name;
                //Sender should be named something like 'Button1', this should strip 'Button' and 'Off' leaving the '1'
                senderIndex = StringReplace(StringReplace(senderName, 'Button', ''), 'Off', '');
                
                TForm1(FindComponent('Image'+senderIndex)).Visible := true;
                TForm1(FindComponent('Button'+senderIndex+'On')).Visible := true;
            end;
    end;
    
  • Scrummy (unregistered) in reply to AN AMAZING CODER
    AN AMAZING CODER:

    Incorrect. You don't seem to under

    Agile is not meant to "make shitty code acceptable", it's meant to "make a project better over time". Making a project better over time ENTAILS making the code better over time, but doesn't mean it's ok to write shitty code that will slow the rate at which you can make the project better over time.

    You don't get better code by allowing shitty developers to write shitty code for someone else to fix (or break further) later. The point of going agile is to know that you don't have to have perfectly flawless code with all of the bells and whistles the first time, and spend 6 months building it just for the requirements to change 4 weeks in.

    I would suggest that you are deluding yourself if you think the first cut of your code in a small sprint is good. It is perfectly OK to just get something out there that meets the stakeholders' needs. That's why we have refactoring. As long as your system is sufficiently orthogonal, making improvements in the shitty parts are easy.

  • Jack (unregistered) in reply to foo
    foo:
    Jack:
    Vroomfundel:
    Actually the delphi syntax makes more sense - the '=' sign has been used to express equality, not assignment, long before C was invented (or computers altogether, for that matter). Using '==' for that TRWTF and if your early programming days were not that long ago you might remember mistakenly using = instead of ==, just because it's more natural - I'm pretty sure everyone does that (except people who use Pascal/Delphi, that is)
    I'm pretty sure before programming, there was no concept of "assignment" in mathematics.
    No, they're called "definitions" (and also use ":=").
    Definition is not the same as assigment. A definition should never change (within a given scope).

    On a side note, I doubt that ":=" was used much before computers (or at least before type writers). Why compound two symtols when you can just as easily draw a new one? (Such as "≡", which is also used for definition.) I don't really know the history, though.

  • PeanutNoir (unregistered) in reply to Jack
    Jack:
    I'm pretty sure before programming, there was no concept of "assignment" in mathematics.

    y = 12x evaluate for x = 3.

  • Jack (unregistered) in reply to Code Slave
    Code Slave:
    Nagesh:
    Chelloveck:

    I used to work in a C shop. All C, all the time. One of the old-timers complained when I used the '?:' conditional operator.

    x = (a > b) ? a : b;

    Like that, only with meaningful variable names.

    In my view, it is more sense making to have more lines of code for future maintenance guy to understand that code. The more cryptic code is difficult to understand. I am sure mr Atwood, mr [Ed]Spolsky and mr Skeet (A.S.S) team will get this point.

    Sadly, I find my self agreeing with someone identifying them self as Nagesh. Perhaps it's time to rethink my life. HOWEVER, the advantage that using the '?' operator does is it saves a bunch of space in your source file.

    Are there really that many people, who are likely to see it, that don't understand that operator? I thought it was common knowledge, but who knows.

    Anyway, I prefer Python's version:

    x = a if a > b else b

    It's a little easier to figure out if you've never seen it before.

  • M (unregistered) in reply to Jack
    Jack:
    Code Slave:
    Nagesh:
    Chelloveck:

    I used to work in a C shop. All C, all the time. One of the old-timers complained when I used the '?:' conditional operator.

    x = (a > b) ? a : b;

    Like that, only with meaningful variable names.

    In my view, it is more sense making to have more lines of code for future maintenance guy to understand that code. The more cryptic code is difficult to understand. I am sure mr Atwood, mr [Ed]Spolsky and mr Skeet (A.S.S) team will get this point.

    Sadly, I find my self agreeing with someone identifying them self as Nagesh. Perhaps it's time to rethink my life. HOWEVER, the advantage that using the '?' operator does is it saves a bunch of space in your source file.

    Are there really that many people, who are likely to see it, that don't understand that operator? I thought it was common knowledge, but who knows.

    Anyway, I prefer Python's version:

    x = a if a > b else b

    It's a little easier to figure out if you've never seen it before.

    One detail about C#'s conditional operator is that it is an expression, not a statement.

    In C++ you might see

    someFlag ? Foo() : Bar();

    but that code would not compile in C#.

  • Gunslinger (unregistered)

    Apparently he didn't learn the "if it ain't broke, don't fix it" lesson.

  • Gunslinger (unregistered) in reply to Derek
    Derek:
    OMG, they posted it. I submited this code about month ago, I thought it wasn't good enough, perhaps it took them that long just to decipher my non-native-english. Thanks!

    It took that long to figure out how to edit in a real WTF.

  • Trollface.png (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    If by "new" you mean "17 years old and used by millions of dinosaurs that won't evolve worldwide" then yes, I suppose there is. :P

    Fixed that for you. Problem?

  • Gunslinger (unregistered) in reply to Mike
    Mike:
    Image4.Visible = (1 == t);

    The real wtf is default control names

    Like and +1.

  • Peter (unregistered) in reply to foo
    foo:
    snoofle:
    Flash:
    This old-timer just demonstrated that he hadn't learned an important lesson of writing software: that "working fine" is not enough. Our code has to be maintainable, too. It should be easy to understand for the next person who comes along. If there are bugs, they should be easy to find. If a change is needed, it should be easy to make.
    Not to defend the old timer's attitude or code, but from the story, it appeared that the code was relatively understandable for the next person who came along, who also appeared to have little trouble changing it.
    So you have 1/3. What about the other two, finding bugs (esp. typos) and making changes?
    I make that 2/3.
  • Gunslinger (unregistered) in reply to Jack
    Jack:
    Code Slave:
    Nagesh:
    Chelloveck:

    I used to work in a C shop. All C, all the time. One of the old-timers complained when I used the '?:' conditional operator.

    x = (a > b) ? a : b;

    Like that, only with meaningful variable names.

    In my view, it is more sense making to have more lines of code for future maintenance guy to understand that code. The more cryptic code is difficult to understand. I am sure mr Atwood, mr [Ed]Spolsky and mr Skeet (A.S.S) team will get this point.

    Sadly, I find my self agreeing with someone identifying them self as Nagesh. Perhaps it's time to rethink my life. HOWEVER, the advantage that using the '?' operator does is it saves a bunch of space in your source file.

    Are there really that many people, who are likely to see it, that don't understand that operator? I thought it was common knowledge, but who knows.

    Anyway, I prefer Python's version:

    x = a if a > b else b

    It's a little easier to figure out if you've never seen it before.

    Looks like another great reason to stay away from Python.

  • Kevin Cline (unregistered) in reply to Roby McAndrew

    I can't see both sides. Yes, it is that ugly, and it will be expensive to maintain: hours instead of minutes. If someone asked me to modify it, I would do the same as the poster, and I have much more than ten years of experience.

    Eventually the cost of maintaining a pile of WTF puts companies out of business. Then the cut-and-paster gets laid off and never works as a programmer again.

  • Larry (unregistered) in reply to Jack
    Jack:
    Anyway, I prefer Python's version:
    x = a if a > b else b
    As usual, Perl is best:
    x = a unless b > \\&$${${ref[$_#$&(#&*)&$&I(U&**(((LOST CARRIER
  • F (unregistered) in reply to Tasty
    Tasty:
    ... Wirth deliberately gave Pascal those operators as a teaching tool. Assignment is not commutative and the colon in a := b; makes that clear. Equality is a single = in ordinary algebra, where (a = b) is the same as (a = b).

    Well, yes. I hope I never have to deal with a language where (a = b) is different from (a = b).

  • Kevin Cline (unregistered) in reply to James C. L.

    It's perfectly clear to me; I hate using an if statement to test the value of a boolean and then return that very same value.

  • (cs) in reply to Jack
    Jack:
    I'm pretty sure before programming, there was no concept of "assignment" in mathematics.
    Au contraire. "For a right circular cylinder of radius 3, ..."
  • Muzer (unregistered) in reply to Dave
    Dave:
    meh:
    meh:
    I wish the last statement would be true...

    err, was! was true! phew, saved it.

    It was alright as it was. You unwittingly used the subjunctive which, while rare these days, is perfectly valid and in fact rather elegant.

    Surely the subjunctive would be "I wish the last statement were true". "Would be true" is, as far as I can see with my limited knowledge of grammar, indeed ungrammatical.

  • Nolte (unregistered)

    Pretty sure this is Ada code.

  • [] (unregistered) in reply to ochrist
    ochrist:
    Derek:
    OMG, they posted it. I submited this code about month ago, I thought it wasn't good enough, perhaps it took them that long just to decipher my non-native-english. Thanks!

    No, that's just because Alex is an older, more experienced programmer and wants you to know your place.

    Wait a minute, i'm noticing a pattern here. Does every comment with the word "Alex" in it get made a featured comment :)

  • You sure? (unregistered) in reply to Jack
    Jack:
    Vroomfundel:
    Actually the delphi syntax makes more sense - the '=' sign has been used to express equality, not assignment, long before C was invented (or computers altogether, for that matter). Using '==' for that TRWTF and if your early programming days were not that long ago you might remember mistakenly using = instead of ==, just because it's more natural - I'm pretty sure everyone does that (except people who use Pascal/Delphi, that is)
    I'm pretty sure before programming, there was no concept of "assignment" in mathematics.
    Let p be a prime number Let i be square root of -1; Let x be an odd divisor of 12

    hmmm...sounds like assignment to me...

  • (cs) in reply to Scrummy
    Scrummy:
    AN AMAZING CODER:

    Incorrect. You don't seem to under

    Agile is not meant to "make shitty code acceptable", it's meant to "make a project better over time". Making a project better over time ENTAILS making the code better over time, but doesn't mean it's ok to write shitty code that will slow the rate at which you can make the project better over time.

    You don't get better code by allowing shitty developers to write shitty code for someone else to fix (or break further) later. The point of going agile is to know that you don't have to have perfectly flawless code with all of the bells and whistles the first time, and spend 6 months building it just for the requirements to change 4 weeks in.

    I would suggest that you are deluding yourself if you think the first cut of your code in a small sprint is good. It is perfectly OK to just get something out there that meets the stakeholders' needs. That's why we have refactoring. As long as your system is sufficiently orthogonal, making improvements in the shitty parts are easy.

    This is why I run screaming from liberals, Catholics, and Agile developers. Some of each category are just fine, even awesome, but the common example hasn't got a clue how fucked up their bad interpretation of the given paradigm is. If that isn't bad enough, they will defend their position to the death.

  • Spewin Coffee (unregistered)

    That's a very strange way to implement a Semafor.

    /YoureDoingItWrong

Leave a comment on “The Long Glow”

Log In or post as a guest

Replying to comment #:

« Return to Article