I've been working with a small group of people on a coding project for fun. It's an organized and fairly cohesive group. The people I work with all have various skill sets related to programming, but some of them use older or outright wrong methods, such as excessive global variables, poor naming conventions, and other things. While things work, the implementation is poor. What's a good way to politely ask or introduce them to use better methodology, without it coming across as questioning (or insulting) their experience and/or education?


当前回答

您可能想要关注坏代码的影响,而不是您对它的风格是好是坏的主观看法。

其他回答

这里的许多答案都与代码格式有关,但现在并不是特别相关,因为大多数ide将按照您选择的样式重新格式化代码。真正重要的是代码是如何工作的,海报是正确的查看全局变量,复制和粘贴代码,以及我的烦恼,命名约定。糟糕的代码是存在的,这与格式没有多大关系。

好的方面是,大多数情况下都有很好的原因,这些原因通常是可量化和可解释的。所以,用一种非对抗性的方式解释原因。在许多情况下,您甚至可以为作者提供问题变得明显的场景。

我总是说‘这就是我要做的’。我不会试图教训他们,告诉他们他们的代码是垃圾,而只是给他们一个不同的观点,希望能向他们展示一些明显更整洁的东西。

介绍代码标准的思想。关于代码标准最重要的事情是它提出了代码库的一致性(理想情况下,所有的代码都应该看起来像由一个人一次编写的),这将导致更容易理解和可维护的代码。

坦白地说,我相信当某人的代码更容易修改、调试、导航、理解、配置、测试和发布时,他的代码就会更好。

也就是说,我认为不可能告诉某人他/她的代码不好,而不先让他/她解释它是做什么的,或者任何人应该如何增强它(比如,创建新功能或调试它)。

只有到那时,他们的大脑才会崩溃,任何人都能看到:

全局变量值的变化几乎总是不可追踪的 庞大的函数很难阅读和理解 模式使您的代码更容易增强(只要您遵守它们的规则) (等)

也许一段结对编程就能达到目的。 至于执行编码标准——这是有帮助的,但它们离真正定义什么是好代码还很远。

他们可能也认为你的风格很糟糕。让团队一起讨论一套一致的编码风格指南。同意某事。这是否适合你的风格并不是问题,选择任何风格只要它是一致的才是重要的。