[muzzik分享]:浅谈自己的编程风格|社区征文

# 前言

此篇闲聊贴,大家可以随意发表自己的意见

# 命名风格

- 蛇形命名法

也就是类似 user_name 这种的,不管是类名,函数名,变量名,枚举,接口,一律使用

- 原因

强迫症,不喜欢看到驼峰有些小写开头,有些大写开头,又有些全大写的命名方式,感觉太杂乱,眼睛看着也没有蛇形清晰

以前用驼峰,现在项目要求也用驼峰,不过我私下还是蛇形,嘿嘿嘿

虽然是蛇形,不过我还是有一套自己 久经考验 的命名格式

# 命名结构

变量含义在前,变量类型在后, :chestnut:

  • boolean:
let open_b: boolean;
let touch_b: boolean;
  • string:
let name_s: string;
let time_s: string;
  • number:
let count_n: number;
let time_n: number;
  • object:若是类型名超过 4 个字符则直接省略或者简写
let temp_node: cc.Node;
let temp_anim: cc.Animation;
  • any 或不清楚类型:那就直接省略
let temp: any;
  • array:一维便是一 s,对象类型用 a 代替
// 基础数据类型数据
let temp_ss: string[];
let temp_ns: number[];
let temp_bs: boolean[];

// 对象数组
let node_as: cc.Node[];

// 多维数组
let node_ass: cc.Node[][];
let node_asss: cc.Node[][][];

如果用我这套命名法,那么不用把鼠标放变量上,一眼就能知道这个变量是什么类型,加快 code 速度

# 命名规则

首先必须满足上面的类型规则,接下来…

- Class

  • private 成员/函数:下划线开头,代表内部访问成员,从学习C++遗留至今
private _test: any;
  • protected 成员/函数:下划线开头,代表内部访问成员,如上
protected _test: any;
  • public 成员/函数:不用下划线开头,代表内外部访问成员
public test: any;

- Function

  • 参数:下划线结尾,代表外部参数,能一眼分辨函数外部参数和函数内部变量的区别
class test {
    public func(test_b_: boolean, args_as_: any[]): void { ... }
}

- 复数变量

  • 直接在第二个及之后变量末尾追加数字,为什么是第二个?因为有些时候你不确定是否会出现复数变量
let temp_n: number;
let temp2_n: number;


// 循环示例,用的最多!!!,也是最方便的
this.node.children.forEach((v, k_n)=> {
    v.children.forEach((v2, k2_n)=> {
    });
});

# 代码块划分

不知道各位是什么注释代码块的呢?会不会出现代码块注释和变量注释放在上下两行很难看的情况,或者留出几行空间注释,我觉得都不行

function temp() {
    // 这里是代码块1
    {
        let temp_n = 0;
        // 这里是代码块2
        {
            let temp_n = 0;
        }
    }
}

用块作用域来划分代码块, 就算出现变量命名相同也不会警告,更可以通过 ide 折叠代码块,获得极好的代码阅读体验!

# 文件命名

采用目录跟进式命名

// assets/script/main/login
则 login 文件夹下的 ts 文件命名为:main_login_xxx.ts

# 模块结构

当初研究了段时间模块拆分,最终选择如下

// 存放模块内部使用的接口,类型,枚举,常量等
module _test { ... }

class test { ... }

// 存放模块内部和外部使用的接口,类型,枚举,常量等
export module test_ { ... }

export default test;

# 模块集成

写框架必配,我用过几乎所有写法,下面的是我最推荐使用的方式

// ui_a.ts
export default a;

// ui_b.ts
export default b;

// ui_export.ts
export { a, a_ } from "./a";
export { b, b_ } from "./b";

// ui.ts
import * as ui from "./ui_export";
export default ui;
3赞

可怕.和我的习惯惊人地一致.

看到文件名有下划线的,心里就是一颤

为什么 :slightly_smiling_face:

同不喜欢下划线

宏怎么办,定义一个全局开启测试标志

一视同仁,全局常量可以放在一个模块内,直接通过模块名索引

能稍微讲解一下 模块集成那样写的优缺点吗

现在上班哈,有空了回复

好滴好滴。

收藏了吖, 一直想问下大厂的代码风格要求是怎么样哦???

俺也不知道,没进锅 :rofl:,但我估计是驼峰

有个规律,属性带下划线大概率是大佬

那条下划线让我很难受;分享我自己的

  1. 命名结构:变量在前,前小写后大写,类型在后,类型必须写,不清楚的any代替。
    1.1.const goHome: string = ‘’;
    1.2.let goGame: boolean = true;
    1.3.let goGame: any = 11111;
  2. Class:方法定义
    2.1.private _test: number = 1
    2.2. protected test: string = ‘’;
    2.3. public test: string[] = [];
  3. 预制体命名:大写开头,Prefab后缀结尾
    3.1. TipViewPrefab
  4. TS文件命名:大写开头
    4.1. 关联预制体时,和预制体一样的名字,TipViewPrefab.ts
    4.2. 管理器:TipManager.ts
  5. 图片资源命名:ui开头,数字结尾
    5.1. ui1…ui*,分目录归类管理
  6. 补充下类方法
    6.1.方法需要传参必须指定类型:private _test(sprite: cc.Sprite, node: cc.Node) {}
    6.2.方法非参必须定义不能带?号:private _test(num: number, color: cc.Color = cc.Color.RED)
    6.3. 方法自定义类型,必须先定义接口:interface TEST {num: string} private _test(num: TEST) {}
  7. 注释:vscode朋友强烈建议使用‘KoroFileHeader’插件,至于为啥用了就知道
    7.1. 方法注释:
    image
    7.2. 属性注释:
    image
    7.3. 行内注释:

    7.4. 正确使用注释,鼠标移动上去都会显示

    image
    7.8. getComponent()访问挂载脚本时,建议使用引用的方式,可以显示对应的注释,但一定要注意循环引用:
    image

就这样,有需要的再增加。祝大家用餐愉快。

我的命名方式就是为了避免每次都要放上去看

一般而言,命名规则其实是为了见名知义服务的,目前来说,普遍共识(可能是受阿里规范的影响)是下划线开头,表示该属性是私有的,小写开头的驼峰表示这是一个变量,大写开头的驼峰表示这是一个类,大写加下划线表示这是一个常量,大致规范如楼上所述

是阿,都明白,但是我就是不喜欢一个变量夹杂大写一个又是全小写,索性就全小写

说实话全大写的常量命名方式我一直不赞同,看起来太麻烦了,ts里面直接 const 声明,靠颜色就能判断

首先,命名规范不是强制的,只要不与公司冲突即可,当然个人开发者就随意一些,这个是大前提
其次,所谓的规范都是因为以前或者大部分是这样的,所以是这样的,比如常量大写,可能这个规则来自其它语言,刚好ts又比较适合那群java转过来的人(比如我),自然就将java的那套规范也挪过来了
最后,推荐规范的结果不要依赖编辑器,特别是所谓的颜色区分。(这点是我个人见解)

我也不是很赞同全大写的常量,确实有点难懂,可能一直以来英文不好的缘故,全大写我大脑还要转一遍小写才知道啥意思