• Martin (unregistered)

    It's also notable

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

  • Jochen (unregistered)
    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.

  • mikeash (unregistered) in reply to Martin
    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.

  • Avi Drissman (unregistered)

    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

  • Ross Day (unregistered)

    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.

  • Avi Drissman (unregistered)

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

  • *** (unregistered) 
    (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.

  • Fregas (unregistered) in reply to Avi Drissman

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

  • Sergio Pereira (unregistered)

    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

  • (cs) in reply to Ross Day

    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.

  • (cs)

    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/

     

     

  • harborpirate (unregistered) in reply to Ross Day

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

  • (cs)

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

  • Justin Sippel (unregistered)

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

  • (cs) in reply to Ross Day

    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

  • (cs) in reply to Justin Sippel
    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.
  • JAFO (unregistered)

    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?

  • SmarterThanThou (unregistered)

    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.


  • (cs) in reply to Charles Nadolski

    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.

  • (cs) in reply to Sergio Pereira
    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

     

  • (cs) in reply to harborpirate
    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:

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

     

     

  • (cs) in reply to TheDan666
    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?

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

     

  • Alex Feinman (unregistered) in reply to JAFO

    <FONT size=2>Pardon me for not being up to speed on VB & .NET but would I be crazy for assuming SqlCeException is derived from Exception?</FONT>

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

    <FONT size=4></FONT> 

  • (cs) in reply to Ross Day

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

  • (cs)

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

  • (cs) in reply to A Wizard A True Star
    A Wizard A True Star:

    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.


    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:

    public class Item { public Item() { /* details omitted */ } 
     public string ItemName
 {
      get { return _ItemName; }
      set { _ItemName = value; }
 }

 /* ... */

    }

    Because I know I would hate to have to always references myItem.ItemName...that would be TONS of fun. 

  • (cs) 

    applicationShouldTerminateAfterLastWindowClosed

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

    Brilliant

  • onefactor (unregistered)

    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]

  • Anonymous Coward from Slashdot (unregistered) in reply to Ross Day

    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.

  • (cs) in reply to A Wizard A True Star
    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."
  • machinshin (unregistered)

    i had one :

    void function ( const SpecificHost &sh )
    {
        SpecificHost::iterator shIT = sh.begin() ;
    }

    ingenious ;)

    --vat

  • brazzy (unregistered) in reply to Charles Nadolski
    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.
  • brazzy (unregistered) in reply to dubwai
    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.
  • Chris Brien (unregistered) in reply to machinshin

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

  • (cs) in reply to Anonymous Coward from Slashdot

    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.

  • anonymouse (unregistered) in reply to Chris Brien

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

  • (cs) in reply to dubwai

    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
    if IntToStrDef(Edit14.Text,-1) <> -1 then
        Form3.CheckBox57.Enabled := True;

  • (cs)
    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

  • Rik Hemsley (unregistered) in reply to bat
    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

  • CumpsD (unregistered)
  • emacs fanboy. (unregistered) in reply to Charles Nadolski

    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.

  • Josh Matthews (unregistered)

    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

  • (cs)

    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.

  • MrVacBob (unregistered)

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

  • Simon (unregistered) in reply to MrVacBob

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

  • (cs) in reply to Chris Brien
    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...
  • alan (unregistered) in reply to TheDan666

    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.

  • (cs) in reply to MrVacBob
    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];

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

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

    <font size="4">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. 
    </font>
  • Scott McKellar (unregistered)

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

  • (cs) in reply to Ross Day
    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.)

Leave a comment on “A Hodgepodge of Naming”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article