Comment On The Long Glow

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

{And I get paid for being FIRST}

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

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?

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

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.

"Image4.Visible := t = 1;"

Yuck.

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

Looks like Delphi to me.

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

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!

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.

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

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.

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

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 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?

anon:

Who proofreads these articles?

Nagesh, by the look of it...

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.

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.

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.

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.

Image4.Visible = (1 == t);

The real wtf is default control names

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:

I wish the last statement would be true...

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

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.

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

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.

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

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.

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 VB it would be
"Image4.Visible = t = 1"
Scary.

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

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.

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.

?

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.

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!

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

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.

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.

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.

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?

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.

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

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!

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?

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.

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

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.

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

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

   Image1.Visible := true;

   Image2.Visible := false;

   Image3.Visible := file_not_found;