i18n Ally 这个插件，很早之前就从各种的 VS Code 插件分享贴中了解到，但是一直都没有好好利用起来。特别是我当前开发的项目是我自己魔改的一个国际化维护方式 i18n Ally 并不能很好的支持。
而我的一些个人项目，并不会使用到国际化。所以即使安装了这个插件已经有将近一年了，也没有使用起来。

这几天正巧要新增加一个语言到项目中，所以趁着这次机会就决定把插件使用起来。也可以做一次内部分享，方便一下同事。现在新增了很多国际化的需求，应该可以提供一些便利。

最近在考虑把遍码习惯整理一下，一个良好的遍码习惯可以有效减少一个项目的维护成本，
因为不可能在整个项目的生命周期中，均由最初的开发人员来维护，或者所有的代码都是由你一个人写出来的，
改善代码的可读性，可以让开发人员尽快理解历史的业务代码。

之前也有研究过 ESlint的格式化风格 选择一款适合自己的来规范自己，但是了解的越多，越觉得还是需要团队互相讨论来找一个大家能都接受的妥协结果，所以最后还是选择了 Prettier ，因为我觉得其它两种风格相对来说太严苛了，很多项目都是自己开发并没有多人合作开发的情况出现，所以使用 Prettier 相对来说所自由一些…

这段时间刚刚复工，年前的我负责的一个年会大屏系统公司准备重新整理制作成为商城可售卖版本，然后又来了一个公司服务器租赁的 WebAPP 的项目，
我春节期间的外包项目也没有做完。那么给我自身 CodeReview 的时间就不够了，所以需要一个 ESLint 的通配规则来减少我编写的时候小失误，
虽然有自己的代码书写习惯，但是并没有强制要求自己，一直以来自己的 ESLint 配置仅具有错误预防功能，并没有使用一个通用的格式化风格，一直考虑的是使用 Airbnb config。

趁着 CLI 在创建项目下载依赖的时间，我想选择一个规则作为我自己的以后的编码风格，
根据 CLI 给出的提示，默认可以配置的有三种：

• ESLint + Airbnb config_detail
• ESLint + Standard config _detail
• ESLint + Prettier _detail