关于svn提交代码规范问题探讨

那怎么保证每个人自己的风格能统一呢？规范这种东西不强制靠人自己主动遵守是不可能的，强制format，再加checkstyle，findbugs，至少是可以很好的解决编码规范问题的。

只能多强调,老手已经有自己的风格了,新手存在问题,所以新手如果不能只能shift+crtl+f来进行格式化

这个看情况吧，也不是绝对。如果项目开发要求统一的IDE，这个不是问题；但是如果不同的IDE的话，那就是绝对不能有的。

上家单位，我带的团队就是要求统一格式的，所有格式，文档都是统一，IDE也是统一ECLIPSE，然后我制定出一个统一的配置文件，格式化，注释规范，检查代码等等，所有队员使用的都是相同的配置文件，所以这个没有问题，格式化出来的效果都是一样的。

当然，如果项目大，或者在一些涉及到不同部门，不同地方办公的，有可能大家使用习惯不一样，那么这个规定就不能执行了  呵呵

这个不存在什么老手和新手的问题吧，这个是制度规范的问题。看你怎么去执行，从质量管理的角度来说，牛人也一样要遵守开发的规范。

我倒是同意aronlulu同学的说法，我以前也做过公司质量管理这块的工作，当时我用的就是类似aronlulu说的那样，统一格式化配置文件，统一注释风格配置文件，统一checkstyle文件，统一findbugs，统一emma等，而且这些动作都是服务器自动执行（持续集成），如果开发员提交不规范，最迟第二天就能看到结果。

我最反感那些以牛自居的人，以为自己技术了不起，不愿意服从公司的管理，自搞一套。想以前的技术经理，我说要搞单元测试，用Junit，他就非用在类里写个main函数来测试，那么持续集成报告怎么出来？要求一个类功能要独立，方法要简短，人家就说我就喜欢一个方法写看完功能，从头读到为，跳来跳去的不习惯。你能说什么？人家还举例说你看spring源码，里面不是也有很多代码很长的方法！无语了..... 等等。当然最后还是要他遵守公司的规章决定。

当然，我在制定这些规范的时候，也不是自己一人说的算，是跟他家一起讨论一起商量的，也不是说所有都必须严格按规范执行，比如一个方法不能超过XXX行，这也不是死的，毕竟有些功能就是要那么长的代码，但是不会是大部分都这样。

恩,说得相当好,但是实施有些东西,强推大家都抱怨,不能取上,只能取中了

貌似现在Git版本控制比较流行哦。

我个人认为这个问题应该是这样：
  1. 既然定下规范，当然应该按照规范进行。
  2. 牢记当初定下规范的目的，不要为了执行规范而执行。
  3. 如果员工的个人习惯不和规范冲突或严重冲突，尽量尊重员工的个人习惯。

----------

比如说，有些公司的工作必须要所有员工都在一起才能完成，所以规定：
  1. 早上9点上班，下午6点下班，中午12点到13点午餐。
  2. 迟到扣钱，早退扣钱，旷工扣钱。
  3. 全勤奖励。
但是有些公司并不需要这样，所以规定：
  1. 每天8小时工作制，员工早来早走，晚来晚走。
  2. 由于中间有一小时午餐时间，所以必须呆满9小时才能走。
还有些公司连时间也并不强求，所以规定：
  1. 必须完成自己的工作。
  2. 可以来公司，也可以不来公司，但必须按时交付工作。

这个就没必要吧。一般我们的代码author都写开发团队名称，而不是开发者个人名称。

真正想明确责任，可以看历史记录，就知道是谁写的。

嗯，真的不能格式化。。。

艹蛋的格式化

本来手排的好看的一版，就被一个快捷键弄没了

我表示很蛋痛，统一的格式可以减少代码版本冲突