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

这篇文章真好。

审美风格不一样
你说你老婆好看,我说我老婆好看,有些还喜欢别人老婆。
代码风格简单,能一眼辨认即可
毕竟大家走的都是美国风
要求太苛刻的主程会被打的

我们项目已经要求了用eslint,不是驼峰直接报红:joy:

我也喜欢用蛇形命名,阅读好阅读一些

好分享,但看着下户线头疼

解析遇到不想用的字段或者属性,一律 _ 代替, :sweat_smile:

个人还是比较喜欢用 驼峰. 用符号间隔如果有遇到需要解析Key的时候.就很难受了 :rofl:

首先说下我知道的模块集成方式

# (无 import export 模块的)全局自注册模块

// a.ts
module module_a {
  export const a = 0;
}
globalThis.module_a = module_a;

// 使用
globalThis.module_a;
  • 好处:
    • 方便快捷
  • 坏处:
    • 污染全局
    • 不能保证引用时模块已经注册完成,但可以用修改 bundle 加载顺序方式避免

# 局部自注册模块

// module_map.ts
const module_map: [[k in keyof module_map]: module_map[k] ] = {};
export default module_map;

// a.ts
import module_map from "./module_map";

class module_a {}

// module_map 存储所有注册模块到 
module_map["module_a"] = module_a;

declare global {
    interface module_map {
        module_a: module_a;
    }
}
  • 好处:
    • 不污染全局
  • 坏处
    • 需要架构的回调才能确定模块已经加载完成,例如 EasyGameFramework 就是使用的这种方式

# 局部集成模块

如上文

// 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;
  • 好处:
    • 不污染全局
    • 可以使用 npm 上面的各种打包 dts 导出工具,没有任何问题,方便写库,框架
    • 可以自定义集成块,比如 a 和 b 可以放在 c 集成,也可以放在 d 集成
  • 坏处
    • 每个集成块都需要一个 export 导出文件 和 一个 import 集成文件

学到了 感谢大哥解惑

对于框架内的模块,和业务模块,生命周期回调是一个约束,也是保证互相之间能正确依赖。
是坏处吗?
针对一些第三方库或者不依赖业务的,和框架也没有耦合,可以使用全局的方式。也可在生命周期的某一环注入
对于模块之间有耦合,或者对框架有依赖的,对业务有依赖的,放在生命周期中注入,会相对好一些。

对于我个人而言,任何有限制的,都属于坏处

这得看个人了。
当你的模块之间依赖达到一定复杂度时,你终究会用一个流程限制,确保依赖正确。
而这个流程其实就相当生命周期或者某种回调,只是比较初始的

所以编程要符合规范,父类不能依赖子类,上不能用下,最基本的原则

而且大多数情况下是不会出现循环引用的问题,即使两个模块互相引用,只要不在js虚拟机加载模块时使用另一个模块,就不会出现循环引用的问题

同样,很烦下划线

不是驼峰,我很难受

是驼峰,我很难受

我想知道你们资源的命名是怎么样的

全大写,看上去感觉单词都不认识了

大写加下划线呀 :grinning: