RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext and Other Long Function Names

Every reader should ask himself periodically “Toward what end, toward what end?” — but do not ask it too often lest you pass up the fun of programming for the constipation of bittersweet philosophy.

— Alan J. Perlis [foreword to SICP]

RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext (53 characters)

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:

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.

A histogram of the length of functions names exported by system DLLs in the Windows directory

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:

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.


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

2 thoughts on “RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext and Other Long Function Names

Comments are closed.