天天财汇 购物 网址 万年历 小说 | 三峰软件 小游戏 视频
TxT小说阅读器
↓小说语音阅读,小说下载↓ 		一键清除系统垃圾
↓轻轻一点,清除系统垃圾↓ 		图片批量下载器
↓批量下载图片,美女图库↓ 		图片自动播放器
↓图片自动播放,产品展示↓
首页 淘股吧 股票涨跌实时统计 涨停板选股 股票入门 股票书籍 股票问答 分时图选股 跌停板选股 K线图选股 成交量选股 [平安银行]
股市论谈 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事
商业财经 科技知识 汽车百科 工程技术 自然科学 家居生活 设计艺术 财经视频 游戏--
  天天财汇 -> 科技知识 -> 为什么 C/C++ 的库很喜欢缩写？ -> 正文阅读

[科技知识]为什么 C/C++ 的库很喜欢缩写？

[收藏本文] 【下载本文】
为什么 C/C++ 的库很喜欢缩写？
关注问题?写回答
[img_log]
C++
C / C++
为什么 C/C++ 的库很喜欢缩写？
因为古代的 C 标准规定链接器至少支持 6 个有效字符即可。什么意思呢？假设你把malloc和memcpy写成memory_allocate和memory_copy，由于这两个标识符前六个字符相同，于是在链接器看来，这两个标识符相同，就无法区分这二者了。
喜欢全称给我去写Java
把scanf_s改成
threadUnsafeUnbufferedSystemEncodedStreamBoundedFormatedScanner
就老实了
老派的 C/C++ 程序员是非常相信人脑的记忆力的。
思想不坚定的已经被其它编程语言和平演变了。
以上是吐槽在新时代新项目还大量创造缩写的情况。
至于以前 IDE 自动补全还没普及的年代，反复手打长名称是受不了。
历史遗留问题。
当年电脑屏幕一行都放不下多少字符，也没有现在这么智能的IDE。于是有各种奇奇怪怪的缩写，还有奇奇怪怪的冗余比如匈牙利命名法，一个类型typedef出一堆类型等等，在现在看来毫无必要的编程技巧。
1988年制订的ANSI C标准（也就是C89国际标准）才第一次规定外部标识符长度上限不能少于31个字符。在那之前，不同的系统上，外部标识符的长度上限是由操作系统提供的连接器限制的，而连接器基本上是为FORTRAN等老式语言服务的，外部标识符长度上限被定为6个字符或者8个字符都是司空见惯。所以从C语言诞生到ANSI C推广普及之前，这差不多二十年里大家写的C函数的名字都非常克制。很多标准库函数的名字都是那个时代确定下来的，所以基本上不超过6个字符。
补充一点冷知识：
在ANSI C还没普及的过渡时代，C语言编译器厂家还不能强迫操作系统提供识别31个字符长度的外部符号的连接器，那时候C编译器厂家的对策是：一、暂时不遵守标准，还是只认操作系统保障的前6个或者8个字符；二、C编译器厂家自己提供连接器，不管是连接单独用C语言写的程序，还是C语言模块跟其他语言模块混编，都要用C编译器厂家的连接器；三、利用操作系统连接器的特性（漏洞），以某种算法把最多31个字符的英文字母、数字和下划线组成的外部符号名映射成由全部ASCII字符集组成的外部符号名，这样就大大缩短了外部符号长度，这样做的前提条件是连接器承认这些诡异的符号。
会，烦死。
当年开始写库的时候，显示器分辨率可能才640×480，尺寸也只有14寸，程序字母写多了是真看不完。
而且当时的编辑器功能也很弱，没有自动提示补全功能，当年的代码每一个字母都是纯手工敲入的。
不用缩写，真的能烦死。
送礼物
还没有人送礼物，鼓励一下作者吧
一、正如很多回答已经提到的，早期的有效标识符长度有限制，所以缩写用得比较多。也主要是在 C 里（Unix 的传统）。C++ 里的标识符用缩写的不多。如 C++98（毕竟比 C89 晚了 9 年么）里我们就已经有了很多挺长的名字，如 count_if、stable_sort 和 next_permutation。
二、不管你屏幕有多宽，编译器支持多长的标识符，很多地方对代码的宽度仍然是有限制的（否则就需要滚屏）。极客时间在手机上看的话代码宽度不到 40 字符，知乎在电脑上看也不到 80。印刷书籍一般只能 60 出头。而很多显示器要上竖直并排比较代码的话，代码宽度最多只能 100 出头一点点。因此，我自己写代码时，仍然是坚持以 80 列为限。——所以我看到 C++ 标准里规定的长标识符（如 propagate_on_container_move_assignment）时经常还是会觉得有点牙痒痒的（但鉴于这个名字用到的地方不多，长一点也许还是比较好）。
三、你真的确定你喜欢用 input_file_stream 而不是 ifstream？短的名字对读和写都有帮助，关键是在上下文里是不是足够清晰没有歧义。可以争辩，C 的那些短名字还是足够清晰的。日常生活里，不管是中文还是英文，我们都在使用大量的缩写。
每行不超过80字符的时代，也没过去几年吧？
另外，像dup难道不比duplicate好用吗？还有std和standard，lang和language
因为你用这两门语言越久，越能体会到缩写的好处。
来试试你的眼力(最好用电脑，手机看不出区别)：

current_message.as_quote_message.tick_quote_position = global_tick_quote_buffer.tail_postion;
current_message.as_quote_message.daily_quote_position = global_daily_quote_buffer.append( ctp_tick_quote_record );
current_message.as_quote_message.source_name = new_tick_quote_record.quote_source_name;
for( auto& current_receiver : all_receivers ) {
    current_message.as_quote_message.target_buffer = current_receiver.customized_pointer;
    SendToChildProcess( current_receiver.receiver_message_queue, current_message );
}

很容易看懂吗？那再看看这个：

_m.as_qmsg.tq_pos = _tq_buf._tail;
_m.as_qmsg.dq_pos = _dq_buf.append( ctp_ );
_m.as_qmsg.source = new_tq.src_name;
for( auto& r : _recvs ) {
    _m.as_qmsg.tgt_buf = r.cust_ptr;
    Send2Child( r.recv_mq, _m );
}

请问哪个让你可以更快更轻松理解它的大致逻辑(而不是迅速陷入某个字段名称含义的细节)？其实它俩完成同样的事儿。
我想表达的意思是：
可读性意味着能尽可能让代码读者保持“总览感”，而不会过快地陷入细节。
上述代码片段，我更希望读者看第一遍的时候，觉得：“哦，这段代码就是利用新数据构造了一条消息，然后发给子进程/子线程了。”
至于到底需要用什么数据来构造一条消息，以及消息内部每个字段的具体含义，暂时不重要。
而且到底是发给子进程还是子线程，暂时也不重要，因为读第一遍只是了解故事梗概。
真到需要细化了解的时候，到对应的头文件一看便知。
过长的字段名、子字段名、函数名，容易让读者很快就只顾着理解单词含义去了，结果“感觉每句话都看得懂，但到底做了什么还是似是而非”。阅读代码的目的首先是要了解业务主线，而非针头线脑的细节！！！阅读代码的目的首先是要了解业务主线，而非针头线脑的细节！！！阅读代码的目的首先是要了解业务主线，而非针头线脑的细节！！！
那些来杠“长标识名可读性强”的同学，请问你们做代数题设未知数时，是设成“x”还是“the_difference_between_the_long_side_and_the_short_side”？
程序代码本质上是另一种数学语言，标志名称本质上是“符号”！“符号”！“符号”！
这是 CTP 官方接口节选：

///资金账户口令更新请求响应
virtual void OnRspTradingAccountPasswordUpdate( CThostFtdcTradingAccountPasswordUpdateField* pTradingAccountPasswordUpdate, CThostFtdcRspInfoField* pRspInfo, int nRequestID, bool bIsLast ) {};
///投资者结算结果确认响应
virtual void OnRspSettlementInfoConfirm( CThostFtdcSettlementInfoConfirmField* pSettlementInfoConfirm, CThostFtdcRspInfoField* pRspInfo, int nRequestID, bool bIsLast ) {};
///删除预埋撤单响应
virtual void OnRspRemoveParkedOrderAction( CThostFtdcRemoveParkedOrderActionField* pRemoveParkedOrderAction, CThostFtdcRspInfoField* pRspInfo, int nRequestID, bool bIsLast ) {};

设计这接口的人绝对是个文学家！
送礼物
还没有人送礼物，鼓励一下作者吧
C库使用缩写是历史的选择，是人民的选择。
并不完全是历史原因，而是不恰当的长名字很恶心。
初看还行，但是如果形成编码规范，满篇都是长名字，看起来密密麻麻的，在混进一大堆大写，容易犯密集恐惧症，进而头晕恶心之类的。
多写两个字母，会不会死不知道，但会很烦；
聪明的懒人才写库，所以尽量少打几个字母；
聪明不懒的人不写库，手撸一切；
不聪明也不懒的人，多打少打几个字母无所谓；
不聪明的懒人，自己不想写，调库又嫌麻烦，多打几个字母都要死要活的；
补充一点具体的吧：
i18n初一看确实有点懵，但天天打 Internationalization ，确实会烦死；
std::string，都有点麻烦，std::str 不就好了！
其实很多事情都是路径依赖，铁轨这么宽是因为以前的马车这么宽。
c/cpp 出现的年代太早了，在那个时候，屏幕普遍比较小，还没什么智能的 ide，你可以理解为在记事本里写代码，这种情况下，名字短可以少打几个字，在小屏幕上能看到更多内容，开发上优势是非常大的，更早的编译器甚至只支持几个字符的变量，所以习惯上库、函数都会用缩写，尽量写短一点。
至于现在，虽然屏幕大了，ide智能了，很多年纪比较大的程序员还是会习惯性的使用缩写风格。
而且如果是维护或者调用一些年代久远的库，不缩写的代码和老的缩写代码混一起风格也怪怪的，不好看。
当然了，这些其实也都是细枝末节，C/C++里驼峰下划线都没统一呢，代码风格本来就乱，习惯就好。
送礼物
还没有人送礼物，鼓励一下作者吧
纯粹是偏好风格。
在我看来，这些无论长短都是token，你再怎么长也不可能做到看名字就不需要查手册直接知道怎么用——哪怕是到了objc这种极度啰嗦的地步自然做不到。
所以，尤其对非英语母语的人来说，短一点反而在记忆和交流上更轻松点。
对了，突然想到：i18n/k8s之类的词，应该也不是c/c++圈子里流传开来的吧？
因为你的母语不是英语，对英语母语的人来说，这些缩写并不难理解，也不会造成混淆。
如果有什么需要特殊说明下的东西，会加注释的，而不是拿变量名当注释用。
另外，总体上看，能长期使用C语言进行日常工作的开发者，素质更高一些，可能这也是原因之一。
送礼物
还没有人送礼物，鼓励一下作者吧
也就是java时代才讲究全拼
内存都使者劲儿浪费，多敲二十个字母不是更显得工作量爆满吗
缩写 猖狂的 是类unix相关的库。
微软的函数名都很长。
除了函数， 微软的power shell 也有长命名 命令。
而类unix 用户 貌似还因此瞧不起微软。
unix shell， glibc， socket库， vim， 五笔输入法，风格是一致的， 对于不愿意学习他们那些 缩写命令的人来说，就是悲剧。
对于要不停敲键盘 输入命令的 操作系统， cp， ls， 确实 比copy， list 要少敲几个字母，敲的多了，确实更累。
c/c++的最强项可能就是效率，除了汇编，无人能敌。双向选择之下，c程序员对效率也会有比较高的追求，多打两个字母会影响效率，对于效率比较低的人来说无所谓，对效率已经很高要追求极致效率的人来说就很重要了。
标识符短主要问题在于重名，尤其是不同的库，谁有资格用短名？当然是用的比较多的用短名称细弱合适。c程序员往往有莫名的自信，自信自己的库比别人的更强，有资格占据短名称。当年git刚出来的时候，git实际上是另外一个软件，git要输入一个比较长的名字，现在用的人多了，nb了，今天提到git我们知道的只是这个版本控制了。多写两个字母会死么？这个问题也可以去问下鸠占鹊巢的git。
c/c++，都多倾向缩写，尤其是函数内部变量，这样可以精简代码块，让人眼更注重逻辑，这很关键，因为底层代码更重要的是符号，比如& * [] -> + >> 等，这些符号在c/c++很常见，甚至比命名更重要 。
c# java就是反例，一坨一坨的长命名，没有太多逻辑计算符号，全是函数调用。带来的效果是，看起来代码很多，但实际上逻辑信息密度非常低。
何止古代IDE简陋，VSCode和VS项目一大，搜函数名好几秒甚至搜不到才是常态。
你想要多打几个字吗


C/C++程序员大部分还是在用vim编码，名称都是要手敲的，所以有缩写的动力。一般只会缩写一些约定俗称的名称linux、freebsd 内核中的缩写会传播给其他程序员协议RFC中大量使用缩写，在实现这些RFC时，就使用了这些缩写并不会缩写一些不常见的名称
例如，在开源网络测试仪dperf项目中的缩写：
sk: socketfd: file descriptorsig: signalref: referencerst: resetack: acknowledgerto: retransmit timeout
dperf: 100Gbps开源压力测试工具
以前的显示器分辨率不高，一行能显示的字符数量有限制，所以可视空间有限，无论写代码还是读代码，用缩写可以提高效率，增加一眼看到的逻辑的数量。
其实有些缩写习惯一直流传至今，比如一说起 i 这个变量，大部分程序员第一反应就是循环变量，如果是两层循环，那么内层的循环变量，基本就是 j 了。
而且古老的c编译器标识符的确有6个字符的限制。大概原因是以前存储的容量小，成本贵，曾经拆过一台古早的ibm的笔记本，硬盘容量40m，这点容量，放现在连个小容量优盘都不如。
一开始如很多答案说的，是“物理限制”。
后面其实大家发现合适的缩写比大小写混杂加下划线的破明明好太多。代码补全再厉害也比不上你有五个二三十个字母长度的函数但其中只有三五个字母不同带给你的眼晕。
这一点在python里尤为明显。
我猜是因为早期IDE都比较简陋(写IDE的语言正在开发中...)
每次都完整打全DeserializeObjectFromXmlString可太酸爽了,那会显示器换行也不方便,甚至流行80字符宽度限制,都不够写几个标识符的.
最早的C语言采用穿孔纸打印时，行长一般只有80字符。如果是使用9针的点阵打印机有的行宽更小。所以，如果变量太长，每行都会换行。
这与后来者，比如套用3层的命名空间的现代语言完全不同。我觉得对于一种特性并不丰富却非常灵活的中级语言（必要时还能嵌入汇编），C语言之所以经久不衰，是因为它的代码可以写的足够易读、直白。虽然基于它的灵活性，也可以写出天书一样的混淆代码，但大部分开源项目的C代码都非常简单易读。C++语言虽然变得非常复杂，但你依旧可以用C语言的风格去编程，用using后，也可以解决命名空间太长太深的问题。C/C++足够灵活，满足了不同人的审美需求。
一些常见的偏好包括：
喜欢函数式风格，不断迭代返回值来做事情，比如 A.a().b().c(d.e())云云，把用面向过程几十行的代码变成一行。喜欢迭代器风格，使用一串向量整体回调操作，比如 D.mapop(E.range(), my_operator喜欢lambda风格，使用一大堆匿名函数在多个线程/协程里游走。
当然不是说这些不好，但最简单易读的还是死板、循规蹈矩的面向过程编程。因为线性的、直白的思维最节省脑力。
另外吐槽一下命名空间嵌套，如果设计的不好，会让人半天找不到在哪个命名空间里引用符号，反而没有头文件直接。
std::this_thread::sleep_for(std::chrono::milliseconds(1000));
远不如一句
QThread::msleep(1000)
来的痛快。
你就当以前都是写字板编程，没有好的ide，没有舒适的提示，没有好的屏幕，没有好的着色
野史不保真：C早期多写两个字母不会死，但手指可能会断，后面就是习惯了。
缩写表达遵循一种规范，大家都方便。
见名知意不带歧义才是最重要的，好的命名自带注释。
如果某些代码不需要别人维护或查看，你随便怎么写都可以。
C++和C语言库喜欢使用缩写的原因有很多，主要包括以下几个方面：
历史原因:
C语言诞生于1972年，当时计算机内存资源非常有限，为了节省空间，C语言的设计者使用了大量的缩写。C++作为C语言的扩展，继承了C语言的许多语法和风格，包括对缩写的使用。
提高代码简洁性:
缩写可以使代码更加简洁易读，尤其是在函数名和变量名较长的情况下。例如，printf()比print_formatted()更简洁易读。
兼容性:
许多C语言库函数都使用了缩写，为了保持兼容性，C++也需要使用缩写。
习惯和约定:
经过多年的发展，C++和C语言社区已经形成了使用缩写的习惯和约定。
并非所有库都喜欢缩写:
并非所有C++和C语言库都喜欢使用缩写，例如STL库就很少使用缩写。一些现代C++库也开始使用更具描述性的命名方式，例如std::filesystem。
是否会死:
使用缩写不会导致程序崩溃或运行错误，但可能会降低代码的可读性和可维护性。在某些情况下，过度使用缩写可能会使代码难以理解，甚至可能导致错误。
建议:
建议根据具体情况选择是否使用缩写。在使用缩写时，应确保其含义清晰易懂。对于重要的函数和变量，建议使用更具描述性的命名方式。
以下是一些建议:
对于常用的函数和变量，可以使用缩写来提高代码简洁性。对于不常用的函数和变量，建议使用更具描述性的命名方式，以提高代码的可读性和可维护性。在团队开发中，应统一命名风格，避免混淆。
总结:
C++和C语言库喜欢使用缩写的原因有很多，包括历史原因、提高代码简洁性、兼容性、习惯和约定等。使用缩写不会导致程序崩溃或运行错误，但可能会降低代码的可读性和可维护性。建议根据具体情况选择是否使用缩写，并在使用缩写时确保其含义清晰易懂。
送礼物
还没有人送礼物，鼓励一下作者吧
[收藏本文] 【下载本文】
   科技知识 最新文章
百度为什么越来越垃圾了?
百度为什么越来越垃圾了?
为什么程序员总是发现不了自己的Bug?
出现在抖音评论区里边的算命真不真？
你认为 C++ 最不应该存在的特性是什么？
为什么 Windows 的兼容性这么强大，到底用了
如何看待Nvidia禁止使用翻译工具将cuda运行
为何苹果搞了十年的汽车还是难产，小米很快
该不该和AI说谢谢?
为什么突破性的技术总是最先发生在西方？
上一篇文章      下一篇文章      查看所有文章
加:2025-05-14 13:27:12  更:2025-05-14 13:55:10 
 
 
股票涨跌实时统计 涨停板选股 分时图选股 跌停板选股 K线图选股 成交量选股 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事
网站联系: qq:121756557 email:121756557@qq.com  天天财汇