I find long functions names charming — I think they impart a certain personality to the API and add to the fun of programming. And while I try to avoid excessively long names in my own code at work (unless they add to clarity), I never fail to get a good kick seeing such names used by other programmers!

I’ve often wondered what the longest names would look like. So I decided to explore a large system — the system DLLs in C:\Windows directory — and dig up some of the biggies. My plan was to write a script that walked through the installed DLLs and looked at their exported functions list for interesting candidates.

The Winners

Here are the longer ones I could find:

• RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext [wcp.dll], with 53-characters, was the longest one (but this function is not documented)
• (52) ConvertSecurityDescriptorToStringSecurityDescriptor{A,W} [advapi32.dll], the function that Raymond Chen admitted was the reason for his post on security descriptors.
• (52) ConvertStringSecurityDescriptorToSecurityDescriptor{A,W} [advapi32.dll], the complement of the above.
• (50) CreatePrivateObjectSecurityWithMultipleInheritance [advapi32.dll], another security function.
• (50) CertCreateCTLEntryFromCertificateContextProperties [crypt32.dll].
• (50) EapHostPeerQueryUIBlobFromInteractiveUIInputFields [eappcfg.dll].
• (49) AccessCheckByTypeResultListAndAuditAlarmByHandle{A,W} [advapi32.dll], yet another security API — I guess the security API programmers get a good kick from long names, just like me!
• (47) GetNumberOfPhysicalMonitorsFromIDirect3DDevice9 [Dxva2.lib].
• (43) SetupRemoveInstallSectionFromDiskSpaceList{A,W} [Setupapi.dll].

And just so that no one thinks I’m making these up, I’ve linked to their documentation!

Curious on seeing these names, I dug through the other “operating system” I had access to — GNU EMACS. The longest interactive command there is slime-compiler-notes-default-action-or-show-details/mouse: Counting punctuations, this beats the longest Windows export by 4 characters.

The Method

I used the pefile Python library to parse all DLLs in my windows directory. I only considered “system” DLLs (ignoring any third-party drivers etc.) by checking for “Microsoft” in the DLL copyright-string. In addition, I discarded any C++-ish exports, because the C++ name-mangling skewed the results too much and I was too lazy to hook in a “undecoratify” procedure.

Finally, on my 64-bit windows installation, there are both 32-bit and 64-bit versions of many core DLLs (in System32 and SysWOW64 directories respectively), and I encountered duplicates. A similar thing happened with SxS DLLs.

Using this Python script I coded, I generated a delimitered text-file with around 1500 entries that I manually scanned (I had some time to waste!) for “interesting” names. Below is a histogram of the function-name lengths. The rough bell shape gives me confidence that script wasn’t totally off the mark.

Functions Taking Lots of Parameters

A second axis to dig “interesting” functions would be to count the number of function params.

This one is a bit of fuzzy due to questions like “Do you count deep“? In that when a function accepts a pointer to a struct, do you count the struct members as inputs too? For instance, CreateFontIndirectEx [gdi32.dll] takes a pointer to ENUMLOGFONTEXDV structure that holds about two dozen items (all things considered).

Counting params is also more work, at least for DLL exports (where you need to cross-reference with documentation/headers if the export is, at all, public). Otherwise, the problem can be approached differently by forgetting DLL exports entirely and instead using a crawler that walks the the locally installed MSDN and parses the “Syntax” section to count the number of params — just assuming num_params = num_commas + 1 might be good enough.

Anyway, manually browsing through some of MSDN, I chanced upon a few gems:

• AccessCheckByTypeResultListAndAuditAlarmByHandle, our friend from above, true to its character, takes 17 parameters!
• OleCreateFromFileEx takes in a filename, interface ID, flags, sink, connection, site… 13 in all.

On a Serious Note

Well named functions (just like well named variables) are good instant documentation. Descriptive function are important when:

• Such functions all belong to a flat namespace (DLL exports or C code)
• Several of them have very similar purpose (like the six or so AccessCheck* APIs)

Such names become even more relevant when they define the public API of your library/system.

Some people (“constipated by bittersweet philosophy”?) dislike long function names, and I wonder why. The argument that longer functions take longer to type seems mostly dud: Visual Studio with the awesome Visual Assist X addon does Intellisense beautifully; Emacs with hippie-expand does some good magic (the brave also have CEDET); Eclipse, BBEdit, and Vim surely have their own thing. So typing isn’t a problem. And with machines so fast and powerful, the (JIT)compilation/linking-time for longer function names should be irrelevant in most cases.

Links

While researching for this entry, I came across the post “Best” method names ever by Brad Abrams that has some interesting content/comments.

[Note: Lest someone should give a wicked twist to the whole point of this post, I should add that I have most sincere respect for Microsoft engineers, enjoy using their programs every day and working with their APIs.]

I was going through the first chapter of the book Graphical Enumeration by Frank Harary and Edgar M. Palmer when I chanced upon this perplexing footnote:

Read wrote Wright that both Read [R2]¹ and Wright [W3]² were wrong. So Read and Wright wrote a joint erratum [RW1]³ to set things right. This may be wrong since Wright asserts that Wright wrote Read first.

It appears on Pg. 17 in reference to k-colored graphs. Read and Wright are, of course, the mathematicians Ronald C. Read and Edward M. Wright!

A quick glance at the bibliography confirms that the above footnote describes, even if humorously, a true incident. However, I can’t say what the last sentence means: This may be wrong since Wright asserts that Wright wrote Read first. Does it mean:

• There is a genuine priority dispute as to who figured the error out [I don't think this is the case]. Or,
• Since [RW1] paper has Read as the first author (so, in that sense, “Read wrote first”), Wright couldn’t have written first. Or,
• Since “write” must happen before “read”, Wright wrote first. Or,
• It doesn’t mean anything — the authors are just playing around with words!

I could not find anything relevant by searching the phrase “Read wrote Wright” on Google.com. I’ll be eager to learn any other clues the reader might have as as to the meaning of the last sentence of the footnote.

Aside: It is sad that the Graphical Enumeration book, which was published by Academic Press, New York (1973), has apparently gone out of print. I’ve added it to the out of print math blog.

1. [R2] R.C. Read, The number of k-colored graphs on labelled nodes, Canad. J. Math. 12, 409–413 (1960).
2. [W3] E.M. Wright, Counting coloured graphs, Canad. J. Math. 13, 683–693 (1961).
3. [RW1] R.C. Read and E.M. Wright, Coloured graphs: A correction and extension, Canad. J. Math. 22, 594–596 (1970).

Some time back, I had read a hilarious piece by Shashank, a friend of mine from the days at BITS, Pilani. The auto-podal-tow phenomena that he describes has to be seen to be believed: an autorickshaw towing another with one of the drivers using his leg as a connection! A good soul captured the moment and licensed it under Creative Commons Attribution-Noncommercial 2.0 Generic.

It would have been unfortunate to have left a phenomenon as recurrent as the auto-podal-tow without a name. Shashank did his part, and I’ll do mine by documenting two other phenomena that deserve to be “named and conquered”. People who haven’t been on Indian roads will have to get their imaginations working (since I couldn’t find images for them).

First there is, what we’ll call, the autorickshaw-big-v-formation: In a 2-lane road, a bunch of auto-rickshaws (usually three to five in number) do a V-formation that’s impossible for anything but a motor-bike/scooter to breach. While the V-formation is the most commonly sighted one, other tactical formations are also deployed to advantage.

Second, there’s a phenomenon known as differential-velocity-autorickshaw-overtake-maneuver. To a casual observer it would appear that two or three autorickshaws are engaging in a line-abreast formation; but in all probability, something more subtle is under way. What’s really happening is that one of the autorickshaws is running just a little bit faster than the one alongside it (any non-zero , no matter how small, would be sufficient for our purpose); and the -faster autorickshaw is doing the only reasonable thing to under such circumstances — overtake the slower one. The phenomenon usually lasts for a good one-two minutes before the “formation” is broken.