为什么UNIX / POSIX系统调用命名如此难以理解？

43

为什么使用诸如time和creat而不是getCurrentTimeSecsand createFile或者这样的非公开系统调用名，也许更适合Unix get_current_time_secs和create_file。这就引出了我的下一个要点：为什么有人想要cfsetospeed没有骆驼套的东西，或者至少要有下划线才能使之可读？当然，调用将包含更多字符，但是我们都知道代码的可读性更重要，对吗？

history posix system-calls

— 本约约
source

42

因为它们是在匈牙利记法之前几十年才发明的，所以骆驼箱，蛇箱等开始流行。同样是因为那时的编译器资源很少，而且标识符名称仅限于（IIRC）8个字符。

— lcd047

3

@phresnel不确定在文件名和变量ID之间看到什么关系，但是，我在8、12和14之间犹豫不决。也许变量ID的限制也为14。当然不是256+。至于表示法：请定义“始终”。Arminius是否使用CamelCase单词？也许不吧。在1990年代初期，Windows引入了匈牙利符号AFAIR。CamelCase和slipne_case是后来的变种。两者当然都在此之前使用过。我的意思是，它们在1990年代中期开始流行。

— lcd047

6

@phresnel：请注意，您的链接讨论了第一个Unix文件系统的局限性。当汤普森，里奇等。在设计 Unix时，他们不得不在尚未运行Unix的机器上引导 Unix ，即在可能甚至更受限制的环境中。

— DevSolar 2015年

11

您可能还会问为什么它们不是用德语编写的，因为那是我能想到的最接近的自然语言近似值，因为Java教给程序员的超长怪物已经接受了……

— R..15年

12

我很高兴这样试想一下，如何ls -la | grep将看起来像：listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint()。

— 2015年

61

这是由于时间的技术限制。POSIX标准创建于1980年代，并引用了1970年诞生的UNIX。当时，一些C编译器仅限于6或8个字符长的标识符，因此该标准确定了变量和函数的长度。名称。

相关问题：

— 博士01
source

5

我认为技术约束不适用。您可能有大于6个字节的文件，可能有跨越数千行代码的程序；抽象语法树的深度不只是六个层次，而且每个层次有更多的节点。出于某种原因，这6个字符的限制不是技术性的，而是设计的限制。它没有解释为什么“创建”比“创建”更好。另外，您能说一下您提到的几个C编译器吗？您的答案确实听起来像是“某个时候听到过”。

— phresnel

41

@phresnel：他不是在谈论文件大小，行数或语法树深度。C语言的旧版本并没有要求编译器和链接保留不止具有内部链接，标识符的前31个字符或超过6个外部标识。因此，get_current_date()并get_current_time()不能由一些早期的工具链的告诉分开。原因是这些系统只能在几千字节的微小空间内工作。

— DevSolar

34

但是你是对的creat()。肯·汤普森（Ken Thompson）曾经被问到，如果他重新设计UNIX系统，他会做些什么。他的回答是：“我会用e拼写创作。”

— DevSolar

8

@phresnel：只有有限的内存并不是硬性限制。有标识的只有有限的担保支持长度为。如果只保证您有6个有效字符，那就是您值得付出的代价。

— DevSolar

6

FWIW，旧的Fortran标准限制标识为6个字符。从本书中可以得出：“ Fortran规则在一个标识符中包含六个字符，是因为一个IBM 704单词可以代表六个字符。” 我不能代表C，但我想知道限制的起因非常相似（或者可能是相同的起源）

— tpg2114

26

dr01是正确的，但是还有另一个原因-可用性。过去，您没有像键盘那样舒适的键盘输入方式。如果幸运的话，您会拥有类似于老式打字机的功能。如果您不走运，则必须处理需要实际物理操作才能运行的系统（例如，按下“键”需要很大的力），或者您需要手动在卡上打孔。

这意味着即使在6-8个字符的限制内，您也尝试使命令尽可能短。这就是为什么您拥有ls而不是list和creat而不是的原因create。从那个时代的代码是充满变量一样a，x和i-当然，x2和朋友。打字是一项繁重的工作-如今，您打字所付出的精力listIndex要比过去“打字” 所付出的精力少i-而且它的速度甚至不再那么慢（尤其是使用自动完成等附加技术）。

真正的问题是-为什么即使不再需要这么多Unix习惯仍然存在？

— a安
source

23

当我的内核从更改time为getCurrentTimeSecs或之类的那一天，我将停止升级它。即使使用舒适的键盘和最新的硬件，这些名称仍然非常方便和简单（简单性是UNIX的基本原理之一）。我真的没有必要将这种Java / C＃风格的命名引入C语言，更不用说在Linux内核中了。IMO，从内核开发人员或UNIX开发人员的角度来看，这些习惯用法几乎是不受欢迎的。

— 约翰·史密斯

11

@Benjoyo 对我来说unRootlyLongNamed.Packaged.nonsensicalFunction是丑陋的，我宁愿确定它的作用而man 2 time不是猜测它的作用。

— muru 2015年

7

@Benjoyo好吧，任何不习惯这种环境的人都不应该首先使用系统调用，因为它们是专门为那些习惯的。（标准）库在这里供其他使用。UNIX不遵循这些时髦的设计“规则”，这些规则使乍一看就容易理解。这些谁使用它没有寻找到任何文档都在为一个很大的麻烦，而在UNIX界很少有人会认为这是一个需要解决的问题。

— 约翰·史密斯

4

@JohnWHSmith确保内核模式开发人员知道他们的系统和它的文档，但我们没有理由不具有简洁和告诉名字。

— Benjoyo 2015年

7

@JohnWHSmith作为一个卑微的开发人员，他只写过内核驱动程序，并且喜欢不包含缩写的有意义的名称，我不得不不同意。但这没关系，因为如果您查看原始的git源代码，就会发现至少一个内核开发人员同意我的观点。尽管如果您告诉Linus 内核开发人员不希望他get_X或他remove_file_from_cache（也许我建议rmfc？），请公开进行此操作-我很乐意看到他的反应。

— Voo，2015年

22

除了其他答案，我想指出的是，Unix是对Multics，CTSS和其他现代操作系统的一种反应，它们在命名约定方面更加冗长。您可以在http://www.multicians.org/devdoc.html上找到这些操作系统的感觉。例如，http://www.multicians.org/mspm-bx-1-00.html给出change_name了重命名文件的命令；比较Unix mv。

同样，保留非常短的系统调用名称的主要原因是向后兼容。您会注意到，较新的API往往更加明确。例如gettimeofday而clock_gettime不是仅仅time。

（即使在今天，在我的书中，使用whateverIndex代替代替i循环索引也是自动代码审查失败；-)

— 兹沃尔
source

2

是的当LISP Machines早于UNIX时，听到有关硬件功能的技术争论很有趣。当然，购买 UNIX机器更便宜，但仅此而已。即使到那时，增加维护成本（这当然也不算在* nix土地上）仍然可以改变表的面貌，但是无论如何它还是没有足够的说服力。（i是的，当您迭代一个数组时，它对于索引是很好的。坐标？使用x和y。遍历一些序数？是描述性的。）

— Luaan 2015年

@Luaan LISP机器不早于Unix。你失败了。

— pizdelect

@pizdelect从技术上讲这是正确的，但是技术上的事实不足以对某人snap之以鼻。

— zwol

@pizdelect抱歉，我的意思是Lisp早于UNIX（和C）。但是，如果您将LISP机器的商业影响进行比较，那么LISP机器本质上是现代的（UNIX大约有3年的领先优势，但是到LISP机器问世时，商业UNIX机器仍然很少而且相差甚远；大多数UNIX处于学术界或没有支持）。无论如何，它都是对当时普遍的技术论点的回应，当时是80年代，当时人们实际上是在UNIX计算机和LISPM之间做出决定，但它们是错误的。微型计算机无论如何都可以更快地运行LISP，这发生了变化。

— a安

10

丹尼斯·里奇（Dennis Ritchie）为自己设定了C约束，它不会依赖Fortran也不要求的任何链接器功能。因此，外部名称不得超过6个字符。

— 用户名
source

@downvoter您可能不同意Denni Ritchie的观点，但这就是他所做的。将此答案排除在外是徒劳的。

— user207421 '16