Comment On A Hodgepodge of Naming

It's also notable

applicationShouldTerminateAfterLastWindowClosed returns YES instead of true.
Way to go if you don't those crappy native types ;)

Alex Papadimoulis:

Next there's Stu Coates who came some rather interesting method names in a core dump after the Backup application on OS X crashed ...

[SNIP]

You should read "Undocumented Windows" about weird naming conventions.

Anonymous:

It's also notable

applicationShouldTerminateAfterLastWindowClosed returns YES instead of true.
Way to go if you don't those crappy native types ;)

Objective-C doesn't have a native boolean type, so I'm not sure what you're referring to.

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

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.

And Apple loves long function names that are very clear as to their function. The longest one in Carbon is SetAutomaticControlDragTrackingEnabledForWindow().

(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication

*)theApplication

{

     return YES;

}

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.

I've done that last one! Naming a variable Sex for (S)ql (Ex)ception!

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

Anonymous:

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.

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.

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/

 

 

"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.

Almost choked when I saw "_DontTouchThis". That's good!

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. :'(

Anonymous:

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.

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

Anonymous:

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. :'(

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.

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?

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.

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.

Anonymous:

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

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

 

Anonymous:

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.

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:

select * from Divisions
where Id = 1

Without brackets, it highlights the word "Id" in blue, but other than that, it runs fine.

 

 

TheDan666:

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.

Is it really that difficult to alias column names?

select Item.Id AS ItemId

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.

 

Pardon me for not being up to speed on VB & .NET but would I be crazy for assuming SqlCeException is derived from Exception?

Correct. It's WTF on its own. The SqlCeException will be never displayed, just caught silently

 

Anonymous:

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.

ross, my friend... you and i hate the same people... 

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".

A Wizard A True Star:

Is it really that difficult to alias column names?

select Item.Id AS ItemId

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.

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. 

applicationShouldTerminateAfterLastWindowClosed

This guy is so clever he figured out how to comment code without any comments.

Brilliant

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]

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.

A Wizard A True Star:

Secondly, why do people use ID instead of Id?

I think it is because people verbally say I-D to mean identification.  As in, "Please show me your ID."

i had one :



void function ( const SpecificHost &sh )

{

    SpecificHost::iterator shIT = sh.begin() ;

}



ingenious ;)



--vat

Charles Nadolski:

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.

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.

dubwai:

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.

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.

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".

Anonymous:

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.

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.

Anonymous:

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".

huh-huh-huh

he said "sex".

Chiming in with my own 2.63 cents (that's in Australian money, you see):

• Repeating the table name in the field name makes sense to
  me.  It helps me see what I'm looking at in an SQL display (such
  as PHPMyAdmin or whatever it's called) without having to rummage around
  the screen to find the first line.  It also gets over the issue of
  joins, reserved words and the like, without excess fiddling.  I've
  written SQL with and without doing it; there's no good reason not to do
  it (did someone say "it's too much typing"?  Come on!  How
  many weeks ago did you learn to program?) so I do it.


• I believe, though I'm not certain, that the Unix tags command
  predates Intellisense by some years.  Emacs supports it, though I
  blush to admit I haven't bothered installing it for my PHP work. 
  I refer to Emacs as TOOSYNACTE, which stands for The Only Operating
  System You Need (Also Contains a Text Editor).


• The biggest naming WTF I know of was a programmer, who's still a
  friend of mine, who wrote Delphi code and never changed the default
  component names.  (For those who came in late: Delphi is Visual
  Basic done right.  Rapid Application Development without the
  stupidity.)  So there were reams of pages of lines like

Alex Papadimoulis:

BOOL CSApp::FillDocFmtArrSave(CABDocFmtArr &arr, BOOL bSteve_09_24_2003)

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

the Unix tags command predates Intellisense by some years.

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

Here are some more weird names: http://blogs.msdn.com/brada/archive/2005/01/09/349678.aspx :)

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.

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

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.

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];

-[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

Anonymous:

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".

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...

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.

Anonymous:

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];

It would be a lot easier to read if you spread it over several lines, which is the more typical approach AFAIK:



img = [img initWithBitmapDataPlanes:NULL

          pixelsWide:lls->width


          pixelsHigh:lls->height

          bitsPerSample:16

          samplesPerPixel:4


          hasAlpha:YES

          isPlanar:YES

          colorSpaceName:NSDeviceRGBColorSpace


          bytesPerRow:0

          bitsPerPixel:0];





It might also have been clearer just what the method name is if you'd shown it without the arguments:




initWithBitmapDataPlanes:
pixelsWide: pixelsHigh: bitsPerSample: samplesPerPixel: hasAlpha:
isPlanar: colorSpaceName: bytesPerRow: bitsPerPixel:
 


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:

initWithBitmapDataPlanes(int pixelsWide, int pixelsHigh, int bitsPerSample, 
                         int samplesPerPixel, bool hasAlpha, bool isPlanar, 
                         ColorSpace colorSpaceName, int bytesPerRow, 
                         int bitsPerPixel);

Now, if you ask me, having a method with an arity of 10 is a mild WTF in any language, but I've seen worse.
Initializers tend to have large numbers of arguments. Whether the Obj-C or the C++ version is better would
depend on whether you see named arguments as useful documentation or an unnecessary encumberance;
it could be argued either way. 

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."

Anonymous:

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.

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.)