有一件事情我一直耿耿于怀，是这个样子的，我在用TS写着React的class 组件，页面上有一个表格，它的id需要被同页面另一个类方法用，于是乎我就在类的上面
const tableId = "export-table-id"；
结果被强调要大些...，不要问，问就是代码规范。
我认为大写很不易读，还不好打，这里tableId准确的来讲是一个只读变量，做为只在当前文件中使用的值，大可不必用大写来起到强调的作用
为了避免不必要的争论，改一下只需要两三秒，讨论起来时间可就放大了，我想到一个中庸的解决方案，把tableId写成一个类属性
我单纯的认为只有字符串需要大写，我以前也是这么认为的，只不过是在值被多个文件依赖时会这么做。
然而过了一阵子，又被强调导出的普通对象也要大写，为了完成这个转换工作，我特意在开发者工具写了一个函数，用来把驼峰转换成大写加下划线....
这多多少少让我有些恍惚，仔细体会完个中滋味后，想起郑强老师的一段话
我就一直不明白在中国的民众当中，为什么要把空姐这个行当看成如此之神圣和不得了，我们这么多女大学生，为什么长的这么漂亮外语这么好，毕业了要选择这个专业我一直不解，我就真不明白同志们，我不明白，在天上推着车、倒点水，和地上推着车，倒点水 ，为什么在天上倒点水的那个女孩要长的漂亮
我不断质问自己最初的坚守，为什么一个字符串在一个文件导出，会被多个文件依赖就要被大写!
变量命名，第一是要有区分性，第二是要有语义化
时至今日，我们还需要通过大写来突出、强调、区分吗？
出于减少魔法数值、共用、需求有变化会改动多处等目的，我们通常会声明一些公共属性、方法。
大多数项目都会有对日期的处理，关于格式化字符串的命名可谓是五花八门
const FORMAT_YYYY_MM_DD = "YYYY-MM-DD"；
const FORMAT_HH_MM_SS = "hh:mm:ss";
如果放在命名空间里呢
export namespace UDate {
export const YYYY_MM_DD = 'YYYY-MM-DD';
export const hh_mm_ss = 'hh:mm:ss';
}
export default UDate;
当时希望能够看一眼命名就知道值是什么，现在看来是有点扯蛋，根本用不着这样。
首先UDate已经具备区分性了，那么在项目中如果不需要区分"YYYY-MM-DD" 、"YY-MM-DD"、"YY / MM / DD"的话
如下就够了
export namespace UDate {
export const ymd= 'YYYY-MM-DD';
export const hms= 'hh:mm:ss';
}
export default UDate;
里面还可以放方法、接口(I)、枚举(E)
网友评论