步调开发时定名规范（目录名、文件名、函数名、变量名、数据库字段等）的最
经过实践应用，用合适的方案来给目录、文件等定名将让步调开发变得顺畅。前言
阅读本文前先相识以下两篇：
[*]《步调开发时字母大小写的定名规范（目录名、文件名、函数名、变量名、数据库字段等，小驼峰/大驼峰/短横线/下划线）》
[*]《步调开发时单数复数及前缀的定名规范（目录名、文件名、函数名、变量名、数据库字段等）》
根据这两篇的分析及开发经验订立以下定名方案：
https://i-blog.csdnimg.cn/direct/e97d3905a715446489b6d1d9fa4f16a1.png
上菜
先把最终的样子拿出来看，后面的具体表明根据这份清单来。
router/
├── index.ts
csdn/
├── components/
├── config/
│ ├── index.ts
│ ├── menu.json
│ └── system.json
├── services/
│ ├── index.ts
│ ├── httpClient.ts
│ ├── serviceAuth.ts
├── stores/
│ ├── index.ts
│ ├── pinia.ts
│ ├── storeAuth.ts
│ ├── storeMenu.ts
│ └── storeTab.ts
├── types/
│ ├── index.d.ts
│ ├── typeAuth.d.ts
│ ├── typeMenu.d.ts
│ └── typeService.d.ts
├── utils/
│ ├── index.ts
│ ├── utilTab.ts
│ └── crypto/
│ ├── index.ts
│ ├── utilBase64.ts
│ ├── utilRsa.ts
│ └── utilSecure.ts
└── views/
├── _system/
│ ├── auth/
│ │ ├── ForgotPassword.vue
│ │ ├── Login.vue
│ │ └── Register.vue
│ ├── workspace/
│ │ ├── Layout.vue
│ │ ├── LeftMenu.vue
│ │ ├── MainContent.vue
│ │ ├── MenuItem.vue
│ │ └── TabContainer.vue
│ │ └── TopNav.vue
│ └── About.vue
└── home
├── Dashboard.vue
└── Notice.vue
规范
[*]一层目录除了config，其它都是复数。
[*]原因是config在使用时将被拼接成一个整体使用，如果每个config单独调用，那么思量重立名字。
[*]非vue的文件名开头以该目录单数定名。
[*]比如utils/utilTab、stores/storeTab
原来并不在文件名开头写目录单数，但是开发时遇到这个环境
https://i-blog.csdnimg.cn/direct/28734ecf12314fed9b795b69bd96c0c8.png
三个名字如出一辙，分别属于路由、控制器和模子，这里目录名还能看到不一样，可如果目录名也一样呢？
https://i-blog.csdnimg.cn/direct/b4775f3d66c0473c8de7ade4f551434d.png
改成带有目录名前缀后，三个不同的menu同时出现在编辑器标签页里也能清晰分辨作用。
当使用了目录单数名前缀后，目录的复数名是不是也就顺理成章了？
utils/utilMenu.ts、utils/utilTab，如许的 目录/文件 看着顺眼不？
[*]一般环境内容都包含在定名空间中，且空间名称与文件名相同。
[*]比如utilMenu.ts中的定名空间就是utilMenu，如许的利益是在其它文件中引用该文件后直接就调用该定名空间了。
看下面这个例子，不消说什么，单单看到utilMenu.action()，立即就知道在哪个目录下，起什么作用。
import { utilMenu } from "../utils/utilMenu";
const csdn = utilMenu.handler;
现实开发时由于在index.ts中已经引入了该组件，所以这么写就更惬意了：
import { utilMenu } from "../utils";
const csdn = utilMenu.handler;
[*]方法、变量等定名规范参考之前的分析。
[*]这里多讲一点，每个定名空间里的类名可以不太在意，但是其对应的实例如果要定名导出一般用use前缀，例如下面的代码：
// ./stores/storeMenu.ts
import { ref } from 'vue';
import { defineStore } from 'pinia';
// 命名空间与文件名相同
namespace storeMenu {
// 标识随意，本实例名规范参考之后的说明，主要是builder或factory的区别
export const builder = defineStore('csdnMenuStore', () => {
const isCollapsed = ref(false);
const toggleCollapse = () => {
isCollapsed.value = !isCollapsed.value;
};
return {
isCollapsed,
toggleCollapse
};
});
}
// 默认导出有且只有一个
export default storeMenu.builder;
// 命名导出中必须有命名空间
export { storeMenu };
// 命名导出中必须有一个实例，且该实例名用use做前缀，目录单数做后缀
export const useMenuStore = storeMenu.builder;
// ../utils/crypto/utilSecure.ts
import SecureLS from 'secure-ls';
// 命名空间与文件名相同
namespace utilSecure {
// 类名随意
class SecureStorage {
private ls: SecureLS;
constructor() {
this.ls = new SecureLS({
isCompression: false,
encryptionSecret: 'csdn'
});
}
// 方法名随意
setItem(key: string, value: string): void {
this.ls.set(key, value);
}
// 方法名随意
getItem(key: string): string | null {
return this.ls.get(key);
}
}
// 本实例名规范参考之后的说明，主要是builder或factory的区别
export const builder = new SecureStorage();
}
// 默认导出有且只有一个
export default utilSecure.builder;
// 命名导出中必须有命名空间
export { utilSecure };
// 命名导出中必须有一个实例，且该实例名用use做前缀，目录单数做后缀
export const useSecureUtil = utilSecure.builder;
这么规范的利益你们在开发的时间自己体会。
[*]实例名
上面的代码案例中已经涉及到builder，看一下便明白本段在说啥。
除了接口类文件，一般定名空间中都有一个实例，无论这个实例是由类new来的又或者天生就是，只要这个实例是对外暴露的，那么也要有个标准名称，比如说可以根据返回值是实例还是函数定义来区分，订立原则如下：
// 返回实例，用builder
const su = storeUser.builder();
const { getId, toggleId } = su;
su.getId();
storeUser.builder().getId();
// 返回函数定义用factory
const su = storeUser.factory();
const { getId, toggleId } = su();
su().getId();
storeUser.builder()().getId();
参考：
《factory、creator、handler、builder、provider、generator、instance、constructor之间在返回实例或返回函数定义上有什么区别》
[*]总引入文件
[*]每个目录下基本都有一个index.ts，将该目录下的全部文件引入其中，如许在写代码时只需要引入到该目录即可，不需要关心下面的目录文件。
[*]推荐写法一的引入方法，扩展性更强。我个人喜好写法一的文件调用，原因是：这么写的话，当你在任何地方看到他，都立即能知道他从哪里来。
[*]如果用的函数、属性少，就用下面案例一中写法一、二的使用方法，多就用写法三、四，用到哪里调哪里。
[*]有了总引入文件后，哪怕套再多层，也能直击要害。
案例一
// ./stores/index.ts
export * from './pinia';
export * from './storeAuth';
export * from './storeMenu';
export * from './storeTab';
// 某文件
// 写法一：
import {storeMenu} from '../stores'
const { isCollapsed, toggleCollapse } = storeMenu.action();
// 写法二：
import { useMenuStore } from '../stores';
const { isCollapsed, toggleCollapse } = useMenuStore();
// 写法三：
import { useMenuStore } from '../stores/storeMenu';
const menuStore = useMenuStore();
menuStore.isCollapsed;
menuStore.toggleCollapse();
// 写法四：每个文件都有一个自己的默认导出，所以要用默认内容，导入的时候就必须精确到文件
import csdn from '../stores/storeMenu';
const menuStore = csdn();
menuStore.isCollapsed;
menuStore.toggleCollapse();
// 更多写法...
案例二
// ./utils/crypto/index.ts
// 所有命名导出继续导出
export * from './utilSecure';
export * from './utilBase64';
// 选择性的让命名导出继续命名导出
export { utilSecure, useSecureUtil } from './utilSecure';
export { utilBase64, useBase64Util } from './utilBase64';
//因为default默认的会重叠，所以不带默认的家伙们玩了
...
// 某文件
// 套娃只要引入一层，比如这里实际引用文件为 ../ytils/crypto/utilBase64.ts，但只要引入一层就能使用
// 这里导入命名空间
import { utilBase64 } from '../utils';
utilBase64.handler.encode('csdn');
//而因为在./utils/crypto/index.ts已经引入了命名导出，所以如下也是可以的
// 这里导入实例
import { useBase64Util } from '../utils';
useBase64Util.encode('csdn');
[*]其它定名
比如./stores/pinia.ts、./services/httpClient.ts等由于作用比较特殊且具有全局性，所以不把他们的前缀强制取目录单数名。
具体环境
目录中的目录改用单复数？
在上面的套娃案例中utils/crypto/...，这里的crypto该用复数还是单数呢？分析分析如下：
分析：crypto vs cryptos
当前的项目目录结构中：
csdn/
├── utils/
│ └── crypto/
│ ├── index.ts
│ ├── utilBase64.ts
│ ├── utilRsa.ts
│ └── utilSecure.ts
[*]单数（即 crypto），由于这个目录表示一个加密工具模块，而不是多个独立的工具集。crypto 更倾向于指一个整体的加密工具库。
[*]如果这个目录内专门存放不同类型的加密工具且各自独立，也可以思量用复数（cryptos），但大多数环境下，单数会显得更加自然和简便。
最终决定：crypto
[*]更符合模块定名的习惯，表明这是一个专门处理加密的工具集合。
[*]为什么这个例子单独拿出来讲，由于这是提醒你（我），在遇到单个环境的时间，一定具体环境具体分析具体决定。
总结
总的规范使用本解决方案，特例单独使用。
觉不错请一键三连。
更新
2024.12.02 更新
项目靠近尾声，根据目前的开发经验，修改或确定了如下两条：
[*]config改为configs
原本config全为json格式，直接在index.ts中合并即可。但现实使用中json文件不能标注释，无法在不同环境下提供不同设置，且服从还差点。所以综合思量还是用回传统的方式，用export分别暴露。
[*]非组件对外暴露都依照如下格式
定名空间+主输出符，并都对应一个简写方式，比如
设置类configTest.options对应getTestConfig；
实例类serviceTest.builder对应useTestService；
定义类storeTest.factory对应makeTestStore。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]