Use consistence style

[zeroclear]

I learned a good way to join a project.

[mingkuang-Chuyu]

我不接受 clang-format ，风格是否完全一致这并不重要。

2015我也并不想支持编译，因为这会让无用条件编译代码增加，另外开发者只需要使用新的编译器即可。不需要过于纠结是否支持老的编译器编译。如果需要考虑，2008用户也会提出要求。我们只需要支持他们使用，至于是否可以编译源代码，我认为这不重要。

其他类型的更改我也并不喜欢，因为那就是我的风格，

我唯一可以接受的就是源代码文件使用UTF8编译，对于这一点，我会手工转换他们。

此外，我不得不说，这个pr 报告了太多了无意义的更改，如果你的初衷是增加 clang-format，那么所有更改应该只服从这个改动，不应该引入其他没有影响的提交记录。

[lygstate]

我不接受 clang-format ，风格是否完全一致这并不重要。

2015我也并不想支持编译，因为这会让无用条件编译代码增加，另外开发者只需要使用新的编译器即可。不需要过于纠结是否支持老的编译器编译。如果需要考虑，2008用户也会提出要求。我们只需要支持他们使用，至于是否可以编译源代码，我认为这不重要。

其他类型的更改我也并不喜欢，因为那就是我的风格，

我唯一可以接受的就是源代码文件使用UTF8编译，对于这一点，我会手工转换他们。

此外，我不得不说，这个pr 报告了太多了无意义的更改，如果你的初衷是增加 clang-format，那么所有更改应该只服从这个改动，不应该引入其他没有影响的提交记录。

不懂你的要求， 到底是不接受clang-format 还是不应该引入其它没有影响的提交记录

风格一致当然重要，方便代码review，保持风格统一也可以让后序 PR不需要考虑代码风格问题

[zeroclear]

不懂你的要求， 到底是不接受clang-format 还是不应该引入其它没有影响的提交记录

风格一致当然重要，方便代码review，保持风格统一也可以让后序 PR不需要考虑代码风格问题

原来你会说中文啊，那为什么要把中文注释改成英文的呢？ 我觉得你这些PR很没道理。风格方面，打个更直观的比方，别人写了一份C代码，左大括号不换行，你给改成换行的，还反过来劝作者换行怎么怎么好，合不合适自己好好想想。 编译配置维护一份最常用的就可以了，谁要有特殊需求自己在项目里改，没必要为了小众情况搞得太复杂。你用clang，还有人用Intel编译器呢。 至于编码这种事情也能PR，你真不是来灌水的？好自为之吧。

[lygstate]

不懂你的要求， 到底是不接受clang-format 还是不应该引入其它没有影响的提交记录 风格一致当然重要，方便代码review，保持风格统一也可以让后序 PR不需要考虑代码风格问题

原来你会说中文啊，那为什么要把中文注释改成英文的呢？ 我觉得你这些PR很没道理。风格方面，打个更直观的比方，别人写了一份C代码，左大括号不换行，你给改成换行的，还反过来劝作者换行怎么怎么好，合不合适自己好好想想。 编译配置维护一份最常用的就可以了，谁要有特殊需求自己在项目里改，没必要为了小众情况搞得太复杂。你用clang，还有人用Intel编译器呢。 至于编码这种事情也能PR，你真不是来灌水的？好自为之吧。

变成网暴了啊，算了不纠结了

[mingkuang-Chuyu]

@lygstate 因为你的提交记录设计了多个方面，所以我分别回复了你的问题，我认为我的回复很明确。

1. 不接受 clang-format 统一风格，因为我觉得风格并非很重要。因为很显然很少PR可以直接采用，我一般都是手工合并代码。
2. VC 2015编译 支持不增加，这破坏代码的简洁感。
3. 文件格式改成 UTF8 这个可以接受，未来我会统一调整。

最后，你的PR包含了太多无关的记录。

[mingkuang-Chuyu]

@zeroclear 我觉得编码问题 提交PR 没有太大问题。

[zeroclear]

@zeroclear 我觉得编码问题 提交PR 没有太大问题。

改UTF8实际是个不错的建议，放到issue里和维护者商量下比较合适。我个人的观点是贸然修改容易造成项目内编码不统一，到处改编码还有刷战绩的嫌疑。或许别人一片好意被我曲解了，如果是这样我道歉。