為何 Linux 的系統 API 相比 Win32 到處是縮寫？有何優劣? 造成兩者差別的原因是什麼？

01-15

大家也可以發表一下自己對兩種 API 的評價。

Linux的API縮寫是歷史遺留問題造成的，因為Linux開發的目的是為了取代Unix，所以在API上基本要和Unix保持兼容一致。

而Unix是1970年左右由 KR兩位老爺子開發的，他們先設計了Unix，然後又設計了C語言，用C語言重新實現Unix，但是早期的C編譯器只支持8個字元的符號名，所以所有符號包括函數名，變數名都要壓縮到8個字元或以下，你會發現C的keyword都沒有8個字元以上的，現在有些超過8字元的C keyword都是後來的標準加進去的，比如C99加了好多。

Unix的API就是一個C function，名字也不能超過8字元，所以就導致用了很多縮寫，而這些縮寫成為了事實標準，又傳遞給了Linux。

而微軟開發 Windows已經是 1985年了，距離C語言發明十多年過去了，編譯器也進步了，所以支持長符號名已經沒問題了，用長名字，把單詞拼寫完整還是有利於可讀性的。

1990年左右開發的NeXTSTEP，就是macOS和iOS的前身，雖然繼承自Unix，但是上層API是用Objective-C開發的，對長符號名支持已經很好了，所以大量使用長函數名，有的函數名簡直就是篇小短文。

比如：CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications，這是個iOS上的C 函數 API。

更多長名字請參考：Quotation/LongestCocoa

早期的文本編輯器沒有自動完成，所以用長名字會導致代碼輸入很麻煩，但是現代編輯器自動完成已經是標準配置，並且已經很智能了，所以更推薦用長符號名，以可讀性為第一原則。

Unix 最早（V0 ~ V6）是在電傳打字機上開發的（Ken amp; Den picture），Teletype Model 33，我只在博物館裡見過實物。如果你用過針式印表機，可以理解為那玩意兒加個鍵盤。編輯源代碼是列印在紙上，而不是顯示在屏幕上。所以 Unix V6 的源碼每行都很短，左花括弧放行尾，否則費紙費墨費時間（ASR-33 一秒鐘可以打10個字元，一行代碼要好幾秒鐘才能列印完）。常用命令（unix-6th - 1）只有兩個字母同理，ls、mv、cp、rm、wc、ln、cc、ld、nm 這些命令的輸出都要列印到紙上。

視頻終端 ADM-3A （可以理解為帶鍵盤的顯示器）出現之後，才有了 vi 這樣的全屏編輯器（出處見此）。之前是用所謂的「行編輯器」。如果你用過 DOS 3.3，那麼你可能還記得 edlin 這個工具，就是那個感覺。ADM-3A 每行顯示80個字元，現在有的編碼規範的行寬限制搞不好是從這台40年前的設備繼承的。

另外一個原因，受 Fortran 影響，當時的 linker 只支持 6 個字元的外部名稱，因此有 malloc, memcpy, printf, strcpy, strcat 這一大堆剛好 6 個字元的函數名（見早期 manpage unix-6th - 2）。putchar 這個「函數」其實是個宏，用 putc() 實現，不是外部名稱，所以才不受這個限制。

What is the exact role of significant characters in C (variables)?

和

C - Why did ANSI only specify six characters for the minimum number of significant characters in an external identifier?

話說覺得自己好老。

早年的C語言變數只能用8個字元，所以程序員老圈子形成了非常獨特的縮略語言體系，大致是把清輔音留下，濁輔音和母音刪掉，也有些單音節母音要被留下。最經典的，比如：

button =&> btn

reset =&> rst

convert =&> cvt

而且這只是一種大致的文化，沒有任何約束力，然後又有一堆不怎麼懂的人，秉持著敲字元少就是寫代碼快的思想瞎jb學，造出了更奇怪的詞，時間久了就這樣了。

而windows誕生的晚，又是大廠生產的，上面架構師定coding convention和design，然後程序員來寫代碼的，並且強制code review的，所以實現可能很噁心，但是命名這種事肯定超級規範超級統一。

UNIX新手總是對UNIX對命令的命名表示驚訝。在DOS和Mac上受的教育不足以讓他們體會

到cp、rm、ls這類兩字母命令的簡潔和優美。
像我們這樣用過70年代早期的IO設備的人都能理解，ASR-33 Teletype這類設備的速度、
可靠性，以及它的鍵盤是萬惡之源。和今天這種基於反饋原理、只需要關閉一個微開關
的鍵盤不同，你必須用足力氣撳下Teletype的鍵至少半英寸，以發動一個類似自行車上
用的小型發電機，在上面操作要冒指骨骨折的危險。
如果當時Dennis和Ken用的是Selectric而不是Teletype，可能今天我們敲的將不是」cp
」和」rm」而是」copy」和」remove」了。（Ken Thompson曾被問道如果他能重新設計U
NIX他將做什麼修改，他回答說：「我會在creat命令後加上個e。」），科技在拓寬我們
的選擇的同時，也能限制我們的選擇，此一例也。
20多年過去了，還有什麼理由延續這一傳統呢？理由就是「歷史的無可替代的力量」，

歷史就是那些存在的代碼和教科書。如果一個廠商用remove替代了rm，那麼所有UNIX教
科書就不適用於這一系統了，每個使用rm的shell腳本都需要被修改。而且這也不合POSI
X標準。
一個世紀前，打字高手由於擊鍵過快，經常把打字鍵柄攪在一起，工程師設計了QWERTY
鍵盤，於是問題得到了解決，因為沒人能在這樣的鍵盤上打得快。計算機的鍵盤不再有
機械鍵柄，但QWERTY的鍵盤布局仍然在使用。同理，在未來的一個世紀中，我們仍然會
繼續使用rm。

以上摘自《UNIX痛恨者手冊》。看到這裡大家大概也就明白了那些縮寫得莫名其妙的API是哪裡來的了。

太長了就非得靠intellisense了，不然你看這個

SecondaryAuthenticationFactorAuthenticationStageChangedEventArgs Class

當然，*nix里的creat一定是create的縮寫，不是拼錯了，嗯嗯。

就是程序員風格，你怎麼不說下劃線命名和PascalCase的差別呢……

全稱其實更適合推廣，調用的人只要熟悉英語就很容易拼對API，而creat這種就需要記憶了；但反過來，如果沒有自動補全，對於獨立開發的人來說自然寫得越短越輕鬆了。

另外很多其實賴不到Linux頭上，是從Unix時代就繼承下來了，畢竟最早的Unix也只是兩個程序員自己瞎折騰出來的。

linux api不是就一個syscall嗎

縮寫就縮寫吧，你把create縮成creat, 啥意思？

據說unix剛發明的那個年代，鍵盤的按鍵都硬得跟石頭一樣，程序員為了保護指關節，盡量使用儘可能短的變數/函數命名，所以unix及它的後繼者linux就到處是縮寫了。

API（Application Programming Interface,應用程序編程介面）是一些預先定義的函數，目的是提供應用程序與開發人員基於某軟體或硬體得以訪問一組常式的能力，而又無需訪問源碼，或理解內部工作機制的細節。

　　Windows API：

　　API函數包含在Windows系統目錄下的動態連接庫文件中。Windows API是一套用來控制Windows的各個部件的外觀和行為的預先定義的Windows函數。用戶的每個動作都會引發一個或幾個函數的運行以告訴Windows發生了什麼。這在某種程度上很像Windows的天然代碼。而其他的語言只是提供一種能自動而且更容易的訪問API的方法。當你點擊窗體上的一個按鈕時，Windows會發送一個消息給窗體，VB獲取這個調用並經過分析後生成一個特定事件。

　　更易理解來說：Windows系統除了協調應用程序的執行、內存的分配、系統資源的管理外，同時他也是一個很大的服務中心。調用這個服務中心的各種服務(每一種服務就是一個函數)可以幫助應用程序達到開啟視窗、描繪圖形和使用周邊設備等目的，由於這些函數服務的對象是應用程序，所以稱之為Application Programming Interface，簡稱API 函數。WIN32 API也就是MicrosoftWindows 32位平台的應用程序編程介面。

　　凡是在 Windows工作環境底下執行的應用程序，都可以調用Windows API。

　　linux API：

　　在linux中，用戶編程介面API遵循了UNIX中最流行的應用編程界面標準---POSIX標準。POSIX標準是由IEEE和ISO/IEC共同開發的標準系統。該標準基於當時現有的UNIX實踐和經驗，描述了操作系統的系統調用編程介面API，用於保證應用程序可以在源程序一級上在多種操作系統上移植運行。這些系統調用編程介面主要是通過C庫（LIBC）來實現的。

Linux的API縮寫是歷史遺留問題造成的，因為Linux開發的目的是為了取代Unix，所以在API上基本要和Unix保持兼容一致。

忘了哪看到的

當時的鏈接器只支持6個字元，還不區分大小寫。

人家unix之父都說後悔當時用了那麼多縮寫了。

不過說是當時打字很麻煩，成本比較高

程序的可讀性，隨著時代的不同它的形式也不同。

古代:

顯示器25行80列，超過列寬是不顯示的，所以為了避免超過列寬

1 斷行，一個語句寫在多行

2 較短變數名，犧牲部分可讀性，但可以盡量避免超過80列的情況發生，使得一個語句較短從這個方面又可以部分提高可讀性。

現代：

顯示器至少30行200列可以做到，不存在列寬限制的問題那麼較長的命名本身就是文檔了。

unix與linux的命名規則局限於時代，windows, macos得益於時代進步。

縮寫打的快，效率高；

縮寫還能用的紙袋少，省錢（這是最重要的吧）。

歷史原因造成的，上面的大神已經說了，早起的C編譯器支持的函數名字最長8個字元。如果一個函數的名字太長，是不是考慮需要拆分它？是否需要使用其他類比的方式命名？

竟然在 Cocoa 面前討論函數名長短的問題，太 naive 了：

跑題了，UNIX 有歷史原因把函數名起得那麼短，看上去很酷，但實際並不好，Windows 算上 kernel 和 user 的 API，函數超級多，6 個字元根本組合不來。

win32有vs，名再長也無所謂～

我也被vs帶壞了已經，名經常一句話

寬屏顯示器普及度

函數名太長影響運行時的性能