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

Creator 3.x
#24

这篇文章真好。

#25

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

#26

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

#27

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

#28

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

#29

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

#30

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

#31

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

# （无 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 集成文件
#32

学到了 感谢大哥解惑

#33

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

#34

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

#35

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

#36

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

#37

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

#38

同样，很烦下划线

#39

不是驼峰,我很难受

#40

是驼峰,我很难受

#41

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

#42

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

#43

大写加下划线呀 :grinning: