• (cs)

    Derek was probably paid a salary. The "old-timer" was paid by total SLOC count.

    {And I get paid for being FIRST}

  • first (unregistered)

    So a piece of functioning but long-winded code was refactored by a junior developer. And the WTF is?

  • Blargles (unregistered)

    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 (unregistered)

    It's definitely Turbo Pascal. Delphi to be more precise.

  • Arrghhh me head hurts... (unregistered) in reply to Blargles
    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 (unregistered)

    "Image4.Visible := t = 1;"

    Yuck.

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

  • Thomas (unregistered)

    Looks like Delphi to me.

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

    Yuck.

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

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

  • Derek (unregistered)

    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!

  • (cs) in reply to first
    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.

  • (cs)
    '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.
  • (cs) in reply to ParkinT
    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.

  • (cs)

    We don't take too kindly to your optimization around here. You best learn your place fast, son.

  • Vroomfundel (unregistered) in reply to TheSHEEEP

    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)

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

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

  • anon (unregistered)
    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 (unregistered) in reply to anon
    anon:
    Who proofreads these articles?
    Nagesh, by the look of it...
  • (cs)

    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 (unregistered) in reply to anon
    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 (unregistered) in reply to TheSHEEEP

    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 (unregistered) in reply to Bob
    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 (unregistered)

    Image4.Visible = (1 == t);

    The real wtf is default control names

  • meh (unregistered) in reply to Bob
    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 (unregistered) in reply to meh
    meh:
    I wish the last statement would be true...

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

  • (cs)

    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.
  • (cs) in reply to Roby McAndrew
    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. (unregistered)

    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.

  • (cs) in reply to Bob
    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 (unregistered) in reply to Roby McAndrew
    Roby McAndrew:
    Cutting and pasting working code to get unchanged functionality is kind of good practice.

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

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

  • Chelloveck (unregistered) in reply to Bob
    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 (unregistered) in reply to Sizik

    In VB it would be "Image4.Visible = t = 1" Scary.

  • Your Name (unregistered) in reply to Roby McAndrew
    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".

  • (cs) in reply to maw
    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 (unregistered) in reply to James C. L.

    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.

    ?

  • (cs) in reply to James C. L.
    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 (unregistered) in reply to Sizik
    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 (unregistered) in reply to Tasty
    Tasty:
    Sizik:
    TheSHEEEP:
    "Image4.Visible := t = 1;"

    Yuck.

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

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

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

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

    ever heard Wirth ranting about C++? he seems to be very convinced about the superiority of his languages

  • (cs) in reply to Chelloveck
    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 (unregistered)
    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 (unregistered) in reply to meh
    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 (unregistered) in reply to TheSHEEEP
    TheSHEEEP:
    "Image4.Visible := t = 1;"

    Yuck.

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

    Do all programming languages that you don't know scare you?

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

    ?

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

    ?

    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 (unregistered) in reply to Vroomfundel
    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 (unregistered) in reply to TheSHEEEP
    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 (unregistered) in reply to Vroomfundel
    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 (unregistered)

    So, in this notation, "=" means ? Σ(n=0 to ∞) x^n

  • (cs) in reply to wolfi
    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.

  • (cs) in reply to Blargles
    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

  • (cs)

    ...and just because no one's posted it yet:

       Image1.Visible := true;
       Image2.Visible := false;
       Image3.Visible := file_not_found;
    

Leave a comment on “The Long Glow”

Log In or post as a guest

Replying to comment #:

« Return to Article