What is the reason to use such untelling system call names like time and creat instead of getCurrentTimeSecs and createFile or, maybe more suitable on Unix get_current_time_secs and create_file. Which brings me to the next point: why should someone want something like cfsetospeed without camel case or at least underscores to make it readable? Of course the calls would have more characters but we all know that readability of code is more important right?

  • 44
    Because they were invented decades before Hungarian notation, camel case, snake case, and the like became fashionable. Also because back then compilers had very few resources, and identifier names were limited to (IIRC) 8 characters.
    – lcd047
    Commented Jul 9, 2015 at 7:33
  • 3
    @phresnel Not sure what relation do you see between filenames and variable IDs, but yeah, I was hesitating between 8, 12, and 14. Maybe the limit was also 14 for variable IDs. It certainly wasn't 256+. As for the notations: please define "always". Did Arminius use CamelCase words? Maybe not. AFAIR, the Hungarian notation was introduced for Windows in early 1990's. CamelCase and sneak_case were later variations. Both were of course used before that. What I'm saying is that they have become popular about the mid 1990's.
    – lcd047
    Commented Jul 9, 2015 at 12:17
  • 6
    @phresnel: Take note that your link talks about the limitations of the first Unix filesystem. When Thompson, Richie et al. were designing Unix, they had to bootstrap Unix on machines that did not run Unix yet, i.e. in probably even more constrained environments.
    – DevSolar
    Commented Jul 9, 2015 at 13:01
  • 11
    You might as well ask why they're not written in German, because that's about the closest natural-language approximation I can think of for the over-long monstrosities Java has taught programmers to accept... Commented Jul 9, 2015 at 22:15
  • 17
    I'm so happy it is like this. Imagine how a ls -la | grep would look like: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().
    – Pouya
    Commented Jul 10, 2015 at 14:29

4 Answers 4


It's due to the technical constraints of the time. The POSIX standard was created in the 1980s and referred to UNIX, which was born in the 1970. Several C compilers at that time were limited to identifiers that were 6 or 8 characters long, so that settled the standard for the length of variable and function names.

Related questions:

  • 5
    I don't think Technical Constraints applies. You could have files larger than 6 bytes, you could have programs spanning thousands of lines of code; abstract syntax trees way deeper than just six-levels, and with way more nodes per level. Just out of reason, the 6 character limit can't be technical, but rather a designed one. And it does not explain why "creat" is better than "create". Also, can you please name those several C compiler you talk about? Your answer really reads like "heard somewhere somewhen".
    – phresnel
    Commented Jul 9, 2015 at 11:49
  • 42
    @phresnel: He's not talking about file size, number of lines, or syntax tree depth. Old versions of the C language did not require compilers and linkers to keep more than the first 31 characters of identifiers with internal linkage, or more than 6 for external identifiers. Thus, get_current_date() and get_current_time() couldn't be told apart by some of these early toolchains. The reason was that these systems were working on tiny footprints of a few kilobytes.
    – DevSolar
    Commented Jul 9, 2015 at 12:43
  • 34
    But you're right on creat(). Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e."
    – DevSolar
    Commented Jul 9, 2015 at 12:45
  • 8
    @phresnel: Having only limited memory is not a hard limit. Having only a limited guaranteed supported length of identifiers is. If you're only guaranteed 6 significant characters, that's what you're working with if you're worth your salt.
    – DevSolar
    Commented Jul 9, 2015 at 14:31
  • 6
    FWIW, the old Fortran standards limited identifies to 6 characters. From this book: "The Fortran rule of six characters in one identifier stems from the fact that six characters could be represented in one IBM 704 word." I can't speak for C, but I imagine the limitation has an very similar origin (or perhaps, identical origin)
    – tpg2114
    Commented Jul 9, 2015 at 23:39

dr_ is right, but there's also another reason - usability. Back in the day, you didn't have something as comfortable as a keyboard to type on. If you were lucky, you had something akin to an old-school typewriter. If you were unlucky, you had to deal with systems that required actual physical work to operate (as in, it took a lot of force to press the "key"), or you manually punched holes in a card.

This meant that even within the 6-8 character limit, you tried to keep your commands as short as possible. That's why you have ls instead of list, and creat instead of create. Code from that era is full of variables like a, x and i - and of course, x2 and friends. Typing was a lot of work - today, you're less exerted from typing listIndex than you used to be from "typing" i - and it isn't even all that slower anymore (especially with additional technologies like auto-completion).

The real question is - why do so many Unix idioms persist even though they're no longer desirable?

  • 24
    The day my kernel changes from time to getCurrentTimeSecs or something like that, I'll just stop upgrading it. Even with my comfortable keyboard and recent hardware, these names remain extremely convenient and simple (simplicity being one of UNIX's fundamentals). I really don't feel the need to bring that kind of Java/C#-style naming into the C language, let alone in a Linux kernel. IMO, from the perspective of a kernel developer, or UNIX developer in general, these idioms are nothing close to undesirable. Commented Jul 9, 2015 at 16:13
  • 11
    @Benjoyo unRootlyLongNamed.Packaged.nonsensicalFunction is ugly to me, and I'd rather be sure what it does by doing man 2 time than guess at what it seems to do.
    – muru
    Commented Jul 9, 2015 at 16:34
  • 7
    @Benjoyo Well, anyone who is not used to this environment isn't supposed to use system calls in the first place, since they are specifically meant for those who are. (Standard) libraries are here for the others. UNIX does not follow these fashionable design "rules" that would make it easily understandable at first glance. Those who use it without looking into any doc are in for a lot of trouble, and few people in the UNIX community would consider that a problem to be solved. Commented Jul 9, 2015 at 16:44
  • 5
    @JohnWHSmith sure kernel mode developers will know their system and its docs but that is no reason for not having concise and telling names.
    – Benjoyo
    Commented Jul 9, 2015 at 17:35
  • 8
    @JohnWHSmith As a lowly dev who only ever wrote kernel drivers and prefers meaningful names that are not full of abbreviations I have to disagree. But that's alright, because if you look for example at the original git source code, you'll find at least one kernel dev agreeing with me. Although if you tell Linus that his get_X or remove_file_from_cache (might I propose rmfc?) are undesirable to kernel developers, please do it publicly - I'd love to see his reaction.
    – Voo
    Commented Jul 9, 2015 at 18:31

In addition to the other answers, I would like to point out that Unix was developed as a reaction to Multics, CTSS, and other contemporary operating systems, which were significantly more verbose about their naming conventions. You can get a feel for these OSes at http://www.multicians.org/devdoc.html. For example, http://www.multicians.org/mspm-bx-1-00.html gives change_name as the command for renaming a file; compare Unix mv.

Also, the principal reason why the very short system call names persist is backward compatibility. You will notice that newer APIs tend to be more explicit; e.g. gettimeofday and clock_gettime instead of just time.

(Even today, using whateverIndex instead of i for a loop index is an automatic code-review failure in my book ;-)

  • 3
    Yeah. It's funny hearing the technological argument about hardware capabilities when LISP Machines predate UNIX. Sure, UNIX machines were cheaper to buy, but that's about it. Adding maintenance costs (which of course don't count in the *nix land) turned the tables even then, but it wasn't a persuasive enough argument anyway. (And yup, i is fine for an index when you're, say, iterating an array. Coordinates? Use x and y. Traversing some ordinal? Be descriptive.)
    – Luaan
    Commented Jul 9, 2015 at 20:16
  • @Luaan LISP machines do NOT predate Unix. You fail.
    – user313992
    Commented Jun 17, 2019 at 20:06
  • @pizdelect That's technically true, but technical truth is not sufficient reason to snap at someone.
    – zwol
    Commented Jun 17, 2019 at 20:43
  • @pizdelect Sorry, I meant Lisp predates UNIX (and C). But LISP machines were essentially contemporary, if you compare their commercial impact (UNIX had a head start of about three years, but by the time LISP machines came, the commercial UNIX machines were still few and far between; most of UNIX was in academia or with no support). In any case, it's a response to the common technological arguments at the time, which was the 80s, when people were actually deciding between UNIX machines and LISPMs, and they were wrong. That changed with micro-computers which could run LISP faster anyway.
    – Luaan
    Commented Jun 18, 2019 at 6:59

Dennis Ritchie set himself a constraint with C that it wouldn't rely on any linker features that weren't also required by Fortran. Hence the 6 character limit on external names.

  • 2
    @downvoter You may not agree with Denni Ritchie about this, but that's what he did. Taking it out on this answer is futile.
    – user207421
    Commented Dec 17, 2016 at 23:53
  • First rule of downvotes: don’t talk about downvotes. Commented May 10, 2022 at 9:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .