The Long Glow

« Return to Article
  • ParkinT 2012-05-31 07:44
    Derek was probably paid a salary.
    The "old-timer" was paid by total SLOC count.

    {And I get paid for being FIRST}
  • first 2012-05-31 09:21
    So a piece of functioning but long-winded code was refactored by a junior developer. And the WTF is?
  • Blargles 2012-05-31 09:24
    first.visible := false;
    second.visible := false;
    third.visible := false;
    fourth.visible := false;
    fifth.visible := false;
    sixth.visible := true;

    Also, is this Pascal? Or is there some new Pascal-looking language out there?
  • WolfMoon 2012-05-31 09:27
    It's definitely Turbo Pascal. Delphi to be more precise.
  • Arrghhh me head hurts... 2012-05-31 09:27
    Blargles:
    first.visible := false;
    second.visible := false;
    third.visible := false;
    fourth.visible := false;
    fifth.visible := false;
    sixth.visible := true;

    Also, is this Pascal? Or is there some new Pascal-looking language out there?


    Looks like Delphi.
  • TheSHEEEP 2012-05-31 09:27
    "Image4.Visible := t = 1;"

    Yuck.

    Every "x = y" where x ends up not being y is scary, to say the least.
  • Thomas 2012-05-31 09:28
    Looks like Delphi to me.
  • Sizik 2012-05-31 09:45
    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;".
  • Derek 2012-05-31 09:49
    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!
  • arh 2012-05-31 09:52
    first:
    So a piece of functioning but long-winded code was refactored by a junior developer. And the WTF is?


    The WTF is that they seemed spending a lot of time reminding the junior developer that he was a junior, and then scoffing at him when he optimized their code. That's exactly the kind of "mentors" you'd like to avoid.
  • Flash 2012-05-31 09:58
    '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.
  • nonpartisan 2012-05-31 10:00
    ParkinT:
    Derek was probably paid a salary.
    The "old-timer" was paid by total SLOC count.

    {And I get paid for being FIRST}

    So why should the old timer be annoyed? He got his pay. And a professional programmer like that can just massage new code into 500 lines where 50 would do.
  • Callin 2012-05-31 10:07
    We don't take too kindly to your optimization around here. You best learn your place fast, son.
  • Vroomfundel 2012-05-31 10:11
    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)
  • ochrist 2012-05-31 10:15
    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.
  • anon 2012-05-31 10:16
    I noticed that on many of the companies projects used the same pattern where the main window five different buttons and three stock photos.


    Who proofreads these articles?
  • Hmmmm 2012-05-31 10:24
    anon:
    Who proofreads these articles?

    Nagesh, by the look of it...
  • Roby McAndrew 2012-05-31 10:26
    I can see this from both sides.

    I remember being young and keen, and thinking "Hey, I can do this a lot more concisely".

    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.

    We all josh the junior and as long as it is "all in good fun" where's the harm? Having your code précised to this degree would be kind of irritating, and I might well have a bit of grumble.
  • n/a 2012-05-31 10:31
    anon:
    I noticed that on many of the companies projects used the same pattern where the main window five different buttons and three stock photos.


    Who proofreads these articles?


    Older and more experienced editors, obviously.
  • Bob 2012-05-31 10:46
    Some languages use = for both comparison and setting. This is generally considered bad.

    Most languages, including Pascal, don't. This is generally considered good.

    Many languages resolve this by using == for comparison but some don't. This is generally considered irrelevant.

    Many people can only understand what they're used to. This is generally considered stupid.
  • name 2012-05-31 10:55
    Bob:
    Some languages use = for both comparison and setting. This is generally considered bad.

    Most languages, including Pascal, don't. This is generally considered good.

    Many languages resolve this by using == for comparison but some don't. This is generally considered irrelevant.

    Many people can only understand what they're used to. This is generally considered stupid.


    Wise words.
    You have my respect.
  • Mike 2012-05-31 10:57
    Image4.Visible = (1 == t);

    The real wtf is default control names
  • meh 2012-05-31 11:01
    Bob:
    Some languages use = for both comparison and setting. This is generally considered bad.

    Most languages, including Pascal, don't. This is generally considered good.

    Many languages resolve this by using == for comparison but some don't. This is generally considered irrelevant.

    Many people can only understand what they're used to. This is generally considered stupid.


    I wish the last statement would be true...
  • meh 2012-05-31 11:02
    meh:
    I wish the last statement would be true...


    err, was! was true!
    phew, saved it.
  • gramie 2012-05-31 11:05
    This IS Delphi code, and the problem you C/Java/etc. coders have with the "=" and "==" may be because you don't know Pascal syntax:

    a := 'Bob'
    assigns the value 'Bob' to the variable 'a'.
    (note the ':=' as the assignment operator)

    a = 'Bob'
    checks for equality.
  • toshir0 2012-05-31 11:05
    Roby McAndrew:
    The old code is verbose, but it's not THAT ugly and unmaintainable.
    Ok, now try to actually *look* at this fucking rotten pile of ugliness again and do apologize to us all.

    Roby McAndrew:
    Cutting and pasting working code to get unchanged functionality is kind of good practice.
    Ok, you got me. Obvious troll is obvious, I know...
  • James C. L. 2012-05-31 11:08
    While it depends on the environment, the first version looks to be more efficient. It only sets values if things have changed. The second version by Derek, while more concise, will be called every time the mouse moves on the form, doing the same comparisons, and setting values. It may not make a difference, again depending on the environment. On the developer's machine, it might be fine, but when the office assistant runs the program, the form may blink every time she moves the mouse.

    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. In the current case, I'd probably go with a switch, though. Not sure you want to be clear and efficient, though. That's pushing it.
  • toshir0 2012-05-31 11:09
    Bob:
    Some languages use = for both comparison and setting. This is generally considered bad.

    Most languages, including Pascal, don't. This is generally considered good.

    Many languages resolve this by using == for comparison but some don't. This is generally considered irrelevant.

    Many people can only understand what they're used to. This is generally considered stupid.
    Generally, general statements are bullshit.

    (lol as much as you want at this recursive stupidity, but I *heard* it said on TV some years ago, as confidently as anything, by a person I *used* to like much before the very saying of this sentence...)
  • M 2012-05-31 11:10
    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. <i>IT is change</i>; either embrace it or get left behind.
  • Chelloveck 2012-05-31 11:14
    Bob:
    Many people can only understand what they're used to. This is generally considered stupid.


    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.

    "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."

    Amazing what some of these old timers think they know...

    Me, I'm just happy that it's 2012 and I can finally start using some of the constructs presented in the C99 spec.
  • maw 2012-05-31 11:15
    In VB it would be
    "Image4.Visible = t = 1"
    Scary.
  • Your Name 2012-05-31 11:18
    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".
  • Yazeran 2012-05-31 11:28
    maw:
    In VB it would be
    "Image4.Visible = t = 1"
    Scary.


    Ok THIS (if true) is by far the worst thing I have heard of VB (I have personally never written anything in VB and now I want to even less...)

    Yazeran

    Plan: To go to Mars one day with an hammer.
  • Martin 2012-05-31 11:29
    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.


    ?
  • callcopse 2012-05-31 11:30
    James C. L.:
    While it depends on the environment, the first version looks to be more efficient. It only sets values if things have changed. The second version by Derek, while more concise, will be called every time the mouse moves on the form, doing the same comparisons, and setting values. It may not make a difference, again depending on the environment. On the developer's machine, it might be fine, but when the office assistant runs the program, the form may blink every time she moves the mouse.

    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. In the current case, I'd probably go with a switch, though. Not sure you want to be clear and efficient, though. That's pushing it.


    Pretty sure that the redraw will not occur if the visibility is simply set to what it is already, though you'd need to verify. Even if that was not the case that would be no excuse for the impenetrable and unnecessary length of the original.

    For me, I would be fine with a parenthesised version like so:
    Image4.Visible := (t = 1);

    I'd probably include a comment as a clear statement of intent too.
  • Tasty 2012-05-31 11:37
    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!
  • wolfi 2012-05-31 11:58
    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!

    ever heard Wirth ranting about C++?
    he seems to be very convinced about the superiority of his languages
  • Nagesh 2012-05-31 12:14
    Chelloveck:
    Bob:
    Many people can only understand what they're used to. This is generally considered stupid.


    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.

    "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."

    Amazing what some of these old timers think they know...

    Me, I'm just happy that it's 2012 and I can finally start using some of the constructs presented in the C99 spec.


    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 Spalsky and mr Skeet (A.S.S) team will get this point.
  • Old Delphi fellow 2012-05-31 12:16
    TImage(Sender).Tag;


    For this single line You will be fired in my company...
    We already have too much problems with "smart" developers and very "creative" ways to use TComponent.Tag

    Mapping Button => Image should be hold in other collection, and whole code should be moved to procedure in utils.
  • Dave 2012-05-31 12:18
    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.
  • Jack 2012-05-31 12:21
    TheSHEEEP:
    "Image4.Visible := t = 1;"

    Yuck.

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

    Do all programming languages that you don't know scare you?
  • Old Delphi fellow 2012-05-31 12:24
    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.


    ?


    Most property setters (property Visible => setter SetVisible()) in Delphi VCL is intelligent enough to do not trigger updates if new value is same like old one.

    So setting Visible to "true" in component which is already visible, will do nothing more than simple condition check.
  • Nagesh 2012-05-31 12:29
    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.


    ?


    Look at the functions called. The original code is only called when the mouse moves over an image.

    The new code is called every time the mouse moves

  • jMerliN 2012-05-31 12:47
    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 prefer my ===, TYVM!
  • Jack 2012-05-31 12:47
    Image4.Visible := t = 1;

    OK I don't know Pascal or Delphi, so I'm just going to take a guess at the array syntax, but why wouldn't you simply

    Image[t].Visible := 1;

    after clearing the entire array, of course?
  • Jack 2012-05-31 12:49
    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.
  • not frits at all 2012-05-31 13:00
    So, in this notation, "=" means ?
    Σ(n=0 to ∞) x^n
  • D-Coder 2012-05-31 13:04
    wolfi:
    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!

    ever heard Wirth ranting about C++?
    he seems to be very convinced about the superiority of his languages
    With regards to C++, he's right.
  • Mason Wheeler 2012-05-31 13:24
    Blargles:
    first.visible := false;
    second.visible := false;
    third.visible := false;
    fourth.visible := false;
    fifth.visible := false;
    sixth.visible := true;

    Also, is this Pascal? Or is there some new Pascal-looking language out there?


    If by "new" you mean "17 years old and used by millions of developers worldwide" then yes, I suppose there is. :P
  • Mason Wheeler 2012-05-31 13:25
    ...and just because no one's posted it yet:


    Image1.Visible := true;
    Image2.Visible := false;
    Image3.Visible := file_not_found;
  • bob 2012-05-31 13:28
    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 2012-05-31 13:30
    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.
  • lanmind 2012-05-31 13:31
    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...
  • lanmind 2012-05-31 13:34
    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 2012-05-31 13:39
    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 2012-05-31 13:44
    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 2012-05-31 13:44
    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 2012-05-31 13:53
    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. 2012-05-31 13:53
    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.
  • snoofle 2012-05-31 13:55
    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 2012-05-31 13:55
    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 2012-05-31 13:57
    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 2012-05-31 13:59
    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 2012-05-31 14:01
    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?
  • Code Slave 2012-05-31 14:02
    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 2012-05-31 14:10
    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 2012-05-31 14:19
    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 :)
  • KattMan 2012-05-31 14:21
    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 2012-05-31 14:31
    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 2012-05-31 14:38
    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. <i>IT is change</i>; 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. 2012-05-31 14:38
    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 2012-05-31 14:44
    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 2012-05-31 15:00
    [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 2012-05-31 15:07
    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.

  • Matt Westwood 2012-05-31 15:09
    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.
  • Matt Westwood 2012-05-31 15:16
    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 2012-05-31 15:18
    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 2012-05-31 15:32
    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 2012-05-31 15:33
    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 2012-05-31 16:11
    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 2012-05-31 16:22
    Jack:
    I'm pretty sure before programming, there was no concept of "assignment" in mathematics.


    y = 12x
    evaluate for x = 3.
  • Jack 2012-05-31 16:23
    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 2012-05-31 16:55
    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 2012-05-31 16:57
    Apparently he didn't learn the "if it ain't broke, don't fix it" lesson.
  • Gunslinger 2012-05-31 16:59
    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 2012-05-31 17:00
    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 2012-05-31 17:01
    Mike:
    Image4.Visible = (1 == t);

    The real wtf is default control names


    Like and +1.
  • Peter 2012-05-31 17:05
    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 2012-05-31 17:15
    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 2012-05-31 17:34
    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 2012-05-31 17:34
    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 2012-05-31 17:53
    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 2012-05-31 18:13
    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.
  • Silverhill 2012-05-31 18:28
    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 2012-05-31 18:29
    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 2012-05-31 18:56
    Pretty sure this is Ada code.
  • [] 2012-05-31 18:57
    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? 2012-05-31 19:00
    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...
  • lanmind 2012-05-31 19:03
    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 2012-05-31 19:06
    That's a very strange way to implement a Semafor.

    /YoureDoingItWrong
  • lanmind 2012-05-31 19:11
    KattMan:
    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.


    I'm not sure what you find contradictory. First, I say that VB - or any language - allowing you to do that is retarded. And it is. Then I go on to say that the need for separate operators is retarded. Some languages make you do that, but not VB. So... I'm talking about different things here. Clearer?
  • close 2012-05-31 19:14
    Matt Westwood:
    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.

    German = Ja
    Russian = да

    etc....

    Spanish = Si
  • Jack 2012-05-31 19:15
    You sure?:
    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...
    No, those are definitions. They must not change within the context of your formula, or proof, or whatever it is.

    But maybe the difference is too subtle. And it's all semantic, anyway.
  • Jack 2012-05-31 19:17
    Spewin Coffee:
    That's a very strange way to implement a Semafor.

    /YoureDoingItWrong

    Speaking of which, who spells it "semafor"?
  • [] 2012-05-31 19:43
    Jack:
    Spewin Coffee:
    That's a very strange way to implement a Semafor.

    /YoureDoingItWrong

    Speaking of which, who spells it "semafor"?


    Someone who doesn't know how to spell "semafour".
  • toshir0 2012-05-31 20:40
    Peter:
    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.
    FTFY.

    Btw, seems 1.2/3 to me.
  • Chris Lively 2012-05-31 21:16
    You could have simply placed all of the buttons on a TPanel and the stock photos on another TPanel.

    Then you could loop through all of the controls on each panel and never worry about having to modify the function..


    procedure TForm2.ImageMouseMove
    (Sender: TObject; Shift: TShiftState; X, Y: Integer);
    var
    t : integer;
    comp : TComponent;
    begin
    t := TImage(Sender).Tag;
    for comp in MyButtonPanel.Controls do
    begin
    comp.Visible := (comp.Tag = t);
    end;

    for comp in MyPhotosPanel.Controls do
    begin
    comp.Visible := (comp.Tag = t);
    end;
    end;


    Then again I haven't used Delphi in over a decade.
  • ozzie 2012-05-31 22:12
    Jack:
    Image4.Visible := t = 1;

    OK I don't know Pascal or Delphi, so I'm just going to take a guess at the array syntax, but why wouldn't you simply

    Image[t].Visible := 1;

    after clearing the entire array, of course?


    This isn't using arrays, the original statement is basically along the lines of:

    if (t = 1) set Image4.Visible to true,
    else set Image4.Visible to false

    CAPTHCHA: transverbero - A noun that's had a sex change?
  • PiisAWheeL 2012-05-31 22:25
    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've been known to cut and paste, but I usually cut and paste for reference. Not because I'm going to use the code, but because I did something awesome and I needed to reference what I did to duplicate it properly elsewhere.

    And 1 time, I coded a 30 line function in javascript, And got it right the first time. I began to question if i was god. I haven't been able to do it since, so yes... The first draft tends to be a little rough around the edges 99 percent of the time.
  • Gert 2012-05-31 22:39
    I don't think that's correct Nagesh.


    procedure TForm2.ImageMouseMove
    (Sender: TObject; Shift: TShiftState; X, Y: Integer); var t : integer; begin

    // glow "buttons"
    t := TImage(Sender).Tag;


    The procedure is named IMAGEMOUSEMOVE, and the first thing he does is determine which image caused the event handler to fire; we don't have the code that he uses to assign events to this handler, but I'm guessing he assigns all the Image control's "MouseMove" events to this one handler, which is why he needs to firstly determine the sender with

    t := TImage(Sender).Tag;

    This is a pretty common practice in .NET as well.
  • sfs 2012-06-01 00:45
    James C. L.:
    While it depends on the environment, the first version looks to be more efficient. It only sets values if things have changed. The second version by Derek, while more concise, will be called every time the mouse moves on the form, doing the same comparisons, and setting values.

    Stop. Just stop. This is a totally bullshit evaluation of relative performance. We're not talking PHP or Ruby that just derps along. Delphi compiles to native code.

    Also, Derek's code has no branches, so there will be no lost cycles when the processor misses a branch prediction. Derek's code is also much smaller, and thus more cache-friendly.

    More to the point, however, you haven't *profiled* the code, so you really don't know. Derek's 14-line function is readable, clear, and far more maintainable than the original 280-line monster. If the 14-liner is a performance problem, it can be solved by adding an extra check to see if "t" changed. That makes it probably... 15-20 lines, which is more than 14, but far less than 280.

    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.

    Seriously, how long have you been coding? The "BOOL_FUNC := BOOL_EXPR;" idiom is really common, and once you recognize it, the intent is just as clear as the verbose "if BOOL_EXPR then BOOL_FUNC := true;"
  • No Name Arsehole 2012-06-01 01:46
    dogmatic:
                        TForm1(FindComponent('Image'+k)).Visible := false;
    
    TForm1(FindComponent('Button'+k+'On')).Visible := false;
    (...)
    TForm1(FindComponent('Image'+senderIndex)).Visible := true;
    TForm1(FindComponent('Button'+senderIndex+'On')).Visible := true;

    Just because RTTI exists, doesn't mean you have to (ab)use it for everything.

    This whole thing would be much easier solved by just implementing a custom glow button (or using one of the million different ones already implemented).
  • Wim 2012-06-01 02:33
    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.
    And why is the new code in that way better? The new code fails your criteria in my opinion. It is not easy to understand (no comments :)) A bug is more easily found in the first version, because there it is easy to follow what is happening, so changes are easier and it is more maintainable.
    I must admit, I like the new code better.
  • George 2012-06-01 02:42
    Chelloveck:
    Bob:
    Many people can only understand what they're used to. This is generally considered stupid.


    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.

    "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."

    Amazing what some of these old timers think they know...

    Me, I'm just happy that it's 2012 and I can finally start using some of the constructs presented in the C99 spec.


    It is a stylistic choice. Neither approach is good or bad. When you work on a legacy code base with others you sometimes need to adopt the prevalent sytle to maintain readability even if you prefer a different style of doing things.
  • George 2012-06-01 02:53
    Scrummy:

    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.


    The first draft is only shit if you throw analysis and system design out the window and jump straight into hammering out code so that some pointy headed boss can jump straight to micromanaging the crap out of you with lttle pieces of paper on a board. Wait, that is exactly what scrum and agile development is. Nevermind.
  • Derek 2012-06-01 02:53
    "Visible" although it looks like variable is actually property, which means it is just automatic wrapper for getter and setter. Thus no blinking will occure, the setter looks like this:


    procedure TControl.SetVisible(Value: Boolean);
    begin
    if FVisible <> Value then
    begin
    ...actual visibility change
    end;
    end;
  • hyperly 2012-06-01 04:09
    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.


    Congratulations. You're the first person in a looooong while to get a featured comment.

    (looking at the general level of the commentary here, I'm not surprised)
  • dkf 2012-06-01 06:55
    Gunslinger:
    Looks like another great reason to stay away from Python.
    You need no reason other than the derp-y GIL to avoid Python. Putting a busy do-nothing loop in parallel speeds things up!? Trying to kill things makes it all worse? TRWTF…
  • Steve The Cynic 2012-06-01 08:16
    Code Slave:
    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);

    Take a closer look at your version of the strcpy trick... It doesn't work because you left the ++ off dest.

    And (just entering the willy-waving contest for a moment) it has more parens than it needs.

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


    This is what you want, except that in the real world, only the people who write strcpy itself should possibly be worried about this. Everyone else should just call strcpy.

    And either nobody else noticed, which is disappointing, or nobody else cared enough to comment, which is more disappointing.
  • Not Nagesh 2012-06-01 08:56
    close:


    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.


    That's right. Languages like FORTRAN and Perl are just as good as Java and C#, so really no reason to have more than one. Why did Wirth invent Pascal anyway? So 30 years later, people on the Internet could cite his name when arguing the merits of his syntax selection.
  • Nagesh 2012-06-01 10:01
    Why ain't Alex massaging another article yet?
  • Sectoid Dev 2012-06-01 10:29

    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.

    "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."



    My current "team lead" also told me to use if/else blocks instead of ?: His rationale was that it would make porting our entire Perl code base to C much easier if the need ever arose.

    I've stopped listening to anything he has said since.

    Yes, I know TRWTF := Perl
  • Shinobu 2012-06-01 10:55
    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.
    There can be no confusion, since assignment is a statement, whereas comparison can only occur in expressions. This is the reason why VB doesn't have or need horrible kludges like := or == and if you don't know this, you have no business coding in the language. It's always the first thing you do when you meet a new language: study the syntax.
    KattMan:
    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".
    There is no such thing. The statement here is If (hence not an assignment) and is followed by an expression. VB is immune to C's if(x = y) bug since assignment is a statement.
    People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.
  • Scrummy 2012-06-01 10:56
    George:
    Scrummy:

    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.


    The first draft is only shit if you throw analysis and system design out the window and jump straight into hammering out code so that some pointy headed boss can jump straight to micromanaging the crap out of you with lttle pieces of paper on a board. Wait, that is exactly what scrum and agile development is. Nevermind.


    The task board is a perfect metaphor for tracking work to be done. People who fear openness and accountability often poke fun at the task board. Some of us prefer to build code on time, that works, rather than hide behind project managers when the failures that were baked into the GANNT chart are realized. This is why we ship software that meets users' needs, instead of releasing a year late with features that were obsolete 1 month into the 6-month analysis phase.
  • Shinobu 2012-06-01 11:06
    Chelloveck:
    x = (a > b) ? a : b;
    The ( ) are superfluous in that statement. It's precisely because of this intended use of the ? : operator that its precedence level is just above = and that all other operators apart from , have higher precedence.
  • M 2012-06-01 11:30
    Shinobu:
    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.
    There can be no confusion, since assignment is a statement, whereas comparison can only occur in expressions. This is the reason why VB doesn't have or need horrible kludges like := or == and if you don't know this, you have no business coding in the language. It's always the first thing you do when you meet a new language: study the syntax.
    KattMan:
    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".
    There is no such thing. The statement here is If (hence not an assignment) and is followed by an expression. VB is immune to C's if(x = y) bug since assignment is a statement.
    People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.


    VB doesn't have horrible kludges....right.

    Dim x As Integer = 10
    Dim y As Integer = 20
    Dim z As Integer = 20
    x = y = z

    What is x now?
    x is -1, y and z are unchanged.

    I much prefer C#'s transitive assignment to that kludge. Booleans aren't integers.
  • CharlesFoxston 2012-06-01 11:36
    The world is full of dinosaurs. I was sacked from one job because my boss, being an ex-programmer, had a "been there, seen it, done it" attitude towards everything.

    "I was coding when you were a baby!", he would roar, before chuckling to himself and hauling his heavy mass through the office.

    Being a true Microsoft fan-boy, I enjoyed using Visual Studio, and love the way other companies spend a lot of money researching more intuitive ways of using the IDE, much to my boss' chagrin. One day he had had enough. He caught me with my licensed version of ReSharper, and promptly fired me for "disruptive behaviour". I probably shouldn't have called him out about his experience with .NET but I hate those poor souls who are so desperate to appear superior to everyone else.

    It is the way of the world, with some of those left after the .com bubble burst spending all their times thinking of the good old days when they were paid ridiculous sums for nothing. Thankfully, I now contract and see less bad practice but this particular TDWTF reminded me of this encounter.

    Last I heard, the company had closed down.
  • tego 2012-06-01 11:40
    M:
    Shinobu:
    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.
    There can be no confusion, since assignment is a statement, whereas comparison can only occur in expressions. This is the reason why VB doesn't have or need horrible kludges like := or == and if you don't know this, you have no business coding in the language. It's always the first thing you do when you meet a new language: study the syntax.
    KattMan:
    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".
    There is no such thing. The statement here is If (hence not an assignment) and is followed by an expression. VB is immune to C's if(x = y) bug since assignment is a statement.
    People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.


    VB doesn't have horrible kludges....right.

    Dim x As Integer = 10
    Dim y As Integer = 20
    Dim z As Integer = 20
    x = y = z

    What is x now?
    x is -1, y and z are unchanged.

    I much prefer C#'s transitive assignment to that kludge. Booleans aren't integers.

    Don't know much about the internal storage representation of variables, I suppose?
  • marty 2012-06-01 11:42
    A witty, funny, non-frist post, first post. Awesome.
  • null 2012-06-01 11:43
    So TRWTF is that they didn't store all the button/image names in XML, amirite? :)

    CAPTCHA 'illum', I feel illum when I lookum at this copypaste code.
  • it's friday 2012-06-01 11:51
    AN AMAZING CODER:
    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",
    <snip>

    I'd say absolutely not. The "agile" procedures at my last job included an emphasis on test-driven development, and no checking code into version control until it's been seen by a second person, either via pair programming or informal peer review. As I understand it, the rationale is, we haven't got a proper spec, so WHEN the requirements change next week, we aren't going to be slowed down by shit code.
  • Martin 2012-06-01 12:09
    Nagesh:
    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.


    ?


    Look at the functions called. The original code is only called when the mouse moves over an image.

    The new code is called every time the mouse moves



    Really? I kinda thought


    procedure TForm2.ImageMouseMove


    would get called... exactly when the mouse moves over an image.
  • David 2012-06-01 12:34
    Shinobu:
    VB is immune to C's if(x = y) bug since assignment is a statement.


    If you do not know how to use (let alone exploit) a language feature, that does not make that feature a bug.

    Criticizing a language you clearly do not understand does, however, make you at the very least an incompetent critic.

    Shinobu:
    People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.


    If "people are always quick to dismiss VB" could that perhaps be because its defenderz are always so utterly full of shit?
  • Mason Wheeler 2012-06-01 12:58
    Shinobu:
    There is no such thing. The statement here is If (hence not an assignment) and is followed by an expression. VB is immune to C's if(x = y) bug since assignment is a statement.
    People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.

    "Better" depends on your basis for comparison.

    Having said that, most experienced programmers do not consider context-sensitive semantics (such as the same operator doing completely different things depending on the code around it) "better" than context-free semantics.
  • Paul Neumann 2012-06-01 13:17
    lanmind:
    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...
    Yeah, and languages which need special operators to denote the difference between functional arguments and the next expression.
  • Your Name 2012-06-01 13:21
    Well, the young whippersnapper's "solution" is certainly dysfunctional. It is hard on the seasoned programmers' mental faculties, leading to increased TCO and reduced ROI. In short, it is not enterprisey. Also, any and all capabilities to customize the individual buttons with funny copy-paste-stale-bugs are not provided. PHB not like dat.
  • Paul Neumann 2012-06-01 13:26
    Roby McAndrew:
    M:
    Roby McAndrew:
    Blah


    Blah? blah. blah!


    Are you a moron? I thought anyone could see from a million miles across that it was a sarcastic comment.
    Troll status: FAIL!
    It is considered bad form to bash the starfish over the head when they first bite. Drag them along for a few comments and cause some emotional trauma first, at least.
  • dogmatic 2012-06-01 13:58
    No Name Arsehole:
    dogmatic:
                        TForm1(FindComponent('Image'+k)).Visible := false;
    
    TForm1(FindComponent('Button'+k+'On')).Visible := false;
    (...)
    TForm1(FindComponent('Image'+senderIndex)).Visible := true;
    TForm1(FindComponent('Button'+senderIndex+'On')).Visible := true;

    Just because RTTI exists, doesn't mean you have to (ab)use it for everything.

    This whole thing would be much easier solved by just implementing a custom glow button (or using one of the million different ones already implemented).


    Err that's why I recommended using a button class, but since from the looks of their code they've never seen a class nor would know what to do with it, the code was an example of the least he could do to clean up that mess without too much refactoring.
  • AN AMAZING CODER 2012-06-01 14:33
    Shinobu:
    Chelloveck:
    x = (a > b) ? a : b;
    The ( ) are superfluous in that statement. It's precisely because of this intended use of the ? : operator that its precedence level is just above = and that all other operators apart from , have higher precedence.


    But it's way easier to read with the ( ) than without. Which is why you should add them.

    Yes, any experienced coder can figure it out if they stop and think about it, but the less stopping and thinking you have to do, the more time you can spend coding (and the easier it will be to spot bugs).


    I'm sure you could solve this equation:

    10 + 11 / 12 * 17 ^ 2 - -3 * 15

    But wouldn't it be 20 times easier if you didn't have to navigate order of operations in your head?
  • Roger Garrett 2012-06-01 15:53
    I wish the last statement were true.

    When used in a hypothetical statement (as in a "wish") the word "were" is used instead of "was".
  • Roger Garrett 2012-06-01 15:57
    We need a new construct in software. When you cut and paste the pasted code maintains a link back to the original so that when a change is made to the original it automatically is reflected in the corresponding pasted code.

    What fun THAT would produce!
  • Shark8 2012-06-01 16:25
    Roger Garrett:
    We need a new construct in software. When you cut and paste the pasted code maintains a link back to the original so that when a change is made to the original it automatically is reflected in the corresponding pasted code.

    What fun THAT would produce!


    You mean generics?
    Or did you mean that you want it to update the original code when the copy-pasted version is updated (and obviously breaking the links to it from other instances of copy-pastism)?
  • foo 2012-06-01 19:13
    Peter:
    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.
    Of course, you're right, since you're apparently a bot.

    A human, in contrast, would understand context. The point was about maintainability of the old code. The fact that someone rewrote it completely is not exactly an argument in favour, even though in both cases the verb "change" was used.

    Sorry, please update your semantics database to v0.2.
  • Nickster 2012-06-02 09:58
    M:
    VB doesn't have horrible kludges....right.
    ...
    I much prefer C#'s transitive assignment to that kludge. Booleans aren't integers.


    Explain your logic there.

    1) YourLang doesn't work the same way as MyLang
    2) I prefer how MyLang works.
    3) YourLang is a kludge.
  • M 2012-06-02 12:52
    Nickster:
    M:
    VB doesn't have horrible kludges....right.
    ...
    I much prefer C#'s transitive assignment to that kludge. Booleans aren't integers.


    Explain your logic there.

    1) YourLang doesn't work the same way as MyLang
    2) I prefer how MyLang works.
    3) YourLang is a kludge.


    It has nothing to do with my language preference. Yes, I happend to prefer C#, but I use several languages daily, including VB.NET.

    It's a combination of things, perhaps to subtle for you:

    First, as has been pointed out, the = operator performs different tasks depending on context. You could call this alone a kludge, but let's continue on. Secondly vb requires option strict to use strong typing. This line will either give an answer or fail to compile based on a setting somewhere else in the code. Again, this seems rather 'kludgy, but maybe acceptable to those who prefer weak typed languages or came from the old vb world and have trouble learning new things. Lastly, if option strict is not set, the code compiles and gives the value -1 for x. The value -1 is dependent on the internal representation of a boolean from pre-.net vb, while .net booleans DON'T ACTUALLY USE THAT REPRESENTATION. Convert from bool to int using .net framework methods and you get a different value. - kludge, kludge, kludge.
  • bkDJ 2012-06-02 13:29
    Either younare being ridiculous or you're trolling. Your argument is BS, though. For one, the dot operator in C# does double duty of C++'s scope resolution operator :: and indirect member reference ->, and I'm sure there's a craggy developer out there who would complain that "the same operator accessing something on the heap and also accessing a static member" leads to horrible bugs, but I would take that statement as seriously as "assignment and comparison using the same operator is horrible and context sucks". You know what language you're dealing with, so you should know its strengths and weaknesses.

    Also, -1 is just all bits turned on, but who cares as long as it's not zero. It's your own fault for putting an implicit cast from bool to int in the code. If you want an int to be a certain value based on a bool condition, use if/else or the ternary operator and stop whining about how bad you are at coding in a language you don't code in. Handy tip: no matter pre-.net, post-.net, ANSI C, or anything really: a false bool to int will be 0 and a true bool to int will be something that isn't zero.
  • Nickster 2012-06-02 15:17
    M:
    First, as has been pointed out, the = operator performs different tasks depending on context.

    Yes, and in C the * and & operators perform different tasks depending on context. That doesn't really keep you from understanding how they work.

    Secondly vb requires option strict to use strong typing. This line will either give an answer or fail to compile based on a setting somewhere else in the code.

    In C, you can also have a line that gives an answer or fails to compile based on a setting somewhere else in the code, depending on whether you included the right headers.

    Lastly, if option strict is not set, the code compiles and gives the value -1 for x. The value -1 is dependent on the internal representation of a boolean from pre-.net vb, while .net booleans DON'T ACTUALLY USE THAT REPRESENTATION.

    Okay, this one is actually pretty kludgey, but backward compatibility always is. IMHO the only real kludges are inconsistencies deliberately included to get around some quirk of the syntax and semantics, but as long as you understand the code you read and what it will do, it's manageable. Perhaps VB has more of this than other languages. I don't know it as well as you do, to be frank.
  • M 2012-06-02 19:15
    Nickster:
    Lastly, if option strict is not set, the code compiles and gives the value -1 for x. The value -1 is dependent on the internal representation of a boolean from pre-.net vb, while .net booleans DON'T ACTUALLY USE THAT REPRESENTATION.

    Okay, this one is actually pretty kludgey, but backward compatibility always is. IMHO the only real kludges are inconsistencies deliberately included to get around some quirk of the syntax and semantics, but as long as you understand the code you read and what it will do, it's manageable. Perhaps VB has more of this than other languages. I don't know it as well as you do, to be frank.


    I agree backwards compatibility is pretty much always messy. I'm not trying to say vb is worthless or anything of the kind. I was just responding to the post that said vb doesn't have or need kludges. It certainly does, but probably not much more than other languages. It's true I prefer C# to vb, but that's just my preference. I used to enjoy C++ but became spoiled by C# not needing header files. F# is a fun language as well with a some awesome features and probably a few wtf's.
  • Kuba 2012-06-03 01:43
    wolfi:
    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).

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

    ever heard Wirth ranting about C++?
    he seems to be very convinced about the superiority of his languages
    Say what you will about C++, but at least Pascal and Ada have proper modules. C++ doesn't, so you have include files, and to separate interface from implementation, and to maintain binary compatibility, there's this verbose abomination otherwise known as the PIMPL idiom. It's an abomination that not only makes you idly type silly getter/setter functions, but also makes every PIMPLed instance construction automatically allocate stuff on the heap, usually doubling the number of heap allocations. And if you care about performance, you can't use PIMPL at least for some members of the class, so you move them back to the private-yet-exposed interface file (a.k.a. header file). It's mind-numbingly dumb to even have to worry about such a thing, but hey, that's C++ for you.

    If Qt toolkit supported Pascal natively without using shims, I wouldn't be using C++.
  • My Name * 2012-06-04 17:12
    Silverhill:
    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, ..."


    Of course, the difference is in the scoping. There is no notion of "re-assignment", as it breaks referential transparency.

    In other words, equality and assignment are the same things. What you are calling "assignment" is taking a first-order sentence as an axiom in a proof or function.
  • My Name * 2012-06-04 17:38
    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.


    I would much rather see something like
      case1 ? action1
    
    : case2 ? action2
    : case3 ? action3
    ;

    (with sensible naming, given the context of the solution)

    than a verbose string of if-elsif-else's. Why? Because they are far more likely to fit on a single screen. Because it is trivial to add another case by simply adding another row. In other words, this construct maps cases to actions, and the implementation makes that clear. I don't care that the compiler will turn both into the same code. This is easier make sense of, even if it is not as "easy to read".

    Funny symbols are not the enemy. You can pretty much ignore them -- context makes their semantics transparent. Unnecessary explicit sequencing is the enemy.
  • not frits either 2012-06-09 08:18
    It may mean comparison, where you filter from all possible values from x^n those where it n equals a number from 0 to ∞, adding those values up. I’ve heard mathematicians do not think unlike Haskell programmers.
  • C 2012-06-10 09:16
    Jack:
    Image4.Visible := t = 1;

    OK I don't know Pascal or Delphi, so I'm just going to take a guess at the array syntax, but why wouldn't you simply

    Image[t].Visible := 1;

    after clearing the entire array, of course?
    Actually, no. The original code is better, it doesn't change visibilities unneedingly. Therefore, no flicker. [see image 5 in the following "Error'd"! :D]

    Also, no need for a separate list of images yet, but i suppose having many (more) buttons and many images might warrant it, but it still would be something like "for x:=1 to N do Image[x].Visible := t = x;".

    PS Your array syntax is fine, your boolean isn't. :p
  • Kevin Cline 2012-06-12 15:23
    Pascal was perfect in every way except that it was nearly unusable. C++ was horrible, but it was usable.
  • Someone 2012-06-12 18:51
    You must be new here. I became convinced long ago that typos and grammar errors must be intentionally inserted, because there isn't a single article without them.
  • not another Nagesh 2012-06-18 16:00
    If you cannot wrap your little twisted head around a simple concept such as the Ternari operator, please stop calling yourselves a programmer (never mind a software engineer).

    Thanks for playing.
  • Gumpy Gus 2014-05-27 11:28
    Needless to say it could be boiled down to one simple loop, as you can easily iterate through the form fields and set the flags, something like:

    for i := 1 to MainForm.FieldCount do
    with Form.Fields[ i ] do
    if Name = 'Button' + I2S( i ) then
    Visible := t = i;