The Weird and The Wonderful

Bernhard Hiller wrote: It took extremely much time. That turn of phrase gave me pause, it's more common to say "It took a lot of time." implying that in your opinion, it took much more time than you expected. So, what's syntactically wrong with your statement? Breaking it down, I found: nothing. Thank you for inadvertently pointing out to a native English speaker, that sometimes he doesn't know his own language so well. :) I've heard the phrase "I'm 110% sure that I'm right" several times. Which makes me 99% sure they are wrong in some way. I remember a TV series, one of the characters can't forget. He was saying they tested him as a kid, again and again making the 99'th percentile. She said, "What's the matter, you couldn't reach 100?" He said, "There isn't a 100'th." I knew that, but it made me feel better about my SAT's 98th percentile in math because it meant that maybe I was closer to 1.1% away from the top kid in the nation. I took the SAT's over 40 years ago. I'm quite sure my math has degraded since then. It doesn't matter what I scored as a kid. I can't prove it, but I still think I am above the 50th percentile in math. It took me a week to convince a manager that the math was wrong, when I knew it was wrong within 10 seconds of reading the line of code. (I never said I was superior in English. :laugh: )

At least that comment was making sense :laugh:

This is dailywtf worthy.

Rob Grainger wrote: The 1970's called, they want their developer back ;-)   If people rarely keep comments in sync with the code, the chance of them keeping separate technical documents is almost nil. Actually that is exactly what our company did in the 80s to get ISO certification. Our entire software development process was defined around keeping everything in sync. And it worked! Rob Grainger wrote: Almost every project I've worked on with large amounts of technical documentation has been government contracts - badly run, badly designed, over budget and frequently failing, but I've not seen a single example of useful technical documentation on any project I've been lucky enough to work on. Funny you are saying this, because before we introduced extensive documentation and the process around it, we did have issues with budget and time overruns, but rarely after. I've learned - by example - that a well organized process put into action by a disciplined team can produce incredibly high quality output with predictable results. And the documentation was crucial to that! Before we had that extensive documentation, we lost too much time reimplementing stuff that wasn't specified in sufficient detail. Of course, back then the process we had was a modified waterfall model. Nowadays, with agile development, you need a lot less documentation - it's bound to change anyways. In the end, what it all comes down to is that you need a good process. if that process requires a lot of documentation, then you need that. If the process can do without, then you don't. OTOH, if the process is bad, then no amount of documentation can save you.

Name ans shame! Works for Paedophiles.. :) ============================== Nothing to say.

This could be a good tip.... Clever code.... I quit being afraid when my first venture failed and the sky didn't fall down.

That's a joke :laugh: However in this case there should be no iterator!!

OriginalGriff wrote: That explains the lunchtime drinking. No, that was the early part of career working in COBOL. VB is responsible for the night time drinking. :-D Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett

I would bring this up as a potential threat to my business with the powers that be and try to find a different vendor for that type of product. I wasn't, now I am, then I won't be anymore.

While I mostly agree, this is not always possible. C++ in particular is such a large language that few people know it completely, but its perfectly possible to write excellent programs using a familiar subset. In such cases, use the arcane features of the language can be regarded as a codin horror - as the majority of developers will need to look up the meaning. While programmers favouring other languages may scoff, this seems similar to knowing the libraries. I could learn C# syntax in at most a week for example, becoming familiar with the libraries takes longer, and is actually what I spend of my time doing. I'm absolutely sure I don't know them as well as I'd like, and there's whole areas I leave until I need to. What makes all this work is MS's documentation that (normally) helps see usage conveniently. Most of that is auto-generated from Comments, so comments seem fairly necessary. I kind of hate the "everyone who doesn't know what I know is an idiot" approach to programming - I'd hate to be on a project with someone with that attitude, they tend to leave unmaintainable code in their wake.

Well spotted, I did stop at the case mismatch there! 'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood

It's a long time since I've used "proper" C or C++, but in C#, it won't even compile as the label is out of scope of the goto :)

Obviously, the culprit misheard the comment "Too true!" ;P ;P Peter Software rusts. Simon Stephenson, ca 1994.

Parameterized queries are safe in this context! Well there are those 'Xperts' and 'Seniors! everywhere :laugh: Try this[^]

Then you are not guilty. This guy did it with all the bad intentions! hahaha My new toy: www.cloudclipx.com -- If I have 8 hours to chop down a tree, I spend 6 sharpening my ax!

That's downright amazing. I don't think I would have ever thought of that. It really makes you wonder, who does think like that? Was the author an expert in regex per chance?

I've actually done something like this (but never left it in the production code) on a rapidly evolving piece of a class. The purpose behind it is that you originally start out with a method with let's say, 100 lines of code, then the person that was driving the requirements no longer wants the checking, so you go back, and in order to test your entire application quickly without refactoring, you throw the "return true" in there. Not saying it isn't stupid to allow something like that to end up in production, just saying I've actually done it before for quick testing.

mdblack98 wrote: Dim j As Double ... j = 0 For j = 1 To 100000 ... j = j + 1 ... Next Ouch! * Declaring a control variable as a Double * Redundant initialisation of a variable immediately before using it as a control variable * Doing integer arithmetic on a Double (in the For and in the assignment statements) * Changing the control variable inside the loop * Writing a Hall Of Shame contender in response to a Hall Of Shame entry. Priceless!

Coded by lazy programmers, for lazy programmers... This is what happens when you sleep at work! :zzz: It's an OO world.

Exactly what I was trying to say, I guess! :thumbsup: "With sufficient thrust, pigs fly just fine." Ross Callon, The Twelve Networking Truths, RFC1925