I understand that in the earlier days of computing, shorter method names like printf made sense, because storage was limited. But why do modern languages like Python and Go still use the less readable names from the C APIs? Why don't they switch to a more readable form like print_format, the same goes for other names. I wouldn't mind having to write make_directory instead of mkdir in go.

People have suggested that this question has been asked before, but the questions I've found are about whether abbreviated names are bad practice. This question assumes that the answer to this question is usually yes.

  • 20
    Specifically for Python's os module (since you mentioned Python and mkdir), the functions use the same short, cryptic names as C because they are little more than wrappers around the C functions, so it make sense to name them the same way. The function name reminds you that the function isn't doing much more than calling the low level C library functions.
    – Dan Albert
    Commented Jul 23, 2013 at 23:21
  • 10
    Because they were computer experts for the most part, and they didnt see any advantage to naming it something other than what the *nix command they had been using for 20 years was called? I really hate questions like this. You might have a point for something like Go, but Python is ancient in comparison (older than Java, C#, Go, Dart, Javascript...) Commented Jul 24, 2013 at 4:03
  • 7
    <PEDANT><COMMENT>Its actually a FORTRAN style printf()</COMMENT></PEDANT> Commented Jul 24, 2013 at 6:23
  • 6
    Python is not modern BTW, it was created 22 years ago.
    – Den
    Commented Jul 24, 2013 at 8:36
  • 8
    Just switch to a language that has annoyingly long method names. I'd become violent if I had to use print_format instead of "printf". The underscore is especially annoying. Then again, I'm easily annoyed. :D Commented Jul 24, 2013 at 17:13

9 Answers 9


But why do modern languages like python and go still use the less readable names from the C apis?

  1. Because everyone (in their domain) knows the short names. If you made different names, people would question "what makes this different from mkdir?" and generally get confused that stuff isn't where they expect it.

  2. Because without auto-complete in an IDE, long names with generally difficult to type characters like _ annoy skilled programmers. Annoyed programmers limit the adoption of a language, meaning designers don't make the names or you never hear about the languages that used them since they never took off.

These are both kinda flimsy arguments of course.

Readable code is known to be better than writable code these days. And having an IDE with auto-complete handles option 2, though there are still people who argue against IDE's as bloat, or a crutch that hinder programmers' abilities. Having an IDE with intellisense (or the equivalent) helps a bunch with #1 as well, though that has the same arguments and works less well in a non-object oriented environment.

Still, these flimsy arguments (and the vagaries of human taste) are enough momentum to keep the trend going.

  • 7
    Not that flimsy when you consider how quickly a proficient programmer picks up a new dialect (after all, most common languages are just a dialect of LISP or C) with the aid of good documentation (and google). Compare this to domain terminology and TLA's that invade all software, and often poor choice of variable names and poor documentation..... The problem of short names like printf is so far down the list......
    – mattnz
    Commented Jul 23, 2013 at 23:11
  • 3
    Are you implying that liking long method names negatively correlates with programming skill? Commented Jul 24, 2013 at 5:35
  • 2
    @congusbongus - not in general, though in certain domains (systems programming, shell scripting) the correlation tends to hold, since the use of IDEs is non-existent there.
    – Telastyn
    Commented Jul 24, 2013 at 11:27
  • 7
    #1 isn't flimsy because many of the short names are enshrined in POSIX, a well-known, well-supported standard. If you're going to mimic the standard's behavior or simply call your system's compliant function by the same name, why not name yours the same way? That also cuts your documentation down to "Implements POSIX mkdir()."
    – Blrfl
    Commented Jul 24, 2013 at 17:16
  • 2
    "Because it's always been done that way" is not such a flimsy argument if you put a lot of effort into learning the "standard" names, only to have someone come along and change all of them just because they think the new ones are prettier. Commented Jul 25, 2013 at 4:52

Why do we continue to use the old Germanic "Albert" as a boys name and not the modern English translation "Shining Hero"?

Because a name is just a label. It's good to give new stuff a meaningful name, but, after long usage the name itself becomes the meaning.

printf means something very specific to generations of programmers -- a print function with a template that will use %2d to indicate where you want a two digit number printed etc.

On the other hand print_format would indicate a function that will somehow format and print some data and you will need to look up the docs to find out how to use it.

  • 10
    I don't think it's a good analogy. With given names, no one cares about the meaning behind the name because it has nothing to do with the actual person. With the method names it's quite the opposite: the closer the function name is tied to what it does, the better. It's not just a label.
    – Malcolm
    Commented Jul 24, 2013 at 22:18
  • 2
    The point is "Albert" means the guy with freckles who doesn't pay for his beers. The name has been assigned a meaning -- not the other way around! Commented Jul 25, 2013 at 2:12
  • 3
    Yes, it works that way with given names. They are given randomly at birth when no one has even a slightest idea what the person is going to be like. You aren't saying that programmers usually pick a random name for the function, and then make it do something, are you? Even if some do, that's obviously a very poor programming style.
    – Malcolm
    Commented Jul 25, 2013 at 8:51
  • 1
    I'd name my son "Shining Hero".
    – JesseTG
    Commented Jul 25, 2013 at 20:18
  • 5
    Why stop at print_format when you could do print_using_values_substituted_from_arguments? And how long before someone gets aggravated typing all of that out and shortens it to puvsfa?
    – Blrfl
    Commented Jul 26, 2013 at 11:59

It's simple. Using the traditional names is convenient for millions of experienced programmers. We know what "mkdir" and "printf" mean. It is slightly inconvenient for novices, but they soon get over it.

Similarly, most (all?) LISP dialects continue to use "car" and "cdr" instead of "head" and "tail".

  • 1
    I see the point, but it seams like a long vs short term benefit. If a language changes those names, generations of programmers to come won't have to overcome those hurdles
    – bigblind
    Commented Jul 23, 2013 at 22:30
  • 6
    True, but if you want adoption of your language you must cater to current programmers, not future programmers. ;-)
    – sergut
    Commented Jul 23, 2013 at 23:45
  • 9
    Languages such as C# had opted for the more readable forms of well-known OS method names in their API. Directory.CreateDirectory
    – rwong
    Commented Jul 24, 2013 at 2:44
  • 2
    @bigblind You're a novice once per language, and experienced for as long as you continue using it after that. So which is long term and which is short?
    – Useless
    Commented Jul 24, 2013 at 8:15
  • 2
    Rather than pitching it as "long vs short term", I'd say it's a library designer's dare (willpower) to innovate (breaking existing customs). Both choices have pros and cons.
    – rwong
    Commented Jul 25, 2013 at 3:11

As others have already said, a lot of these keywords have well established meanings and make it very easy to pickup a new language etc. They are usually shorthand for existing words by omitting some letters (mostly vowels), its not like someone mashed random letters and decided, 'eokjgv' is going to be my function for make_directory.

Shorter names do have actual benefits beyond not having to rely on auto complete:

  • Can fit more context into fewer lines or a single screen
  • No confusion of trying to reconcile strict computer science meaning with the common language meaning
  • Faster disambiguation: if you want to distinguish between print_formatted_string, print_formatted_string_from_file, print_string_with_line it will take far longer than printf, sprintf, println.

Of course, inertia and culture are also massive factors - in common languages, your question is similar to asking: Why don't people switch to Esperanto instead of English with its confusing grammar and huge vocabulary?

You can see verbose programs by reading pseudocode : create pseudocode for some small method and see how much volume is added to it, and remember that human short term memory is also a finite quantity.


Because your assumption that "longer names are better readable" is simply not true!

On the contrary, the shorter a name, the higher the chances (other things being equal), that you can identify the name at once, like an icon.

But there's more: the chances that you confuse identifiers that have only a few differences is greater the longer the names are.

As always, there is a middle ground. A public method in an API should not be a single letter, and a temporary local variable must notbe a poem.

  • 1
    +1 When skimming, people look at the first and last letters of a word, plus the length.
    – Vorac
    Commented Aug 8, 2013 at 14:30
  • 1
    @Vorac - Actually, when reading novels translated from Russian, where people often have long names that all end in "-ski", I am often confused. Because my brain constructs a most general pattern (or so it seems) to detect those letter clusters that do not make any sense in my language (German). Hence it may happen that "Domedojewski" and "Dokadojurski" are taken for the same person, until suddenly I ask myself: Wait, didn't this Do.*ski pass away two chapters before? How can he appear now again? Chinese novels, OTOH, are easier, because people there have names like Wong, Hang or Lao.
    – Ingo
    Commented Aug 8, 2013 at 17:20

Mandatory xkcd reference:

how standards proliferate

Let's say you design a language, or a next version of an existing language, and say "let's forget the old C-style names, I have a better idea". You rename mkdir to make_directory. Someone else, following the same way of thinking, invents create_directory, a third one create_dir, the next one new_directory, and so on. Now the programmers have a much harder time learning a new language or a new dialect, because instead of instantly recognizing what a command does and what parameters it expects, they have to read through the manual. By not having the same names and structure, it can be much more likely to have a different use or different order of parameters (if I remember correctly, .NET liked to do this in the beginning, some methods had the parameters like source, destination, others like destination, source). It makes programming either more error-prone, or much slower as the programmer has to read the manual every time he uses a function, because one can never be sure what parameters this function in this language in this version is using.

If ALL language designers could agree to change the C-style names for all future languages in exactly the same way, it might make some sense to do it. Good luck in achieving that!

Common roots and cultural heritage are not there without a reason.


As others have said, it's mainly because these are frequently just wrappers around the C calls. And there is a huge benefit in that being the case (including the short name), basically programmers new to the language know what to expect from it -- what arguments it takes, what side effects it might have, how error conditions are handled.

If I see:

printf ("Width trick: %*d \n", 5, 10)

I know that (a) this is a right justified, and (b) that it can take up to 5 spaces. If I see:

printf_formatted_string("Width trick: %*d \n", 5, 10)

I have no idea what it means, without looking it up.


The shorter C-style names also convey that although this language is not C; the language has a C heritage and this printf is our take on our venerable ancestors printf function adapted for our language.

C is very much a foundation language and new languages can gain a lot by stating that they are "C-style".

Similarly other languages may purposefully embed the Unix way of doing some tasks and reinforce that by adopting Unix names for doing similar (or identical) things. If you are familiar with the Unix chmod command and implement chmod-like functionality in your language with maybe a similar API, then it might be better to call it chmod in your language rather than change_mode or whatever. It means that you can re-use your Unix experience

Some people believe that what you may do often in a language should have a shorter name.


To do anything useful, all languages need to interact with operating systems but not all languages make calls to OS directly because there's no API defined for these languages. POSIX, for example, only defines API with binding to C and Ada.

A very important part of OS is the C library (libc), which implements the OS' API, at least after POSIX was defined. POSIX was basically defined based on existing libcs implementations.

If there's no language specific API for a language, then it has to use functions available in libc. It is up to the language designer then to either rename or reuse libc function names and export that as libraries.

I think languages that run on virtual machine (vm as in jvm) shouldn't have the same problem (if it's really a problem).

Not the answer you're looking for? Browse other questions tagged or ask your own question.