|
What if Stuff.Count never exceeds 100 items? Both versions seem like infinite loops.
Recursion would be superior here because it will at least blow the call stack in a reasonable time frame vs. waiting for the application container (IIS?) to kill the non-responsive thread.
I usually include a safety valve for that kind of code:
int maxReps = 100;
blalbalba && (maxReps-- > 0)
I always use safety valves when writing code that "should" converge to an answer.
|
|
|
|
|
How about?:
protected void Page_Load(object sender, EventArgs e)
{
List<Node> Stuff = new List<Node>();
do {
foreach (Node thing in Node.GetCurrent().Children)
Stuff.Add(thing);
} while (Stuff.Count < 100 && Stuff.Count > 0))
Stuff = ShuffleNodeList(Stuff);
}
|
|
|
|
|
Journalists of Bangladesh Asked to police "when are you going to catch the criminal."
Police ob Bangladesh answered that when they will be 100% confirm.
Then the journalist asked "What do you mean by 100% confirm"
Police department answered:
When someone will give the detail description how they murdered those Journalist couple in-front of Journalists then they will be 100% confirm.
FÚck, I born this shîtty country
modified 16-Feb-12 1:17am.
|
|
|
|
|
|
its a programming forum dude,
even though its a shame
|
|
|
|
|
This is the original code:
DateTime dtInput;
DateTime.TryParse(txtInputDate.Text, out dtInput);
document.InputDate = dtInput;
Lets do a change request:
* Input date always will be the current date.
DateTime dtInput;
DateTime.TryParse(DateTime.Now.ToString(), out dtInput);
document.InputDate = dtInput;
What is wrong with these people? They start coding and stop thinking?
|
|
|
|
|
I think the best part of this one is that even the original code is broken – because it's not checking the result of TryParse and assigning a sensible default value, if the input string wasn't in a valid format, you get (DateTime)0 which is almost certainly not what they want (and will cause things further down the line to break in subtle ways).
|
|
|
|
|
The original code has a infallible validation using Javascript.
It never fails.
Except when you change you server locale, or disable javascript, oh sh*t, I remember now, I had fixed this too.
|
|
|
|
|
sergio_ykz wrote: infallible validation using Javascript
that was a nice one 
|
|
|
|
|
sergio_ykz wrote: infallible validation using Javascript
var pope = new Pope();
pope.setExCathedraMode(true);
var inquisition = pope.createInquisition();
var result = inquisition.interrogate($("form"));
if (result.isHeretical)
pope.excommunicate($("form"));
pope.setExCathedraMode(false);
|
|
|
|
|
|
On the other hand, it makes it easier to go back to the original someday. :p
|
|
|
|
|
I have often written a change request with the expectation that it will get switched back to the original when the user realizes that it isn't really what they want. However, I comment out the old line(s) and and new code, not try to shove a square peg into a round hole.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
sergio_ykz wrote: They start coding and stop thinking? Yeah, they still don't get all that multithreading stuff.
Greetings - Jacek
|
|
|
|
|
Maybe they were thinking of the Mayan calendar. Pretty soon DateTime.Now will not parse.
|
|
|
|
|
This[^] VS 2010 issue had been finally fixed and shipped with a SP1.
Horror: Someone had revealed it...
At least it was found in commentaries...
Greetings - Jacek
|
|
|
|
|
But what was even worse, they had to release a hot fix for SP1 as it caused more issues than it fixed !!
#VisualStudio2010WorstEver
|
|
|
|
|
... and all of them are "important"
Ah, by the way, I do not agree that VS 2010 is worst ever. Actually, I like it more than all previous releases, because blah blah etc..
Greetings - Jacek
|
|
|
|
|
|
Moved my primary mail to the ISP, since I'm feeling tracked on Google. KPN, the largest ISP in the Netherlands, has been hacked as they put it. I just received an email telling me that I should reset my password, simply because those were leaked too.
The largest Dutch ISP has not yet learnt how to securely store a password.
No, that's not even the reason for posting in the Hall of Shame; right after this mess they claim that they're "encrypting passwords" in UTF-8[^].
Tweet is in Dutch. Translated;
Passwords of KPN are encrypted using UTF8
I'll even be moving my money from the bank tomorrow unless they can prove that they're not saving my password in plain-text format.
Bastard Programmer from Hell
|
|
|
|
|
Recently, I stopped using online money transferring for the same reason, I am very poor to loose money over their stupidity.
|
|
|
|
|
Eddy Vluggen wrote: they claim that they're "encrypting passwords" in UTF-8
|
|
|
|
|
And here I was thinking encryption involved some magical "keys" and whatnot. Good to know that it's not all that complicated. 
|
|
|
|
|
Wow, I'm impressed. Brand new encrypting technology - UTF8 But it's not strong enough (like Latin1 as well). I strongly recommend to use something like UTF32. You know, additional 24 bits make it harder to decrypt. Or they could just use Japanese or Arabic characters. This will mislead an intermediate european or american hacker.
|
|
|
|
|
UTF-8: Unexpected Technical Fault-8
|
|
|
|