这么多年一直没有太在意代码文件 tab/空格， UTF/GBK ， UNIX/DOS 换行符 的问题，这几天被 Git 坑的不浅，需要统一处理一下并以后固定下来， 大家都怎么设定的呢？

[sdjkx]

这么多年一直没有太在意代码文件tab/空格，UTF/GBK ，UNIX/DOS换行符 的问题，这几天被Git坑的不浅，需要统一处理一下并以后固定下来， 大家都怎么设定的呢？

[EPr2hh6LADQWqRVH]

统一处理还不是分分钟的事？

[sdjkx]

@avastms 不想自己的习惯设定和别人差异太大，所以想了解下比较流行的做法

[Livid]

UTF-8 without BOM
LF Line Ending
Spaces for indentation

[jwk345]

一般都是按楼上的这么做：
1、文件一律 UTF-8
2、代码一律用空格缩进，这样不管在什么编辑器下看起来效果都一样
3、使用 Unix 换行符
除非项目有自己的代码风格

[nicai000]

你自己不规范还说Git坑你... 编码也没注意, 没处理过中文显示之类的问题么?

UTF-8, Unix换行, Python空格缩进, 其它全Tab缩进(但是不用行中Tab对齐).

Tab缩进就是8个空格的长度, 自定义导致出问题的人或者编辑器都是异端异端异端! (笑

[FrankFang128]

是你在坑git

[kingme]

在Windows下面用GIT管理C#的项目，其实还是有很多的坑。。
我遇到过的几个小坑说一下，希望有朋友遇到过并且解决了：
1.换行符，使用GIT的format-patch功能打上补丁之后，VS会提示换行符混合，需要处理成Win的换行符
2.对于资源文件，比如添加了图片的resx，git做merge的时候基本上不可能成功合并。。
3.winform相关的界面改动，会导致designer文件变动，由于这个文件是根据控件的顺序变化的，导致merge十分麻烦，如果是两个人改一个界面的话真的是蛋疼（这里需要考虑分工的问题）
4.中文支持，这个的话主要是VS不能设置所有文件的默认保存编码为UTF-8，中文乱码，但是影响不大，只是在做format-patch的时候基本上有中文注释的编码就会应用失败。但是使用cherry-pick就没问题。
想到再补充吧。。。希望有小伙伴解决啦

[keenkiller]

@kingme 用vs开发，就用vs自带的版本管理呗…应该支持的好一些吧。

[cnwuwil]

一定要UTF-8 without BOM！！！

[kingme]

@tairan2006 TFS 的分支你懂得。。。。习惯了GIT的分支之后。。。。。。

[aaaa007cn]

@kingme
vs 保存的文件默认 utf-8 with bom
所以我随手写了个简单的 python 脚本用来去 bom、改换行符 CRLF 到 LF
顺便去掉行尾空白，并给 EOF 加个换行符
Designer.cs 这种硬伤就只能放弃治疗了

[zhicheng]

在源代码里 UTF8/GBK 或者 BOM 或者 Line Break 出问题的，都不能算是合格程序员。
在缩进和对齐上，tab用来缩进，空格用来对齐是国际惯例，包括 Python 。这样在所有的编辑器，不管是 4 空格缩进，还是 8 空格缩进，看起来都是正常的。

[rming]

国际惯例不是 utf8 / 4空格 / 无bom / unix换行符 么

[typcn]

utf8无BOM
4空格 callback多的语言2空格
换行LF

[mongodb]

@typcn 上次看linus还谁说喜欢8空格..

[thinker3]

在windows,ubuntu下同时使用vim, gvim, git的我表示，坑很多

[vjnjc]

团队分布于wins osx 和ubuntu的情况下，坑确实不少

[FrankHB]

0.禁用AutoCRLF。
1. indent必须使用U+0009，alignment必须使用U+0020，禁止混用表示单一用途。没为什么，这就是这些字符的原意。如果文本编辑器显示会抽风/没法配置，那说明的编辑器太残了。
2. 除了特定的脚本（依赖shebang/Windows批处理）或者准备到处cat的东西，都使用UTF-8+BOM。
UTF-8尽管空间效率不一定就高，但是兼容性良好。如果是其它编码，至少也得用基于UCS的。GBK首先的问题就是没法涵盖某些字符，换GB18030经常又不如UTF-16。UTF-8的另外一个好处是字节序统一，没有纠结LE和BE的必要。
没有BOM的东西充其量只是可能随处中断不完整的byte sequence，是不是就配叫regular file呢，值得怀疑。
3.只要使用的实现支持CR的情况就CR+LF。大多数实用的编辑器同时支持两者，有些支持检查不当的混用。注意有些协议要求CR+LF。而违反CR+LF导致的错误比违反LF通常更容易检查。
Reference: https://bitbucket.org/FrankHB/yslib/wiki/WikiRules.en-US.md

[dorentus]

@FrankHB 既然“UTF-8字节序统一”，那还要 byte order mark 作甚。

[williamx]

要我说这东西压根就不应该有选择。