@Moose-Kun: Somehow the CSS and jQuery code for image scaling got reversed: images loaded enlarged, then you could click them to shrink them o_O I have no clue how that happened, but I'm going to blame myself even if don't know when, why, or how I did that. It's fixed now anyhow. FSTDT's code is actually still mostly Distind's original code, I'd estimate ~90-95% so. The only changes that I've made have been bug fixes. The complete rewrite is a work in progress. It's progressing rather more slowly than originally planned, partially due Ravy not being available often, but mostly because a rewrite is no longer an emergency that needs fixing ASAP because Bossman had lost the latest version of the site's code.*
[aside]*ASP.NET is very unlike virtually all other Web programming in that server-side source-code files are compiled into machine-readable binaries before being deployed. Actually, that's a bit of a simplification: the source code is compiled into [abbr=Common Intermediate Language]CIL[/abbr], an intermediate form somewhere between human-readable source code and machine-readable instructions, but decidedly closer to the latter (or at least to its pre-assembled assembly-language counterpart). Only this (half?-)compiled code is necessary for ASP.NET-powered websites to run. The original source files are not even uploaded onto the Web server unless the programmer is a klutz: that makes "losing" them a real possibility that makes sense. In the rest of the web-development world, all server-side PHP, Python, Ruby, Perl, ColdFusion, etc. source-code files are uploaded directly onto the server as is, and they are interpreted or compiled into machine-readable forms on-the-fly, so it's impossible to "lose" them without completely breaking everything.[/aside]
But Bossman actually wound up saving the day by using a decompiler to resurrect the latest source code before he handed things over to me and Ravy. With that crisis averted, I have the opportunity to be much more thoughtful and meticulous in my coding and to take time to do more testing code as I write it. I'm no longer primarily focused on just making a working replacement to the current code. My goal now is to create something something that is initially functionally equivalent to the current site but whose code is better organized, more modular, easier and faster to extend and [em]improve[/em] upon, and safe to make open source (something I fully intend to do).
Anyhow, the resurrected code of the current site is surprisingly readable for something that was disassembled from much more low-level CIL equivalent to object-oriented assembly. But it more than makes up for this rather impressive feat with a small handful of very, [em]exceptionally[/em] disassembler-like parts that are a special kind of convoluted, being almost unreadable in some cases bad by [em]even decompiled-code standards[/em]. Take a gander at this:
this.Session["LastCommentID"] = (object) (this.CurrentUser != null ? new Comment(Convert.ToInt32(this.Request.QueryString["QID"]), (string) this.UserNameEntryBox.Text, (string) this.CommentEntryBox.Text, (string) this.Request.UserHostAddress, (int32) this.CurrentUser.ID) : new Comment((int32) Convert.ToInt32(this.Request.QueryString["QID"]), (string) this.UserNameEntryBox.Text, (string) this.CommentEntryBox.Text, (string) this.Request.UserHostAddress, 0)).ID;
When it comes to actually making sense of this, actually knowing C# doesn't make me much better off than you unless I have a lot more caffeine and Aleve than I do right now. (I'm actually working on a Shy Says post that touches a bit on this and the results of disassembling the FSTDT code into Visual Basic despite being written in C#.) I get the gist of the basic logic of this code after reading it slowly and carefully keeping count of the parentheses and commas, but I'm not even going to try to decipher the specifics right now. I may edit this post with an update putting this into a readable form a little later. It's pretty much necessary to implement the ban-evasion blocking I have planned.
[aside]For other code-monkeys in the audience, I have no clue what's up with all those ridiculously superfluous type casts: they aren't unique to this especially badly disassembled gem but actually permeate the code, though it does not seriously interfere with readability in the vast majority of cases. This is my favorite: (int32) Convert.ToInt32(this.Request.QueryString["QID"] yes, that is seriously an integer cast on the result of an integer type-conversion operation. Also, CIL is frequently [usually?] compiled with most identifier names intact, but these can also be stripped into very short, random, meaningless strings as a very basic means of obfuscation or perhaps to reduce binary size a little. (Hey, I have knowledge and experience in .NET programming, not 'deprogramming.')[/aside]
Wow. I got sidetracked a bit there.
Addendum: Here's the disassembler's VB rendition of the above code. It does away with the gratuitously needless typecasts, but there's no improvement otherwise, and the code is all about me, me, me (...is it possible for source code to be self-absorbed? At least the C# code was all about this, this, this):
Me.Session("LastCommentID") = (If((Me.CurrentUser IsNot Nothing), New Comment(Convert.ToInt32(MyBase.Request.QueryString("QID")), Me.UserNameEntryBox.Text, Me.CommentEntryBox.Text, MyBase.Request.UserHostAddress, Me.CurrentUser.ID), New Comment(Convert.ToInt32(MyBase.Request.QueryString("QID")), Me.UserNameEntryBox.Text, Me.CommentEntryBox.Text, MyBase.Request.UserHostAddress, 0))).ID
