代码采用这种形式的可读性有多重要:
public void DoStuff()
{
var v = new Object();
v.PropertyID = "abc";
v.Type = "abc";
v.Style = "abc";
v.SetMode(Mode.Abc);
v.Draw();
}
VS
public void DoStuff()
{
var v = new Object();
v.PropertyID = "abc";
v.Type = "abc";
v.Style = "abc";
v.SetMode(Mode.Abc);
v.Draw();
}
我倾向于喜欢第一种最好的风格,它使事情易于阅读,你会如何温柔地引导人们走向前者而远离后者?或者不是吗?
答案 0 :(得分:2)
人们真的会编写看起来像后者的代码吗?这是可维护性的噩梦。
我认为你的代码格式约定并不重要 - 更多的是你一贯地遵循它们。前一个例子不一致,因此难以理解且不可维护。
如果您遇到麻烦引导人们保持一致性,请让他们想象一下在一年内维护高度不一致的代码。
答案 1 :(得分:1)
格式非常重要,尽管不是必需的。如果我看到像后者这样的代码,我会有点恼火。如果您正在花时间编写代码,请确保花时间正确格式化。
答案 2 :(得分:1)
如果是我的代码,我会这样做:
public void DoStuff()
{
var v = new Object();
v.PropertyID = "abc";
v.Type = "abc";
v.Style = "abc";
v.SetMode(Mode.Abc);
v.Draw();
}
这样很清楚哪些行是属性赋值,哪些是方法调用。
我也同意杰米的回答,该回答称“格式非常重要,尽管不是必不可少的。”重要的是格式化并不是那么糟糕,以至于损害了其他人阅读它的能力。我不相信一些额外的标签或换行符会对一个称职的程序员大部分时间产生巨大的影响。
答案 3 :(得分:0)
在第二个示例中,您的花括号不会同样缩进。
间距对我来说很重要。如果你在我的公司写代码 - 我可能必须在某个时候阅读它。如果你没有格式化你的代码 - 我将使用autoformatter来获得我需要的东西。
答案 4 :(得分:0)
在团队中工作时,风格至关重要。所以你选择的风格并不重要,只要确保每个人都同意它,然后执行协议。将IDE设置为自动格式化代码..并确保每个人的IDE设置相同。
答案 5 :(得分:0)
如果你想要善良,请给他们代码完成阅读。如果你想成为卑鄙,在他们的代码中引入像这样的sublte bug:
if (x==y);
DoSomething(); else
DoSomethingElse();
while(Whatever)
SomeFunction();
(如果他们在不到一天的时间内发现了这个错误,那么你就不会满足了。)
答案 6 :(得分:0)
我更喜欢你的间距,不过我会做的有点不同。我相信你最重要的问题是如何让别人相信你的方法是最好的:代码格式化可能非常主观。有些人反对,因为它需要太多时间才能正确。其他人反对,因为团队没有任何编码标准。有些人反对,因为感觉它被挤在脖子上。
最好的方法是与您的团队合作,达成共识,即您的特定方法是最佳做法。如果您是领导者,或者您是个人贡献者,则情况确实如此。
一旦团队达成共识(可能不是通用的),我发现代码审查是确保遵循团队实践的最佳位置。我建议您会发现同伴压力是鼓励其他人遵循公认最佳做法的最有效方式。通常是真实的;如果没有达成共识,一个人很难在团队中发挥这种作用。
以下是我的一些相关StackOverflow答案
答案 7 :(得分:0)
正如其他人所说,第一个例子是常态;第二个不同于它。
此外,请确保处理同一组文件的每个人都具有与“标签”相同的约定。最好将其定义为多个空格,并确保每个人的文本编辑器和IDE都同意。
当三个或四个人在同一个SVN存储库中工作并使用不同的间距约定编辑每个文件时,会很烦人。
答案 8 :(得分:-1)
第二种方式并不是很好。避免它。
我也认为人们倾向于像这样格式化。在一个月内,另一个人会来并希望这种格式
public void DoStuff()
{
var v = new Object();
v.PropertyID = "abc";
v.Type = "abc";
v.Style = "abc";
v.SetMode (Mode.Abc);
v.Draw ();
}
这非常愚蠢而且难以使用。
如果人们这样编码,就会质疑他们的推理和编程能力。