C語言C11為什麼選擇`thrd_create`這麼奇怪的命名？

01-13

thread 縮寫為 thrd 是什麼鬼？
thrd_create - cppreference.com

標準庫里的strcmp, strdup, strcat, strcpy, ..., malloc, calloc, alloca, ..., fprintf, asprintf, ...發來賀電……

unix的creat, sbrk, epoll, ...發來賀電……

thread縮寫為thrd是一個非常常見，非常正常，並且歷史悠久的縮寫規則。

舉些例子，最古老的聖經抄本，希伯來語的，是沒有母音字母只有輔音的。而阿拉伯語字母28個，全部為輔音字母。母音通過由加在字母上方或下方的標音符號來表示，但這些符號通常是省略的，所以也沒有母音字母。主要是閃族語系以輔音和長母音來區分詞義。（有沒有更古老的節點我就不知道了）

至於英文，這個現象也很常見。Extensible Markup Language，縮寫為XML，沒母音。（順便說一下，Ex打頭的單詞，縮寫的話用的是X，而不是E。不要像很多國內的無知企業一樣，User Experience縮寫成UE。UE是Unreal Engine，UX才是User Experience！！！！）

另一個英文的例子是Blt。全稱是Block Image Transfer，但作為API的時候，連i都省掉了，變成Blt。

正經來說thd_crt比較好

---修改---

thrd_crt更好

我感覺C語言從第一天起就在拼寫這個問題上放棄治療了。

確切地說是KR這兩個傢伙放棄治療了。

還不是怕名字衝突. 在C11之前, 已經有很多系統用了thread_create這種看上去很正常的名字了. 你升級到C11結果編譯不過去, 肯定不行, 這樣就不清真了

難道不是怕和以往的pthread_create之流衝突？

這，我還以為只有thread_create和thrd_creat，沒想到人民群眾的創造力如此豐富……

c語言關鍵字少，官方介面也少，就該用這種縮寫。

UNIX以及C社區遺留的歷史性惡習。早年硬體設備太垃圾，鍵盤敲不幾下就手疼，顯示器一共就能顯示80 * 25的字元，逼得大家都把單詞往死里縮寫，所以才會有ls這樣的命令和strcpy這樣的函數名。現在時代變了，硬體廠商變著花樣伺候用戶大爺，可老毛病卻改不了了。

以下摘自《UNIX痛恨者手冊》

含糊的命令名
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標準。

其實吧，這個本身並不是很奇怪。在英語或者其它拼音語言的世界中，忽略母音來略寫單詞是很常見的事情。不光是編程，在推特上就滿是這樣的縮寫。像下面這篇文章專門討論這個現象：

Some Srs Bsns: Are Words Without Vowels Rlly More Efficient?

僅僅是閱讀的話，問題還不是很大，但是如果投入到生產中的話，要記憶這種不規則的縮寫就有點過了。所以，最好是不要縮寫。

這樣很好啊，可以根據縮寫風格的不同輕鬆區別庫函數和用戶自己的函數

庫函數當然要酷酷的看不太懂才是王道，要我看這個還不夠短

通過這命名，我開始欣賞微軟win api簡單粗暴的CreateThread()了...

一看到這麼丑的就知道是庫函數了，多好

太長的名字敲著費勁, 讀著也費勁, 尤其是讀的時候, 浪費寶貴的大腦容量~ 語言都是傾向於簡單化的, 所以今天的網路用語有各種縮寫, 比如, "累覺不愛", "見得多了", +1s等等.

我個人其實是挺支持這種縮寫的，原因有兩點。

第一，變數名所展示的概念，在很多場景下是特殊的概念。這些概念是程序上下文決定的。很多時候，讀程序的人理解了這些上下文，命名中的那些縮寫，不會構成閱讀障礙；如果沒有理解，希望給變數起個好名字就能讓讀程序的人將程序讀懂，未免也過於樂觀。命名體現的是概念，相對於起個好名字，我倒是覺得程序員在寫完程序後應該將程序中用到的概念做一個梳理，然後用注釋的方式記錄下來。

第二，單詞縮寫體現個人風格和個性化理解，應該鼓勵。當程序員在寫程序時創造新概念的時候，用近義詞、縮寫這些手段來表達特殊涵義，應該屬於常規做法。英文中專有名詞的首字母縮寫也是類似的做法。

我個一些個人體會，讀程序最重要的是讀邏輯。最好不要先入為主的將一些概念代入程序閱讀，除非確定這些先入為主的理解和程序作者的理解一致。

creat不加e，這貨要加e。我要報警了

所以我司死也不肯從C90和C++98往上遷徙。我個人也是十分反感這類折衷的新特性，有跟沒有根本不影響使用。

還不如給我來個完全不兼容的系統級新語言，比如rust什麼的

只保留輔音字母是一種很常見的縮寫吧。

----update

不然std為啥代表standard。

這種東西用起來容易出問題，把一部分強迫症噁心跑讓你用系統API，避免被噴。