IDEA 设置 tab 为 4 个空格、 text file encoding为 UTF-8、文件的换行符使用 Unix 格式、JavaDoc快捷键设置（公司强制要求）

现在絮叨公司开发手册，强制要求IDE 的 text file encoding 设置为 UTF-8; IDE 中文件的换行符使用 Unix 格式，不要使用 Windows 格式 ；换行tab 为 4 个空格。

原因:
在各操作系统下，文本文件所使用的换行符是不一样的。UNIX/Linux 使用的是 0x0A（LF），早期的 Mac OS 使用的是0x0D（CR），后来的 OS X 在更换内核后与 UNIX 保持一致了。但 DOS/Windows 一直使用 0x0D0A（CRLF）作为换行符。
这种不统一确实对跨平台的文件交换带来麻烦。虽然靠谱的文本编辑器和 IDE 都支持这几种换行符，但文件在保存时总要有一个固定的标准啊，比如跨平台协作的项目源码，到底保存为哪种风格的换行符呢？
Git 作为一个源码版本控制系统，对这个问题提供了一个“解决方案”。Git 由大名鼎鼎的 Linus 开发，最初只可运行于 *nix 系统，因此推荐只将 UNIX 风格的换行符保存入库。但它也考虑到跨平台协作的场景，并且提供了一个“换行符自动转换”功能。
这个功能默认处于“自动模式”，当你在签出文件时，它试图将 UNIX 换行符（LF）替换为 Windows 的换行符（CRLF）；当你在提交文件时，它又试图将 CRLF 替换为 LF。
Git 的“换行符自动转换”功能听起来似乎很智能、很贴心，因为它试图一方面保持仓库内文件的一致性（UNIX 风格），一方面又保证本地文件的兼容性（Windows 风格）。但遗憾的是，这个功能是有 bug 的，而且在短期内都不太可能会修正。
问题具体表现在，如果你手头的这个文件是一个包含中文字符的 UTF-8 文件，那么这个“换行符自动转换”功能 在提交时是不工作的（但签出时的转换处理没有问题）。我猜测可能这个功能模块在处理中文字符 + CRLF 这对组合时直接崩溃返回了。
示例：
你在 Windows 下用默认状态的 Git 签出一个文件，写了一行中文注释（或者这个文件本来就包含中文），然后存盘提交……不经意间，你的文件就被毁掉了。
问题分析：
因为你提交到仓库的文件已经完全变成了 Windows 风格（签出时把