- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
It's also notable
Admin
You should read "Undocumented Windows" about weird naming conventions.
Admin
Objective-C doesn't have a native boolean type, so I'm not sure what you're referring to.
Admin
BowelsOfDiscRecordingEngine is likely a takeoff of a much older symbol: BowelsOfTheMemoryManager. In early PowerMac days, the debugger would try to find the location of an address by the embedded debugging symbols. So if you corrupted your heap, your app would crash in the memory manager. But the last symbol in the memory manager was "HSetStateQ", so lots of developers would file bugs saying that HSetStateQ crashed. So in Mac OS 7.6, they dropped one last symbol in there: "BowelsOfTheMemoryManager". That way, you'd get a hint as to the real location of the problem.
See http://developer.apple.com/qa/me/me05.html
Admin
Not that it's a huge naming problem, but I am the only person that is bothered by database table column names that always have the table name preprended? If the table is "Item", do we really need the columns to be named "ItemID, ItemName, ItemDesc, ItemFoo"? For some reason those column names drive me mad...maybe it's because I'm surrounded by people that think * is the only thing that can come after SELECT so they never notice anyway.
Admin
And Apple loves long function names that are very clear as to their function. The longest one in Carbon is SetAutomaticControlDragTrackingEnabledForWindow().
Admin
I kinda like it. It's pretty clear what it means :) At the very least you have to admit that it is better than a short cryptic appTermWC method or something like that.
Admin
I've done that last one! Naming a variable Sex for (S)ql (Ex)ception!
Admin
Some of those "DontTouchThis" members in the .Net assemblies were used to avoid some compilation warnings. You can read this post: http://blogs.msdn.com/brada/archive/2005/01/31/364323.aspx
- Sergio
Admin
Yes, that's extremely irritating and pointless. It's like if I named my son WatsonJames, Watson.
The same thing happens when XML schemas are developed. People will create an element Person and two sub elements personFirstName and personLastName. The resoning usually is that they just want to search the XML as if it were a flat file instead of using on the of the bazillion tools at their disposal.
Admin
I believe I've already told all my really good naming stories, but I'll take this oppertunity to post the link to the scans of "Mission:Impossible spoof as documentation". It's the precursor/companion to the Sherlock Holmes spoof I posted a few days ago.....
http://honestillusion.com/photos/mission_impossible_spoof/
Admin
"Not that it's a huge naming problem, but I am the only person that is bothered by database table column names that always have the table name preprended?"
Actually, in SQL this does make some amount of sense. Specifically, if I were to talk about T-SQL (SQL Server), many of the most common descriptors that you might use for a column are actually reserved words, such as ID, Name, and Type. So if you want to avoid compliation problems, you have to add the brackets [] (or ticks ', if you're wierd) whenever you want to do anything with that column. If you want to be consistent, the implication is that you'll have to bracket everything.
Personally, I very much dislike the look of the brackets in SQL code, it breaks everything up and makes it very "stuttery" and harder to read, in my opinion. For this reason, I preface reserved word column names. I can see how some people would preface all columns to preserve consistency.
Admin
Almost choked when I saw "_DontTouchThis". That's good!
Admin
The (sometimes) ridiculous method names are my least-favorite part of working with Cocoa. Of course, I wouldn't care if XCode had something as awesome as IntelliSense. :'(
Admin
This is definitely a GOOD thing to do. The reason I think it is good is what if you have 2 tables and they both have itemID as a column name. If you do a SQL query that and returns both fields then you have to alias the column names in order to distinguish them. If you gave them different names to begin with (i.e. ItemID, ManufacturerID, etc) then you don't have to do this.
--The Dan
Admin
Ewwwww! You mean other code environments don't have something like IntelliSense?! (for non-windows people: this is an autocomplete feature that shows a dropdown of available methods/objects when typing . or -> or CTRL+SPACE, and narrows the list as you type, completing when you hit ENTER) WTF. Boy am I glad I only code in a Windows environment at work.
Seriously, when I was at school, SSHing into unix command prompts and being forced to use VIM or EMACS really really really really sucked.
Admin
Catch ex As Exception
Catch Sex As SqlCeException
MsgBox("Questions.Save : " & Sex.Message())
Pardon me for not being up to speed on VB & .NET but would I be crazy for assuming SqlCeException is derived from Exception?
Admin
I'd take verbose over terse seven days of the week.
Going in to someone elses code and seeing someting like:
if(applicationShouldTerminateAfterLastWindowClosed()) {
...
}
is so immensly more readable than something like:
if (appTermLWinClsd()) {
...
}
I 'err' on the side of verbosity over tersity when I write code and on many occasions I have patted myself on my back when I have had to go back to my old code (say after 6 months to a year) and I can actually understand wtf I wrote. And on some occasions I have cursed myself for using brevity and tersity in the shortsighted interest of saving a few keystrokes.
Admin
XCode DOES have an equivalent to Intellisense. Actually, all the best IDE have been ported on OS X, not on Windows... sorry for Micro$oft fans.
Admin
This, this, this CODE sucks
So hard
Makes me say, oh my lawd
Thank you
For blessing me
With a mind to code
Even in C
Admin
You don't need the brackets for reserved words. SQL Server (2000, anyway) is smart enough to know from the context whether or not you're referring to a column with a name like Id or Name.
I just tried this query:
<FONT face="Courier New">select * from Divisions
where Id = 1</FONT>
Without brackets, it highlights the word "Id" in blue, but other than that, it runs fine.
Admin
Is it really that difficult to alias column names?
<FONT face="Courier New">select Item.Id AS ItemId</FONT>
Seems pretty straightforward to me...
Of course, it doesn't help matters when Microsoft's own sample Northwind database has columns like Customers.CustomerID.
Secondly, why do people use ID instead of Id? ID implies an acronym. If "I" is for "Identity", then what does the "D" stand for? Id is an abbreviation, not an acronym, so it makes no sense to capitalize both letters. That would be like referring to someone as DR. or MR.
Admin
Correct. It's WTF on its own. The SqlCeException will be never displayed, just caught silently
<FONT size=4></FONT>
Admin
ross, my friend... you and i hate the same people...
Admin
We have a tool that was developed in-house and used strictly for in-house work. I don't know what it does, but it has to do with image recognition and grid referencing or something. It's called the "S.E.C.S." tool (sound it out), and the different features within it were given names to correspond with the double-entendre name of the whole suite. Such features like "Mood lighting", "Hump tool", "CenterFold", "Alternate Positions", and "Insertion".
Admin
I agree completely. The amount of typing you save from not typing the table name before EVERY column name far exceeds the amount of extra typing from aliasing a column. Also, if you are taking data from the database and moving it to objects, I assume the properties you are assigning to do not have the table name prefixed...I know that I never write:
}
Because I know I would hate to have to always references myItem.ItemName...that would be TONS of fun.
Admin
Admin
Oh come on, you've all missed the most WTF naming convention of all: Naming stuff after their numeric index in an auto-numbered requirements document.
public void DoAction2aFromSection5cOfRequirementsDocument3();
After all, this should encourage people to read and understand the requirments documents.[:O]
Admin
Suppose that Items has a column called "Name" and you have this query:
SELECT Items.ID, Name FROM Items JOIN Groups
WHERE Items.ID = Groups.ID AND Groups.FooColumn = 'value';
Now add a column called Name to Groups and see what happens. Unless you have been writing ALL your column references as table.column all along, then you don't want to add any column name that appears in commonly joined tables.
Admin
I think it is because people verbally say I-D to mean identification. As in, "Please show me your ID."
Admin
i had one :
void function ( const SpecificHost &sh )
{
SpecificHost::iterator shIT = sh.begin() ;
}
ingenious ;)
--vat
Admin
This feature is definitely not in any way "Windows" specific. In fact, I'm almost sure there were EMACS modes that did the same thing long before Microsoft put it into their IDEs.
Admin
This reminds me... I once had the dubious pleasure of working on a self-service terminal of a globally-operating bank. The terminals talked to the backend via XML messages. The schema for those messages had a whopping 250KB, and that was only for a tiny subset of all defined messages! The main reason: it defined a separate datatype for nearly each single element of each message. Worse: all element names consisted of an E followed by a 6-digit number.
This was the result of generating the XML schema from the field definition of the backend mainframe system.
Admin
Our company has a product called "Easysound", which has an associated code "ESND". Now we have "Easysound Extended" or "ESEX". Of course, it's now always referred to as "EasySex".
Admin
Well, you really should be using the table name to identify your columns anyway. Not only for this reason but also because when someone else is trying to decipher what the query does, they don't have to guess which table each column comes from.
Admin
huh-huh-huh
he said "sex".
Admin
Chiming in with my own 2.63 cents (that's in Australian money, you see):
Form3.CheckBox57.Enabled := True;
Admin
Actually, this one makes perfect sense to me.
It's a boolean indicating whether you want to use Steve's fix from sept 24th 2003.
Oh hang on, it's not optional... never mind.
Drak
Admin
True, but Vim doesn't parse code. It only knows enough to do syntax highlighting (it gains that through some hideous regexps). I can't speak for EMACS because I never learned it.
Press the completion key in Vim and you don't get anything like you would in VS.NET (and presumably Eclipse and other decent IDEs). You get a list of all the words in the ctags file. If you know the first few letters of the method you're trying to call, you're a bit better off, but you still get shown methods that you can't actually call.
Intellisense narrows down your search to what is legal to call and also shows you the names and types of parameters of the method you're calling, including highlighting the parameter you're about to type.
I love Vim and still use it all day, in parallel with VS.NET, but its code completion is pathetic compared to Intellisense.
Rik
Admin
Here are some more weird names: http://blogs.msdn.com/brada/archive/2005/01/09/349678.aspx :)
Admin
Seriously, when I was at school, SSHing into unix command prompts and being forced to use VIM or EMACS really really really really sucked.
Emacs has this. Depending o/c on mode. Don't blame your lack of xp with a tool on the tool.
Blame the imposable steap learning curve.
Admin
char *CC_DiscardUntilMatchingCharIncludingNesting( char *input, const char *pairing )
bool CClass::CheckForPredictionFieldsInRecvTableNotMarkedAsSuchCorrectly( int &missingcount )
Those are the worst ones that I've personally seen, I believe
Admin
One of the production systems at my place of work has a object with a method named HavingItHardcore.
You have as much clue as I do as to it's intended use.
Admin
That's nothing like the worst long name in Cocoa. img = [img initWithBitmapDataPlanes:NULL pixelsWide:lls->width pixelsHigh:lls->height bitsPerSample:16 samplesPerPixel:4 hasAlpha:YES isPlanar:YES colorSpaceName:NSDeviceRGBColorSpace bytesPerRow:0 bitsPerPixel:0];
Admin
-[NSImage initWithBitmapDataPlanes: pixelsWide: pixelsHigh: bitsPerSample: samplesPerPixel: hasAlpha: isPlanar: colorSpaceName: bytesPerRow: bitsPerPixel:];
Okay, it's long. It's even very long. But it's not a WTF. It is extremely self-documenting code. No comments needed. It says what it does.
http://c2.com/cgi-bin/wiki?RonsealPattern and more generally http://c2.com/cgi-bin/wiki?CategoryNaming give some good ideas.
Of course, everyone has read Kent Beck's 'Smalltalk Best Practice Patterns', no? If not, why not?
Some of the other stuff was WTF, though.
Simon
Admin
Could be worse. Lispers often abbreviate the term 'S-expression' (the parenthesized lists that make Lisp programs) as 'sexp'. Take a guess how that is pronounced...
Admin
I personally think the right rule about SQL naming is to use same name for things that refer to same entity whenever possible.
So I would advice against calling a column just "id" if there ever is a likelihood that you will need to refer to it from another table. It makes it harder to mix up which id is what when writing SQL joins. Hence, foo_bar.fooId = foo.fooId is better, imo, than foo_bar.fooId = foo.id. See also SQL keyword NATURAL. (There is solution to the id "aliasing" problem which would be to create custom data types for each kind of id you are doing, and only define equality operations between objects of precisely same type, but I'm pretty sure no-one actually does that.)
Before anyone comments about mixing up foo_bar and fooBar, I like to name my glue tables with underscores that has a similar function than the html entity ndash, that is, parallelising two entities of similar importance.
But otherwise, I think avoiding the table name at beginning makes good sense. I like to say that it's "foo.name" rather than it's "foo.fooName". It's annoying having to repeat oneself without a good reason.
Admin
<font style="font-family: times new roman;" size="3">
It would be a lot easier to read if you spread it over several lines, which is the more typical approach AFAIK:</font>
img = [img initWithBitmapDataPlanes:NULL
pixelsWide:lls->width
pixelsHigh:lls->height
bitsPerSample:16
samplesPerPixel:4
hasAlpha:YES
isPlanar:YES
colorSpaceName:NSDeviceRGBColorSpace
bytesPerRow:0
bitsPerPixel:0];
<font style="font-family: times new roman;" size="3"> It might also have been clearer just what the method name is if you'd shown it without the arguments:
</font>
initWithBitmapDataPlanes: pixelsWide: pixelsHigh: bitsPerSample: samplesPerPixel: hasAlpha: isPlanar: colorSpaceName: bytesPerRow: bitsPerPixel:
<font style="font-family: times new roman;" size="3"> However, that's misleading in a different way, because of the unconventional way Objective C (and
Smalltalk, which it takes it from) handles method arguments; the equivalent in C++ would be something like:</font>
Admin
My favorite case of a bad variable was "BEANO", an obscure flag in several thousand lines of spaghetti COBOL with hundreds of GO TOs. I never did figure out what that name had to do with the variable's function.
After refactoring it I was distressed to find in my regression testing that my new version didn't give the same results. I eventually discovered that I had inadvertently fixed an unrecognized bug. This program -- a general ledger program -- had been quietly corrupting the books for years, shifting money from the occasional account to some random other account.
I asked my boss what we should tell the accountants. He said, "Don't tell them anything. They never noticed it, and we can't go back and repair the damage anyway. So there's no reason to get them upset."
Admin
For IDs, prepending the name is quite convenient, because it allows you to use NATURAL JOIN to join two tables without having to specify the key on which to join. (Though one might well argue that this is just a workaround for bad design of SQL, which ought to be using the foreign key relationships to decide how to join, in the absence of other information.)