程序猿修养 给属性一个单位

[utterances-bot]

程序猿修养 给属性一个单位

程序猿修养 给属性一个单位

https://blog.lindexi.com/post/%E7%A8%8B%E5%BA%8F%E7%8C%BF%E4%BF%AE%E5%85%BB-%E7%BB%99%E5%B1%9E%E6%80%A7%E4%B8%80%E4%B8%AA%E5%8D%95%E4%BD%8D.html

[dashenxian]

我觉得微软很多API也是用的不带单位的主要是有几个前置：1.有丰富的文档，2.有完整的注释，3.作为官方权威有一定普适教育，比如你不知道Task.Delay(100)的单位通常你过不了面试或笔试，4.没单位比有单位在达成共识的情况更简单。更突显了秦始皇的眼界，统一度量衡真的很重要

[lindexi]

@dashenxian 有一些惯用法适合不带单位，但是有些是历史遗留问题，比如传入路径问题，难以表示是文件夹还是文件，是绝对路径还是相对路径，这些都是困扰新手的问题，很经常在各个群聊里面发现新手开发遇到这些问题

有时候注释里面也会带来一些坑，例如写习惯了使用毫秒作为单位的，如果遇到某个伙伴写了以下代码，请问以下代码实际执行效果会是什么

foo.Delay(100);

    class Foo
    {
        /// <summary>
        /// 延迟一段时间
        /// </summary>
        /// <param name="delayTime">延迟多少秒</param>
        public void Delay(int delayTime)
        {
            ...
        }
    }

当写习惯的时候，有时候注释也很难救的了

“没单位比有单位在达成共识的情况更简单”：业务情况一旦复杂起来，或者是稍微有点专业性的话，这个是不会成立的。比如说专业文档排版，像素、厘米、比例 有共性但是也有其不同，必然存在多个单位。单位不仅仅只是相同的客观情况的不同描述而已，有时候是对某个客观情况的多个不同的角度的描述

[dashenxian]

我对你这个说法不认可有时候注释里面也会带来一些坑，例如写习惯了使用毫秒作为单位的，如果遇到某个伙伴写了以下代码，请问以下代码实际执行效果会是什么，文中的单位也只是一种约定，并没有什么物理规律来限制，你给了单位比如1s，但是我就是在方法中把1s当做1ms来处理，你也没办法，类似于我们约定好了1代表1s，你偷偷改成1ms用，你给出单位只是另一种约定，对于不遵守约定的人毫无意义，甚至可以把单位混乱定义，s我可以说这是毫秒单位，ms是秒单位，直接加在注释上，你怎么用？所有我觉得这些都是按照普罗大众的通常认知来处理，而普罗大众的认知来自于一个统一的教育。
所以我觉得一些接口的注释的关键信息应该正确，达到和单位一样的效果，如果没有注释没有单位，应该按照语言的通用习惯，有些语言一般是ms，有些是s，如果一些人喜欢特化那他应该给出明确说明，否则这种人应该被教育。