前言

这里指的 "命名法", 实际上是一种 "规范", 属于未成强制约束性的规则, 在程序设计中尤为常见, 但是实际上 CX 并不是为了编程才去了解这些命名法的😂.

在最开始的时候, CX 在一些不支持富文本格式化的地方写稍微长一点的文本的时候, 比如 QQ 群公告 / README.txt / 一些不支持富文本的文章编辑器(比如某安的动态及图文编辑器等等), 萌生出了 "如何使用纯文本做好排版" 这种疑问, 在搜索引擎和网络朋友的帮助下认识到了一些中文排版规范, 解答了很多之前一直困惑的问题.

在此的基础上深入, 我就开始认识到了 "命名法" 这个东西(这里专指程序设计中的), 它实际上和纯文本排版有异曲同工之妙, 即为: 增强人类对内容的可读性的一种非强制性约定. 而这些规范出现的原因和百家争鸣的程序语言以及字符编码其实最根本都是一个: 现代计算机只认 0 和 1, 但是人类极其难以读懂 0 和 1.

计算机可不会管你写成什么样, 只要能被正确转换成 0 和 1, 那么这就是没问题的, 但是问题在于输入给计算机系统的源代码是需要人来写和维护的, 如果没有这些命名法 / 排版规范 / 代码风格以及注释的加持下, 源代码可能从写出来就是一座 "屎山", 这里的源代码不只是指程序语言中的源代码, 所有写进计算机系统需要被计算机理解并存储的字符都能算是源代码, 一个写满了中文的 TXT 照样能算是源代码, 只是为了针对性, 对于这种弱编程的形式的输入的字符不归于源代码的范畴罢了.

是人类太弱了, 还是计算机太傻了?😤

认识命名法

命名规则 (程序设计) - 维基百科

只要在网上冲浪, 就或多或少接触到与计算机系统相关的东西, 比如用过微软家的 Windows 都可能会知道 aka.ms 这个微软御用的短链接域名, 而这个短链接的命名法也是基本有规律可循的,

首先排除短链 SEO 的因素, 因为短链接从来都没有考虑过这种 URL 能对 SEO 友好.

比如我打开 Windows 10 上的 PowerShell 客户端能看到欢迎语写着:

1
2
3
4
5
6
Windows PowerShell
版权所有 (C) Microsoft Corporation。保留所有权利。

尝试新的跨平台 PowerShell https://aka.ms/pscore6

PS C:\Users\CXPLAY>

里面的 aka.ms/pscore6pscore6 就表示 PowerShell Core 6 的意思, 这里用的缩写和全小写的做法硬要算也能算是自由命名法😂, 在一些更为明显的 aka.ms 的链接上, 比如:

首先 CX 已经排除掉这种写法对 SEO 的影响, 只剩下这种用法是为了便于人类书写和阅读而形成一种规范, 在使用过一些可以自定义短链后缀的链接缩短服务的时候, 如果要让你选择一个便于你书写和阅读的后缀快速访问到本博客, 你会选择记住随机生成的后缀还是写一个更加利于记忆的后缀呢?

比如:

  1. LjdP1
  2. cxplayblog
  3. cxplay_blog
  4. cxplay-blog
  5. CxplayBlog
  6. cxplayBlog
  7. goCxplay
  8. CXPLAYBlog
  9. Cxplay_Blog

如果叫我来选, 我会选 cxplay, 为什么和上面的不一样没有 Blog? 因为我不需要, 只要输我的 ID 就能直接访问岂不美哉? 这里凸显出了命名法的规范特性, 即在此没有强制, 不同的程序语言对此一般都会有专门的规范.

将上面的例子转化成导图即为:

 常见命名法(程序设计)

查看原图表

LjdP1 不属于任何一种, 因为它并没有按照命名法的初衷来书写(毕竟自动生成的就是这个样子).


很显然, 命名法都是为了提高代码的可阅读性而做出的, 在数量繁杂的源代码中, 如果函数和变量的名称变得阅读十分困难, 那么可能相对于程序员来说, 就和没有注释的代码片段一样, 不仅难以阅读, 甚至到最后只有最初编写者才能看懂这些奇怪的变量名.

这让我想起一张看过的梗图, 讲的是上位代码维护的人离职后, 第二个接手的人来继续维护代码, 结果发现里面的变量名全都是上位的程序员用自己老家那边的方言拼音写的...😂

使用命名法

以上举例的命名法都是现在较为常见的几种命名法, 还有很多命名法经过以上几种命名法融合变化出更多兼具优势的命名法比如 帕斯卡蛇形命名法 就是使用了帕斯卡命名法再使用 _ 来替代空格的命名法; 不止于此, 还有很多命名法甚至没有稍微正式一点的称谓, 比如所谓的 "蛇形命名法" 实际上最开始是在 2004 年首次出现于 Ruby 语言社群中, 最后渐渐就成为了这种命名法的习惯性称谓, 再成为了正式的叫法.

不同的命名法之间各有优势与缺陷, 要选择自己适合的那自然是最好的, 当然最好还是建议考虑遵循一下当前程序语言中建议的方法, 对于最后的那种 "自由命名法" 来说应该算是毫无章法的分类, 可以说是十分有个性但是并不友好.


对于 CX 自己来说, 目前使用命名法最多的地方还是在短链的后缀命名上, 比如现在已有的几个短链:

  1. cx.ms/MS365Note

    MS365Note 即表示: Microsoft 365 note.

  2. cx.ms/PixivFe2022GP

    PixivFe2022GP 即表示: Pixiv Featured 2022 Google Photo.

由于这几个短链只是为了方便我自己手打 URL, 所以我都只是按照自己的习惯和便于记忆的角度出发去写了它们的别名, 要说这到底算哪种命名法, 实际上我都不知道, 但我还是是比较钟爱 帕斯卡命名法(大驼峰命名法) 的.

结语

但尽管如此, 还是有一些疑问存在, 比如对于已经规范化的代号, 如 HTTPLaTeX这样的名称, 以及一些常用的简称, 比如 TOSMS365等; 到底是继续遵守命名法的规范还是按照正确的称号去写呢? 这时候可能使用蛇形命名法或者脊柱命名法或许更加合适.

而对于一些规范的命名可能在不同的环境中适用情况完全不同, 比如蛇形命名法在 SEO 中优化建议中, Google 对于使用 - 这样下划线分割 URL 的做法并不是特别推崇:

建议您在网址中使用连字符 -,而不要使用下划线 _。

建议 - 使用连字符 (-):
http://www.example.com/summer-clothing/filter?color-profile=dark-grey

不建议 - 使用下划线 (_):
http://www.example.com/summer_clothing/filter?color_profile=dark_grey

保持简单的网址结构  |  搜索中心  |  Google Developers

Google 对于 SEO 的建议中, 不推荐使用 _, CX 也没有搞清楚是为什么, Google 也没有关于此 URL 间隔使用区别的详细信息. 对于 SEO 而言, 这方面的区别推测极有可能就是与命名法有关, 因为驱动 SEO 进行也是搜索引擎的计算机程序, 对于 URL 这种最为基础的信息, 便于 SEO 识别后以 人类便于检索 的角度出发进行索引, 很难相信它于此没有什么关联.