It’s not really code, it’s comments. Part 2


January 28, 2014General Uncategorized1 Comment

This is continuation of my previous post about all kinds of comments I find in code.

Sometimes everyone gets pissed off with front-end issues:

// Since both html and css are retarded (I've tried spans and divs and
// float and clear and fixed table-layout and what-the-f*ck-not), the only thing
// that actually works is spacer gifs with fixed widths. I f*cking hate it.
// Subtract the height of the header panel - we want the total height of the
// container to reach the height set on it
contentPanelHeight -= 19; // Hardcoded. Very nice. Not. Whatever. Doing this in
                   //javascript would suck more since it is hard to get it to work.
// Subtract the {…} panel's padding
contentPanelHeight -= 2 * 10; // Also hardcoded. Whee.
// fix for IE6 suckage
{Some js hacks to fix layout in IE}
// Microsoft Stupidity Check(tm).
{IE version detection stuff}

And here is some mysterious stuff:

// This is the important part, setting the columnname to the non-existing column
// Show the menu above below the root menu item
if (sqlCheckMessage != SQL_CHECK_PASSED) // Eeek, it does! This can't be tolerated!
// Get {...} messages. The column is there, but its always null.
// Probably must be filled using {class name}.
// The data source doesn't contain a ID field. The way to find this out (using
// DataBinder) is real ugly, so if anyone knows how to do it in a better but still
// generic way (that is, works with any kind of data source; DataSet, DataView, 
// DataTable etc), feel free to implement it.
// The HelloWorld() example service returns the string Hello World
// To build, uncomment the following lines then save and build the project
// To test this web service, press F5

//		[WebMethod]
//		public string HelloWorld()
//		{
//			return "Hello World";
//		}
catch (Exception ex)
    // Handle Exception Here

And some “security” stuff:

//alert("hehe" + top.frames[0].mailPass64);
//mypass = 'MmtlZWZ5Ym95Nw=='
// #### Hack to prepare for the security check later on - move this into a
// behavior or something

Now imagine you been trying to find a cause of stock bug for half a day and then come across such thing:

// Changed by Igor: previously this {…long description…}

This is ordinary name in some countries, but since more often you’d find full name signatures and if we take into account circumstances first what comes to my mind is that character Igor from Frankenstein movies was changing this :)

You know the feeling when everything that you’ve done looks wrong but you have no means to change it because of related parties, but really want to plead your implementation:

* Important/to-do!
* When this card was designed (version 4.0{two major version before this}), the
* CreateNewForUploadedFile operation mode was supposed to be triggered when the
* uploadedFilePathBase64 and titleBase64Encoded query string parameters had values.
* The uploaded document file was supposed to be placed by {module X} in a temporary
* folder, specified by uploadedFilePathBase64, and if this document card was saved
* (using the OK or Apply buttons), the document file would be moved to the 
* regular {…} document storage folder. If this document card was instead closed or
* cancelled, the document file would be deleted from the temporary folder. Code for
* doing this is implemented in the Save method in this card, but not used.
* Why is it not used? Well, that's due to a miscommunication with the developer of
* the document upload function in the {module X}. The old (pre-4.0) method is still
* used, where the uploaded document file is placed directly in the regular {…}
* document storage folder, and a {…} document object is created for that document
* file before this card is opened, and will already have a ID when we get here.
* The querystring parameter "isDraged=1" is used by {module X} to indicate this 
* (the ancient way). Since the code written specifically for the new way to handle
* document file uploads doesn't work with the old way of doing it, the
* CreateNewForUploadedFile operation mode is currently not used.
* Hopefully the {module X} document file upload functionality will be rewritten to
* place the document file in a temporary folder and NOT to create a {…} document
* object for it, but instead passes the said query string parameters to this 
* document card. If so, the CreateNewForUploadedFile operation mode will finally 
* be used, as intended.
* Ticket to implement this: #...

You might have got an impression that it’s always negative. But NO, sometimes it gets sensible:

// If the control is a UserControl, place it inside an UpdatePanel to
// Ajaxify it. Nice and simple. Thank you AJAX Extensions developers, we love you.

Although, in my personal opinion Ms AJAX extensions is something to avoid :D

So, this ends my comments collection.

For conclusion, I’d like to wish you never find such comments in code you are working with and don’t neglect it so much that they appear.

One Response to “It’s not really code, it’s comments. Part 2”
  1. Agnius101

    Nice one. Made my day:)

Leave a Reply