The Daily WTF: Curious Perversions in Information Technology

Airhead · 2010-01-25 Reply Admin

Steve the Cynic:
* Non-measurable-work. This requires the program to commit fiction, in that it cannot show its progress, because it has no idea how much progress it has made. This shouldn't ever happen. You can always report the number of megabytes copied, files deleted, fleens ogglefloggled, etc.

How about a web app doing something on the server side via ajax? Web app is just waiting for some response from server, but the progress cannot be measured on client side.

2010-01-25 Reply Admin

No-one has yet commented on the comments in the code. Those actually raise this code example from a mere "WTF" into actual good code.

The progress bar actually does what it was designed to do here, and the code documentation explains why. Nice job, actually.

-S

Kermos · 2010-01-25 Reply Admin

Fred:
Anonymous:
frits:
They must certainly be using Microsoft coding conventions with those stupid leading underscore member names.
What do you use? Our shop used to use m_xxx for members but we went over to the Microsoft conventions a while ago so now we use exclusively _xxx for members. This is an improvement if only because all member variables are one character shorter and minimising line length is fundamental to improving readability. It's a small improvement but an improvement nonetheless. So what's your solution, frits?

howabout not prefixing with anything?

Because not prefixing with anything gives you this issue:

Vector2::Vector2(int x, int y) : x(x), y(y) { }

Means you either have to prefix the member variables or prefix the parameters being passed in.

This on the other hand, has no such issue:

Vector2::Vector2(int x, int y) : m_x(x), m_y(y) { }

This is just one example where now prefixing your member variables can cause them to be shadowed by incoming parameters.

To me, using this->memberVar (or this. in case of .Net languages) is far more of a pain than prefixing with m_

2010-01-25 Reply Admin

There was a study done on this for for ACM [chrisharrison.net] where they found the user's favorite progress bar was one that slowly built up speed until 100%. The paper had some other recommendations on how code should do labor intensive work or network churning at the beginning so the end would appear quicker to the user but it was also interesting to see how much people HATED the wavy unpredictable version which is more like something that would match actual processing. So basically users should be lied to if possible.

snover · 2010-01-25 Reply Admin

http://www.goodiebag.tv/episodes/11_progress_bars.htm

I have nothing more to say.

2010-01-25 Reply Admin

howabout not prefixing with anything?

Because not prefixing with anything gives you this issue:

Vector2::Vector2(int x, int y) : x(x), y(y) { }

Means you either have to prefix the member variables or prefix the parameters being passed in.

This on the other hand, has no such issue:

Vector2::Vector2(int x, int y) : m_x(x), m_y(y) { }

This is just one example where now prefixing your member variables can cause them to be shadowed by incoming parameters.

To me, using this->memberVar (or this. in case of .Net languages) is far more of a pain than prefixing with m_

Coding standards are always a minefield of a debate -- and it always comes down to preference, to be honest I'm happy with prefixing member fields with '_', and using'this' on potential conflicts (thought not both at the same time, if you have ever experienced StyleCop)

I tend to do whatever resharper tells me to do (it auto prefixes 'this' when there is a conflict, and that only tends to be on the constructors with the dependency injections)

if _ is a coding standard at whatever place has to suffer me, I just set the resharper rules to prefix with '_'

2010-01-25 Reply Admin

Actually if you run Microsoft's StyleCop against the code, it will tell you off for using underscore prefixes; you should just use straight lowerUpper for field names and use "this" to access them.

2010-01-25 Reply Admin

Crinkle:
As others have pointed out this code is dumb, but the idea of giving the user an insight, even if it is almost entirely unrelated to what's actually happening, is fine.

If it is unrelated to what is happening, then you are NOT giving the user any "insight".

A progress bar distracts them enough to play nice. As long as it doesn't outright lie (i.e. 100% means done, 0% means starting, no change in progress bar means something's frozen up) it keeps resetting their ten second attention span.

Unfortunately, the usual behaviour for a progress bar is to run up to 98%, then just sit there un-moving. That is, it looks frozen even when it is still working. It meets your criteria for "outright lie".

Maybe I'm not a typical user, but to me "98% finished" implies "2% remaining". If the progress bar reaches 98% in 49 seconds, I damn well expect it to reach 100% in another 1 second. When it doesn't, the programmer who wrote that progress bar is lying to me.

At least a dancing icon doesn't promise anything about how much time is remaining. Of course, if it updates on a regular schedule, it looks like a separate thread that is unrelated to the (possibly hung) real work.

But if it updates irregularly it looks like it is connected to something that is actually happening. That gives the indication that it is not hung, without making any promises it can't keep.

2010-01-25 Reply Admin

How this probably came about:

Boss: We need a progress bar here. Programmer: But we can't know how far we have to go! Boss: We need a progress bar here.

2010-01-25 Reply Admin

Ocson:
Yet another tale of lowering the bar.

This.

Kermos:
Because not prefixing with anything gives you this issue:
Vector2::Vector2(int x, int y) : x(x), y(y) { }

Means you either have to prefix the member variables or prefix the parameters being passed in.

Ah, that problem. I solved it by, in only that one case (constructors with parameters that initialize members), suffixing the parameter name with an underscore:

Vector2::Vector2(int x_, int y_) : x(x_), y(y_) { }

As a bonus, it does not break your name sorting. And you avoid anything that even faintly smells of Hungarian Notation's evil form.

Kiss me I'm Polish · 2010-01-25 Reply Admin

The Microsoft Services Start/Stop progress bar has 3 steps. 0% - Prepare operation 50% - Send Start (or Stop) signal to service 100% - Service returns a value. Between these steps there is a time limit, so if a service doesn't start on time, the operation is aborted etc. Now for the progress bar - why not make it more proportional? Simply because it cannot be more proportional. This is used not only for native Windows services, but for 3rd party ones as well. There ARE situations when it's impossible to tell how much time you have left:

downloading an unknown size file (due to ftp server restrictions)
requesting information in a client-server architecture, where the server just works until it spits out a reply (hey Ajax)
waiting for a signal
processing a "while" loop. There is no way to tell how much iterations you need. What does your progress bar do?

In these cases all you can do is either show the user a "schmogress bar", or just tell him "we are working on this", with an animation of some sort. If you don't show anything, the user will think your app is frozen.

Now - to all that just don't like the idea of a throbber / "busy" animation and want to replace it all with a progress bar, go buy yourself a book.

frits · 2010-01-25 Reply Admin

I should really start using the new "sarcasm" mark (patent pending). Actually, I need a "flippant sarcasm" mark.

2010-01-25 Reply Admin

The Java way: JProgressBar.setIndeterminate().

public void setIndeterminate(boolean newValue) - Sets the indeterminate property of the progress bar, which determines whether the progress bar is in determinate or indeterminate mode. An indeterminate progress bar continuously displays animation indicating that an operation of unknown length is occurring. By default, this property is false.

GettinSadda · 2010-01-25 Reply Admin

Loading Comment:

0% [=====...............] 100%

2010-01-25 Reply Admin

Kermos:
Fred:

howabout not prefixing with anything?

Because not prefixing with anything gives you this issue:

Vector2::Vector2(int x, int y) : x(x), y(y) { }

Means you either have to prefix the member variables or prefix the parameters being passed in.

It means nothing of the sort. Assuming this is C++, there's no "issue" here that needs fixing - this code is correct, and does the right thing (i.e. initialises members "x" and "y" from arguments "x" and "y" respectively). The only "issue" arises when people don't believe this, and insist on decorating one or other with warts - in the worst case, as you propose, inflicting freaky pseudoHungarian prefixes on every member variable in the whole bloody world.

Erasmus Darwin · 2010-01-25 Reply Admin

Raw:
Actually, the Microsoft way it to have the bar asymptotically increase towards 100% on a timer, never really reaching it. When the task is done, they just slam it to 100% and finish. This is used, among other places, in Microsoft Access.

Zeno would be proud.

joeyadams · 2010-01-25 Reply Admin

Erasmus Darwin:
Raw:
Actually, the Microsoft way it to have the bar asymptotically increase towards 100% on a timer, never really reaching it. When the task is done, they just slam it to 100% and finish. This is used, among other places, in Microsoft Access.

Zeno would be proud.

A trivial port of the Microsoft progress bar algorithm to GTK:

#include <gtk/gtk.h>

struct state { int i; GtkProgressBar *progress_bar; };

static gboolean progress_timeout(struct state *state) { if (state->i < 100) { gtk_progress_bar_set_fraction(state->progress_bar, (gdouble)state->i / 100); } else if (state->i == 100) { gtk_progress_bar_set_text(state->progress_bar, "Finalizing..."); } else if (state->i == 238) { gtk_progress_bar_set_fraction(state->progress_bar, 1.0); gtk_progress_bar_set_text(state->progress_bar, "Finished"); } else if (state->i == 258) { gtk_main_quit(); } state->i++; return TRUE; }

int main(int argc, char *argv[]) { gtk_init(&argc, &argv);

GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL);

GtkWidget *vbox = gtk_vbox_new(FALSE, 0);
gtk_container_add(GTK_CONTAINER(window), vbox);
gtk_widget_show(vbox);

GtkWidget *hbox = gtk_hbox_new(FALSE, 0);
gtk_box_pack_start(GTK_BOX(vbox), hbox, TRUE, FALSE, 20);
gtk_widget_show(hbox);

GtkWidget *progress_bar = gtk_progress_bar_new();
gtk_progress_bar_set_text(GTK_PROGRESS_BAR(progress_bar), "Installing...");
gtk_box_pack_start(GTK_BOX(hbox), progress_bar, TRUE, TRUE, 20);
gtk_widget_show(progress_bar);

gtk_window_resize(GTK_WINDOW(window), 400, 200);
gtk_widget_show(window);

struct state state = {0, GTK_PROGRESS_BAR(progress_bar)};
g_timeout_add(50, (GSourceFunc)progress_timeout, &state);

gtk_main();
return 0;

}

2010-01-25 Reply Admin

Microsoft ARE guilty of doing something like this, though not quite as bad. Because Windows doesn't know how long a service will take to start, the progress bar progresses quickly to 50% and then progressses much slower over the remaining 50%. If at any point the service has finished starting then it jumps to 100% and then disappears.

They don't even attempt to estimate how long it takes based on previous times the same service started. Yet they still haven't replaced the progress bar with something indicating that it doesn't know how long it will take.

2010-01-25 Reply Admin

Microsoft ARE guilty

Sorry, I had to stop reading there. Microsoft is a corporation, which is a singular entity. We are not talking about the people that make up Microsoft, but the Microsoft corporation. The correct usage here is "Microsoft IS guilty".

Now back to your regularly scheduled commenting.

too_many_usernames · 2010-01-25 Reply Admin

Buffled:
Microsoft ARE guilty
Sorry, I had to stop reading there. Microsoft is a corporation, which is a singular entity. We are not talking about the people that make up Microsoft, but the Microsoft corporation. The correct usage here is "Microsoft IS guilty".
Now back to your regularly scheduled commenting.

Depends on the country. In the USA, companies are singular nouns. In England at least companies are plural nouns, so the GP would be consistent there.

2010-01-25 Reply Admin

trwtf is hungarian notation for .net

distineo: Neo's own spaceship for interstellar travel with a non-working stargate

2010-01-25 Reply Admin

Anon:
TRWTF:
SNIP

So I'm assuming PerformStep is supposed to prompt the GUI thread to force it to redraw, presumably with some kind of small delay (so you can see the intermediate steps), which means that this code forces the user to wait while the program does some pointless animation before it even starts doing the task. Start the task in another thread immediately and then play around with the progress bar while the task is being done.

And someone finally mentions the real problem! Congratulations!

It's totally asinine to do NOTHING while you're trying to pretend to do something instead of just doing the damn task already and possibly being finished before your stupid progress bar moves to make it look like you're doing work.

halcyon1234 · 2010-01-25 Reply Admin

GettinSadda:
Loading Comment:
0% [=====...............] 100%

{jiggles mouse}

2010-01-25 Reply Admin

Anonymous:
What do you use? Our shop used to use m_xxx for members but we went over to the Microsoft conventions a while ago so now we use exclusively _xxx for members. This is an improvement if only because all member variables are one character shorter and minimising line length is fundamental to improving readability.

I strongly disagree with that. As with everything else in engineering, it is a trade off: very long lines are unpleasant, but so are extremely short names for variables and functions. About half the screen width seems fine in most cases (unless you have a 30" Cinema Display...)

Coyne · 2010-01-25 Reply Admin

Loren Pechtel:
How this probably came about:
Boss: We need a progress bar here. Programmer: But we can't know how far we have to go! Boss: We need a progress bar here.

Programmer: Can we get a progress bar for next week's staff meeting, too?

dtech · 2010-01-25 Reply Admin

Determining progress is hard, okay... Determining progress is very hard for non-lineair operations (e.g. not infolving a certain amount of data/files to be moved or edited), okay... Progress bars can be used simply as a sign of "it's doing something and it's completing it" if you can't determine "real" progress, okay... If you can't do anything else, just update the progress bar to certain locations in certains steps (e.g. Windows XP installer), even that is acceptable (if no alternatives exist)

But RANDOM progress bars? That's just evil man, puuuure evil...

shadowman · 2010-01-25 Reply Admin

Anonymous:
... [b]but[/i] ...

heh

frits · 2010-01-25 Reply Admin

Anonymous:
Our shop used to use m_xxx for members but we went over to the Microsoft conventions a while ago so now we use exclusively _xxx for members. This is an improvement if only because all member variables are one character shorter and minimising line length is fundamental to improving readability.

Obvious Troll is obvious.

dtech · 2010-01-25 Reply Admin

Raw:
Actually, the Microsoft way it to have the bar asymptotically increase towards 100% on a timer, never really reaching it. When the task is done, they just slam it to 100% and finish. This is used, among other places, in Microsoft Access.
Actually, it's a pretty neat solution for those situations where you can't get any status updates, you just know when it's finished. I've used an enhanced variant of it myself several times.

Inspiring, fearful and evil at the same time. Microsoft did it again...

dtech · 2010-01-25 Reply Admin

despot:
You can take it too far tho. I worked at a place once (game development [...] The lead developer's solution involved standardizing the results of all known installs based on a value passed back as part of the activation process, along with some machine specs... and then conversion to the complex plane, and an integral transform or two thrown in for good measure.

overengineering is an art too. Did you have to answer riddle questions?

badcaseofspace · 2010-01-25 Reply Admin

Anonymous Coward:
Obviously none of you know how the windows service start and stop progress bars work. It's a little more sophisticated, but is basically the same principle

But the length of the progress bar does have meaning, it's a countdown to the service's timeout value, which defaults to 20 seconds on XP. But the service can communicate with the Service Control Manager to keep the SCM informed of the startup/shutdown progress and adjust progress accordingly. It's just the clueless apps that don't do that, they just have the bar run for 20 seconds. But the nicely programmed apps that communicate with the Service Control Manager may cause an even more erratic progress bar.

2010-01-25 Reply Admin

So the bar increments randomly... haven't we all done this?

genitus: cloud

mcmcc · 2010-01-25 Reply Admin

Mike:
It means nothing of the sort. Assuming this is C++, there's no "issue" here that needs fixing - this code is correct, and does the right thing (i.e. initialises members "x" and "y" from arguments "x" and "y" respectively). The only "issue" arises when people don't believe this, and insist on decorating one or other with warts - in the worst case, as you propose, inflicting freaky pseudoHungarian prefixes on every member variable in the whole bloody world.

That works until somebody decides to use member 'x' in the body of the constructor. Whoops. Yes, you can just prepend 'this->' but that's arguably less readable than the 'm_' prefix and is still a wart anyway you look at it. Would you rather have a 6 character wart ('this->') or a two character wart ('m_')?

Alternatives: The single underscore prefix is technically not portable and, I dunno, the underscore suffix just doesn't work for me. The choice of the least of multiple evils.

Needless overriding of outer scope symbols should be avoided if possible. It causes nothing but confusion.

frits · 2010-01-25 Reply Admin

mcmcc:
Mike:
It means nothing of the sort. Assuming this is C++, there's no "issue" here that needs fixing - this code is correct, and does the right thing (i.e. initialises members "x" and "y" from arguments "x" and "y" respectively). The only "issue" arises when people don't believe this, and insist on decorating one or other with warts - in the worst case, as you propose, inflicting freaky pseudoHungarian prefixes on every member variable in the whole bloody world.

That works until somebody decides to use member 'x' in the body of the constructor. Whoops. Yes, you can just prepend 'this->' but that's arguably less readable than the 'm_' prefix and is still a wart anyway you look at it. Would you rather have a 6 character wart ('this->') or a two character wart ('m_')?

Alternatives: The single underscore prefix is technically not portable and, I dunno, the underscore suffix just doesn't work for me. The choice of the least of multiple evils.

Needless overriding of outer scope symbols should be avoided if possible. It causes nothing but confusion.

You can avoid the warts by using COBOL case for members and camel case for locals.

blakeyrat · 2010-01-25 Reply Admin

Anonymous:
This is pretty horrific and I'm sure it's not a "Microsoft Standard" [b]but[/i] Microsoft certainly have done it before. Internet Explorer anyone? In the last version I used (v6.0), the progress bar would very slowly increment at all times, irrespetive of whether there is any data being sent or received from it. They probably thought to themselves "we can't stop the progress bar when the network gets interrupted, people will think IE is broken!". And it is.

That's by design, the progress bar progresses by using the timeout value, on the theory that it will smoothly reach 100% right as the page load times-out. Safari does the same thing, at least on iPhone.

I mean, regardless of the loading status, you know the process is "done" when you hit the timeout value, so you might as well progress the bar to the "done" state.

2010-01-25 Reply Admin

feeds the fire

The correct way to implement a progress par is whatever way makes your customers (both internal->Management, and external->purchaser) happy. I don't care if you lie, cheat, or steal extra cycles to make the perception good - because that's what matters.

tboss · 2010-01-25 Reply Admin

I too have encountered "interesting" progress bars in my travels as a prgorammer. One was similar: it was displayed on a webpage after issuing a request and would progress half of the remaining distance every second or so, meaning it asymptotically approach 100% (until the request succeeded and the new page was displayed). The other was mmore interesting. It was the progress bar for an A* search, so rather than plain progress it displayed it's depth in the tree. It would progress along nicely, but if it hit a dead-end it would go back to the point back up in the tree that the algorithm had to backtrack to. So it would seem to be almost finished, but then suddenly jump way back to hardly started at all. Very confusing for your avaerage user... But after all, this was an NP-complete search so progress was meaningless really.

2010-01-25 Reply Admin

Anonymous:
Fred:
Anonymous:
frits:
They must certainly be using Microsoft coding conventions with those stupid leading underscore member names.
What do you use? Our shop used to use m_xxx for members but we went over to the Microsoft conventions a while ago so now we use exclusively _xxx for members. This is an improvement if only because all member variables are one character shorter and minimising line length is fundamental to improving readability. It's a small improvement but an improvement nonetheless. So what's your solution, frits?
howabout not prefixing with anything?
No good - I want my member variables to be grouped alphabetically, so they need some sort of consistent prefix.

Huh? Why would you need variable names to be alphabetical? Are you using some kind of crazy self-writing code that needs to be able to sort by variable name??

2010-01-25 Reply Admin

frits:
mcmcc:
Mike:
It means nothing of the sort. Assuming this is C++, there's no "issue" here that needs fixing - this code is correct, and does the right thing (i.e. initialises members "x" and "y" from arguments "x" and "y" respectively). The only "issue" arises when people don't believe this, and insist on decorating one or other with warts - in the worst case, as you propose, inflicting freaky pseudoHungarian prefixes on every member variable in the whole bloody world.

That works until somebody decides to use member 'x' in the body of the constructor. Whoops. Yes, you can just prepend 'this->' but that's arguably less readable than the 'm_' prefix and is still a wart anyway you look at it. Would you rather have a 6 character wart ('this->') or a two character wart ('m_')?

Alternatives: The single underscore prefix is technically not portable and, I dunno, the underscore suffix just doesn't work for me. The choice of the least of multiple evils.

Needless overriding of outer scope symbols should be avoided if possible. It causes nothing but confusion.
You can avoid the warts by using COBOL case for members and camel case for locals.

Better still, you can avoid the warts by designing classes and functions that are small enough that you'll never confuse local variables with members. This will result in a much more maintainable codebase than imposing weird naming conventions on the assumption that the code will grow into an otherwise unmaintainable mess.

And to answer mcmcc's question: I'd rather have a 6-character wart that uses the language to express my intent on the (hopefully rare) occasions it's needed, than 2-character warts that make it look like the programmer had hiccoughs pervading every single class definition.

2010-01-25 Reply Admin

There's a much more elegant way of doing this - I don't know what language the original is in (C-pound?) but in Java I'd do something like this:


Thread t = new Thread(new Runnable() {
    public void run() {
        try {
            // Don't let progress bar reach 100%, 
            // just in case the job takes longer
             while (bar.getPosition() < 95) {
                 bar.doStep();
                 Thread.sleep(2000/bar.getPosition());
             }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
});
 t.start();
// Actually do the work
 doWork();
// Wait for progress bar to finish
t.join();

2010-01-25 Reply Admin

mcmcc:
Would you rather have a 6 character wart ('this->') or a two character wart ('m_')?

I'll take the 6 character wart because it's not arbitrary. Its meaning (should be) absolutely clear to anybody who understands the language.

lolwtf · 2010-01-25 Reply Admin

Mark S:
Maybe I'm not a typical user, but to me "98% finished" implies "2% remaining". If the progress bar reaches 98% in 49 seconds, I damn well expect it to reach 100% in another 1 second. When it doesn't, the programmer who wrote that progress bar is lying to me.
At least a dancing icon doesn't promise anything about how much time is remaining. Of course, if it updates on a regular schedule, it looks like a separate thread that is unrelated to the (possibly hung) real work.

But if it updates irregularly it looks like it is connected to something that is actually happening. That gives the indication that it is not hung, without making any promises it can't keep.

The solution to this is to display *two* progress indications, using two threads. The first a simple icon, moving back and forth or spinning or something. The second a textual display of progress (# bytes copied, etc). Then you get the nice smooth animation people tend to want while still providing an actual indication of progress (and speed, even if for some reason you can't display the speed as well) while not knowing how close you are to completion.

My favourites are the ones that seem to be filling up rapidly, but are in fact an "indeterminate" bar with a very oversized fill. So it quickly reaches about 30% and then starts emptying from the other end, and only then do you know it's not actually measuring progress. Also, phpBB's file upload progress bar, which is just a GIF animation of a bar filling, over and over again, giving no indication of progress whatsoever.

TRWTF is phpBB.

2010-01-25 Reply Admin

[quote user="Anon"] http://xkcd.com/612/{/quote]

Funny but a true progress indicator

http://www.pcserviceselectronics.co.uk/fun/download.php

CAPTCHA ullamcorper - the sound mad when hit in the stomach..

2010-01-25 Reply Admin

Raw:
Actually, the Microsoft way it to have the bar asymptotically increase towards 100% on a timer, never really reaching it. When the task is done, they just slam it to 100% and finish. This is used, among other places, in Microsoft Access.

As compared to Outlook Express email download which is incremented by the proportion of COMPLETE messages downloaded. Despite the fact they know how many bytes to be downloaded.

So when more users had dial up the amount of calls I would get because Outlook Express had crashed on message 4 fo 12. In fact message 4 was 2 to 5 MB while the others were 2 - 1o kB.

2010-01-25 Reply Admin

In general, people view a simple spinning 'progress icon' with less trust than a progress bar that's counting up.

People are far less willing to watch a little circle spin than they are to watch a progress bar go to 100%. A non-technical person will see the circle spinning for about 20 seconds and think "hmm that's doing the same thing it was doing, it must be stuck". However they will look at a progress bar and think "well its progressing, it must get to 100% at some point."

Lets face it, in the vast majority of cases, progress bars aren't meant to measure progress they're meant to keep the user occupied and not hitting cancel while you do what you need to do. If that means lying to the user about knowing how much work you've actually done then so be it.

Also with a 'legit' progress bar you have issues with making sure it's consistent. If my application has 5 atomic steps then I would likely update the progress bar 20% after each completion. But what if steps 1, 2 and 4 take 2 seconds each and steps 3 and 5 take 30 seconds each. The bar will jump to 40% right away and then hang, then jump to 80% and hang until done. I'd be much better to have it count asymptotically up to 100% in small increments and then just bump it to 100% whenever I'm done, my user is much more likely to stick around.

2010-01-25 Reply Admin

Mike Caron:
dpm:
I can't think of any clever or even snarky way of pointing out that 1/5 != 0.5

Let me try:

"Hmm... 0.5 == 0.2? This must be that 'new math' I keep hearing about..."

2nd try

Could just be a bunch of bored math geeks... <sarcasm> Imagine a funny base 3 where you have 0, 1, 5 as your symbols (could be a, b, c)... In this instance I think 1/5 in that funny base 3 would equal 0.5 in base 10... just like b/c=0.5 in the other situation... </sarcasm>

mcmcc · 2010-01-25 Reply Admin

Mike:
Better still, you can avoid the warts by designing classes and functions that are small enough that you'll never confuse local variables with members. This will result in a much more maintainable codebase than imposing weird naming conventions on the assumption that the code will grow into an otherwise unmaintainable mess.

What in God's name are you doing that prefixing (presumably private) data members with 'm_' leads to an unmaintainable mess? And upon whom exactly is this convention an imposition? Sounds to me like you already have an unmaintainable mess to start with.

And to answer mcmcc's question: I'd rather have a 6-character wart that uses the language to express my intent on the (hopefully rare) occasions it's needed,

The point is that you can't (reliably) know when it is needed. Most compilers (unfortunately) do not warn about this. If your members are plainly named, there's a decent chance you won't realize that a local variable is overriding it. Your only reliable choice is to wart-ify all references to member variables. Choose your flavor of wart.

mcmcc · 2010-01-25 Reply Admin

Anon:
I'll take the 6 character wart because it's not arbitrary. Its meaning (should be) absolutely clear to anybody who understands the language.

Suit yourself. I myself use 'this->' for method calls quite often (I don't otherwise wartify method names).

In any case, arbitrary is as arbitrary does. Once you establish a consistent convention, it doesn't matter so much what the convention is. You just have to be consistent.

2010-01-25 Reply Admin

I had to build some bulk file transfer utilities to be used in branch offices of the company I work for. I put progress bars in them based on the number of files being transferred with a status message above the progress bar that gave the name of the file being copied. These were meant to run on a laptop that was used to scan docs at remote locations then upload to a server at the main office. Even with the progress bars and status indicators I had problems with the users deciding to just shut the laptop down at the end of the day whether the transfer was done or not.

I tried various things but what I eventually had to do was to intercept all possible kill signals the transfer program could possibly receive and pass them through a routine that checks to see if the transfer is complete. If it's not, it issues an immediate shutdown abort, un-mutes the laptop's speakers, raises volume to max and plays a siren wave file until the user clicks a button explaining that they are not allowed to do what they just tried to do.

I never have any trouble with aborted transfers anymore. None of my users even attempt it anymore.

2010-01-25 Reply Admin

One clearly sees those who majored in Computer Science:

int _percentage = R.Next(Convert.ToInt32(.5 * _bar.Maximum));

Those who did not:

int _percentage = R.Next(_bar.Maximum / 2);

And idiots:

"between 0 and 1/5 the length"

Meaningless Progression

Leave a comment on “Meaningless Progression”