Fri 29 December 2006 10:50 AM
set-based
If I hadn't seen the same sort of drastic improvements in performance by moving a couple data manipulation processes from a cursor-based / procedural approach to a set-based approach, I would have a hard time believing Kevin's story of 1000-fold improvement in run-time by replacing a number of SQL "procedures" with one 300-line SQL statement.
Wed 27 December 2006 11:13 AM
Stranded
this is truly bizarre.
Wed 27 December 2006 11:00 AM
Ritual Impurity
It's your ritual purity laws infecting you with parasites when you just wanted to placate your capricious diety. Isn't ironic don't ya think?
Fri 22 December 2006 10:10 PM
dgaf
Thu 21 December 2006 11:37 AM
fartku
Rumbling bassline Emits smell of cow entrails Underpants are smeared
Tue 12 December 2006 12:44 PM
I will simonize my battle tank
Quebec French attacks the unwary speaker on all fronts - morphological, syntactic, and phonetic. The language has kept a variety of vestigial bits that mainline French lost a while ago, it sounds as different from French as a Scottish does from American English, and it uses heavy doses of local slang and English borrowings (while eschewing other English borrowings that are accepted in Continental French). It also wins special points by throwing in the occasional Imperial measurements, something I only associate with old French texts from the 18th century.
Sun 10 December 2006 10:46 AM
p00t
Far infrared video of a fart.
Thu 7 December 2006 3:54 PM
why didn't you do that?
Aside from the last two, I would say the Script Guys' suggestions are unequivocally bad advice. Why? Because they are advocating a) relying on "default" behaviour; b) failing to make explicit their code's behaviour - for the purpose saving a line or two of code; or c) removing information from the script that would allow the script compiler and interpreter to help you out by throwing useful compile-time and run-time errors.
Beowulf's Script Standards:
- Always use WScript.Quit at the end of your script to explicitly show the reader of your code that you intend to quit now. However, never use WScript.Quit to prematurely dump out of a script to save yourself the trouble of properly structuring your code to test for abberrant conditions.
- Always define Option Explicit, meaning you must dim all your variables. Also, don't be lazy and dim 8 variables all on one line. One dim per variable is nice and easy to read.
- Always set objects you're done using to Nothing. Why? It explicitly declares your intention to both the run-time environment and to your loyal code reading fans. It also frees the memory immediately, rather than whenever the object goes out of scope. Also, it will allow the interpreter to do some work for you by throwing a run-time error, if there are inadvertant references to the no longer used object.
- Always indent code blocks, but never define a tab to be more than 4 spaces. I prefer 2 spaces myself.
- Comment your code as much as you want. If the next person to read/use the code finds it to be too much, it is easily removed. More often than not, the problem is not too many comments, but rather a dirth thereof.
Wed 6 December 2006 3:15 PM
punk rock bandname
Ok, these
things are just lame string concatenators or hash lookup thingies,
but this one was funny:
Your punk rock band name is The Scandisk Dildo
Wed 6 December 2006 2:10 PM
First Sign O' The Season
I saw the following on a sign outside an Episcopal church on the way home
last night. I had to laugh.
Christmas in three words:
God with us
Wed 6 December 2006 12:32 PM
demons fly out your nose
I found the odetocode blog after idly googling demon fly out nose:
As the author of the original "demons may fly out of your nose", I'd like to point out that the real point of the "undefined behavior" discussions was not to assert that bizarre behavior must necessarily result from incorrect or undefined code; it was to defeat the frequently seen argument that "compiler X is junk because it doesn't generate correct code for my program", where "my program" inevitably included an instance of undefined behavior (dereferencing NULL, sizeof(struct undefined), or whatever). Merely replying "the standard says you shouldn't" never convinces these people; they always come back with "well, compilers Y and Z do what I expect, so obviously I'm right", followed closely by "how can the standard possibly permit a compiler to output broken code even if a construct isn't officially defined?" Thus there was an ever escalating insistence that "undefined" does not mean "whatever the user thinks would make his broken program work", it means "undefined by the standard and beyond the pale of the language". Compilers aren't obligated to mistreat programmers who step outside the language definition, but they certainly aren't obligated to treat them kindly, and a compiler which "works" one release with an incorrect construct may not "work" the next release -- even though the compiler is, in fact, perfectly conforming in both cases. (Although there have been some programmers who I *wished* had compilers which formatted their hard drives when undefined language constructs were used...) (I just idly decided to go googling for "nose demons compiler" to see how many references to the idea were still floating around.)
Sidebar
