4个论点
1. 这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
我不同意这个看法。我不否认在现实生活中有些规则确实实在官僚主义下产生的，但这一点并不适用于代码猿猿界。进行软件工程的人基本上都有化繁为简的倾向，而代码规范也是在这种情况下产生的，为了方便码代码以及团队中的交流沟通，在团队项目中尤其重要。所以代码规范是能够节省大家的编程时间、提高人们的开发效率的东西。
举例说明，在一个中型大小的项目团体中，如果没有统一的代码规范，团队中的每个人都仅仅按照自己的习惯进行程序的编写，那么在开始自己写自己负责的部分时，的确速度很快，但是在合并的时候便出现了很大的问题，由于代码风格不统一而引发的血案不见得少见。你的左大括号放在行尾我就偏不认、你用Tab不好意思我是空格党、你拿英文命名就是不支持正宗国货拼音、你在函数外判断输入合法性就是没有我们在函数内判断的洋气……如此一来二去，好点的的团队，撕逼几天后败阵的一方妥协下来，被迫形成一个早就该形成的代码规范，打回重新写就是；不好的团队，可能自此一刀了断老死不相往来，项目也就此搁置。当然，这是个比较夸张的说法，但因代码没有规范的问题而造成的时间上的浪费绝对不可小觑，更不必提由此带来的沟通问题、读代码问题、维护问题等等。
2. 我是个艺术家，手艺人，我有自己的规范和原则。
如果是个人的项目，完全可以以艺术家自居，保持自己的规范和原则。但是如果是集体项目，还是放弃吧。艺术家、手艺人有自己的规范和原则的前提是他可以自己完成整件作品而不需要与他人合作，更没必要在乎别人的看法和整个团队的利益。而团队开发中的程序猿明显不属于这个范围。为了最终项目的完成，每个人最好都牺牲掉自己一部分的规范而接受整个集体认同的规范。
3. 规范不能强求一律，应该允许很多例外。
这一点，视情况而定。从适用性来讲，一个专门针对当前项目的规范其实是最合适的，如果更改规范造成的人员适应时间成本远小于规范适应性带来的项目进度成本，那么规范确实没有必要强求一致。但是，如果是在一个比较大型的企业中，企业员工已经习惯用一套比较成熟的规范进行代码的书写、代码的复查、代码的测试以及程序的维护和改善，那么久没有必要为了一个项目而改变原有的规范而推行新的规范了。否则整个代码生产线都会被延滞。
4. 我擅长制定编码规范，你们听我的就好了。
这一点，见仁见智。我认为，如果你确实很擅长制定编码规范，你制定的规范简洁好懂清晰大众化高端大气上档次，最重要的是，你团队里的绝大多数人都愿意放弃自己的代码习惯而奉你的规范为圣旨，那完全可以考虑让整个团队都遵循这一种代码规范。但是，在现实生活中，这种规范大神下凡的情况还是比较少见的，大多数的情况下说出这句话的人只是自认为自己擅长制定编码规范，而“你们听我的就好了”看似霸道总裁实际中二的表现只能招来团队中其他成员的不满。而这种情况下，尤其在团队协作中，还是应该以集体利益为先，保证公平。在工程开始之前，整个团队应该开一个会来决定一个公认的、保证遵守的代码规范，可以尝试每个人贡献一条自己认为最有效率的规则，同时牺牲自己其他的代码规范。这样人人有失有得，人心相聚，团队力量才能发挥出来。