V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
dswyzx
V2EX  ›  程序员

关于 dotnet 语言属性首字母大写 Pascal 的探讨,以及不同语言的区别

  •  
  •   dswyzx · 2020-09-04 22:42:50 +08:00 via iPhone · 1958 次点击
    这是一个创建于 1301 天前的主题,其中的信息可能已经有所发展或是发生改变。
    一开始学习是建议怎么样就怎么样,搬了几年砖之后放飞自我就喜欢将属性首字母小写处理 camel 。一方面是不用频繁切换大小写,一方面是有时候涉及 json 对象的属性就是 camel 风格。然后 vs 智能粘贴大法直接定义好类。
    当忽然被提出按照规范写的时候。我才开始思考为什么规范是这样的。而哪种方式才应该推广。
    后来查了一下 java python js 基本上是属性走 camel 。而数据库方面也是 Pascal camel 各有不同。
    究根结底,这些风格都是为什么要这样考虑,又都有什么说法呢?不要讲约定俗成,或者说规范就是规范。毕竟容易赚钱的方法都写在刑法里
    11 条回复    2020-09-06 00:27:19 +08:00
    ligiggy
        1
    ligiggy  
       2020-09-04 22:55:31 +08:00 via Android
    属性按照旧习惯写法是伴随着字段的,字段首字母小写,一起的属性首字母大写来区分。
    raysonx
        2
    raysonx  
       2020-09-04 23:00:06 +08:00 via iPhone
    python 的习惯是类名 Pascal,其他名 snake_case 。
    winnerczwx
        3
    winnerczwx  
       2020-09-05 00:32:38 +08:00 via iPhone
    我用 c#,ide 提示我要首字母大写,不然有黄色标记。所以慢慢就习惯了。

    如果你要排除掉约定或者规范,可能不见得就有其他解释了。比如接口用大写 i 开头,为了一眼就能知道这是个接口。但你不加 i 也照样正常使用。

    可能还有一部分原因是因为语言的标准库。
    jiangzm
        4
    jiangzm  
       2020-09-05 01:48:28 +08:00
    你说的应该是编程语言 C#吧,dotnet 是编程框架 /平台。C#诞生之处肯定是继承了 Delphi 的一些设计了,毕竟这两个语言有同一个爸爸( Anders Hejlsberg ), 而 Delphi 就是 Pascal 风格。

    还有后起之秀 Go 也是 Pascal, 所以 Pascal 只是一种选择, 并不是你认为的”另类“
    jjx
        5
    jjx  
       2020-09-05 06:09:19 +08:00
    可以了解一下 nim 的骚操作
    skinny
        6
    skinny  
       2020-09-05 07:59:23 +08:00
    .Net 的 API 命名挺统一规范好看的,至于说频繁需要切换大小写,我是没发现,IDE 自动补全很好用,写自己的代码时也并没有需要频繁切换大小写。倒是 Python 的 API 命名一言难尽,要是统一小写、单词用下划线分割也好,可偏偏不是,乱七八糟的,什么都有,PEP8 也没几个严格遵守。
    jin7
        7
    jin7  
       2020-09-05 09:08:49 +08:00
    python 确实乱 下划线 驼峰都有
    vone
        8
    vone  
       2020-09-05 12:40:03 +08:00
    sql 写多了之后就是全大写了。
    namelosw
        9
    namelosw  
       2020-09-05 21:10:58 +08:00
    虽然我也 follow 规则大写,不过感觉还是挺尴尬的。

    一方面 url 最好小写,所以 controller 啥的还得专门写注解才能改成小写,json 得有层处理(虽然大部分时候框架帮你做了)。

    感觉用 kebab-case 的语言都比较自然。退一步 snake_case 也可以接受,就是打起来麻烦点。camelCase 和 PascalCase 都很尴尬,有时候做传输处理的时候变小写之后就变不回来了。

    另外变量和函数能加问号的语言也比较好,这样就不用纠结有很多 boolean 风格要以 is 开头比如 isEmpty,结果后来发现 hasErrors, canSubmit 之类的比较通顺但是破坏阵型。类似的还有 side effect 加叹号。
    namelosw
        10
    namelosw  
       2020-09-05 21:16:05 +08:00
    然后还有一点是很多语言是大小写有硬性区别的,比如大写是类型,或者大写会被 export,也比较尴尬。

    因为 很多语言没有大小写。
    secondwtq
        11
    secondwtq  
       2020-09-06 00:27:19 +08:00   ❤️ 3
    C# 的 camel case 偏好应该确实跟 Anders Hejlsberg 有关系。Anders Hejlsberg 应该也参与了 .NET 平台的设计,.NET 的目标之一是统一不同编程语言,不同语言会用同一套 API,所以说 .NET 用 camel case,C# 用 camel case,VB.NET 用 camel case,以及 F# 用 camel case 其实都是一样的。

    具体到命名习惯本身,snake_case 的好处是 _ 充当了空格的作用,这样读起来和普通现代拉丁文字的句子是差不多的,但是 _ 会占额外的屏幕水平空间,现在很多项目编码规范还限制一行最多 80 字符,就算扩展到 120 之类的,配合上 InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState 之类的符号还是显得比较搞笑。所以很多 enterprisy 的语言,比如 Java 和 .NET 平台好像都很喜欢用 camel case,可能跟这个有关系。
    camel case 省空间,但是从 typography 角度来看,一般现代拉丁文字的句子都是只有特定位置才会大写,大多数单词都是小写,如果给你一篇英文文章,每个单词首字母都是大写的,看起来会很不舒服。因为这样句子轮廓会有一个波动,不符合大多数人阅读习惯的”flow“(如果你去看公元初的拉丁文,所有字母全是大写,没有空格和标点更不舒服)。camel case 就相当于把这个所有单词首字母大写的体例搬到了程序里面。snake_case 的支持者一般认为这样做是不利于阅读的。
    从打字上来讲两者遇到空格时都需要按一下 Shift,感觉上是差不多的(键盘上有 _ 键的除外 ...)

    (以上 camel case 同时指 lowerCamelCase 和 UpperCamelCase 两者)

    命名规范是有继承关系的。比如 JavaScript 本身是个玩具,但是因为要扯 Java 的虎皮做大旗,所以也继承了 Java 的命名规范。Apple 喜欢用 camel case,所以你看 Objective-C 和 Swift 都是 camel case ( OC 早期历史不明,因此部分存疑)。Julia 怕是也受了 MATLAB 的影响。
    现在大多数 snake_case 应该要追溯到 C 和 UNIX (这俩和 C# 和 .NET 一样是共生关系,所以得一起提)。我认为 C 是 UNIX 平台上的第一语言,写 UNIX 软件最好用 C,而 UNIX 的一大创新在 Shell 上,因此 Shell 是 UNIX 的第二语言,写 UNIX 脚本最好用 Shell,而 C++、Python 、Perl 、Lua 等语言都是 C 和 Shell 的不同程度的混合以及向不同方向的发展。你会发现我们现在常用的很多经典编程语言都起源于八九十年代的 UNIX 机器上(并非所有,比如 Python 最开始不是给 UNIX 写的,但是 Python 那平台命名上和 UNIX 好像蛮相似的),那么受 UNIX 影响也是非常正常的事情。而和 UNIX 没啥直接关系的语言很多也和 UNIX 命名习惯没啥关系,比如 Smalltalk 和 Pascal 等。

    虽然大多数语言有自己的命名规范,但是实际用什么一般还是用户的自由。这里也遵循一些一般规律比如 UNIX 系统上的 C 项目很有可能主要用 snake_case,但是如果是 Windows 项目那你可以欣赏下匈牙利命名法。虽然如此,命名规范的选择也需要考虑一些实际的设计和限制问题。比如 LLVM 项目里面基本全都是 UpperCamelCase,造成一个问题是作为一个 C++ 项目,值和类型是共享命名空间的,那么我上下文里面有一个 MachineRegisterInfo 的值,放 Java 里面就叫 machineRegisterInfo 了,但是因为 UpperCamelCase 的限制,我不能叫 machineRegisterInfo,也不能叫 MachineRegisterInfo,我只能写一个 MRI 上去,这一下就 degenerate 到了比 snake_case 中大量的缩写还要差的程度,不知道的人还以为是医学软件。

    LISP 比较奇葩,因为 S-expr 中,除了空格和圆括号之外基本都是可用的字符,标识符命名规则很自由。但是比较多见的是卡拉季奇 case,啊说反了是 kebab-case 。这个类似 snake_case,但是不用敲 Shift 。大多数编程语言中不能用 kebab-case 是因为这些编程语言给 hyphen 和 minus sign 使用了同样的编码 0x2D,同时又区分了 operator 和 identifier,这样出现 0x2D 就默认是 minus operator 。但是 Shell 中算术操作并不是特别核心的东西,所以有的 shell 是允许函数名用 kebab-case 的,不过变量就不能带 hyphen 了。
    很多语言虽然喜欢用 camel case,但是包名还是喜欢用 kebab-case 或者 snake_case,部分可能是因为包名经常和文件名挂钩,而文件名的大小写在不同文件系统中表现是不一致的,保持全小写更安全。
    部分语言会给命名施加更强的限制。比如 Haskell 要求值标识符必须以小写字母开头,类型和 data constructor 必须以大写字母开头,而 type variable 必须以小写字母开头。OCaml 有类似的限制,但是 Standard ML 没有。这个 thread https://mail.haskell.org/pipermail/haskell-cafe/2006-August/017154.html 给出了一些这样做的理由。

    最后,就设计限制这点来说,很多的考虑根本在于主流编程语言的程序基本都是以 textual 的形式(即所谓”代码“),ASCII 编码表达的。图形编程语言,以及某些 esolang 一般不会直接暴露这种表示,因此命名相对自由,甚至根本没有命名的习惯。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5433 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 08:44 · PVG 16:44 · LAX 01:44 · JFK 04:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.