包含方法名称末尾的介词是否遵循或减损了正常的C#API设计?

Mic*_*eth 12 c# fluent-interface naming-conventions

我知道这听起来像是一个主观的答案,但我会尽量使问题尽可能客观,因为对这个问题的客观答案将是最有帮助的.

我最近有一位代码审查员指出,我习惯在我的方法结束时加入介词.这是我作为类的扩展方法编写的最新方法Point:

var rectangle = new Rectangle(0, 0, 2, 2);
var point = new Point(3, 1);

var result = point.DistanceTo(rectangle);
Run Code Online (Sandbox Code Playgroud)

我的代码审查员提到该方法应该point.Distance(rectangle).我一直认为这是主观的,也是风格问题.但是,我注意到更多的.NET API设计朝这个方向发展.例如,使用NUnit的Fluent Interface,您可以:

Assert.That(result, Is.EqualTo(1.0));
Run Code Online (Sandbox Code Playgroud)

我也和Linq见过这个:

list.CopyTo(anotherList);
list.IndexOf(item);
list.RemoveAt(0);
Run Code Online (Sandbox Code Playgroud)

.NET和/或第三方API设计人员在方法结束时使用介词是否有任何稳定或一致的方式?或者只是风格和主观问题?.NET框架中的API设计本身是否随着此策略发展,或者它是否始终存在?

Ben*_*igt 7

介词很好,只要介词的对象是相应的参数(通常是第一个,而不是this扩展方法的参数).

一个例子,它可能是晚于第一个的参数:

array.CopyCountedTo(count, destination);
Run Code Online (Sandbox Code Playgroud)

要回答你关于这是否已经与.NET一起发展的问题,不是没有.

函数名称中的介词比Microsoft更广泛(例如Java有string.charAtstring.indexOf),.NET也比LINQ使用它更长(例如ArrayList.IndexOf在.NET 1.0中).


Laz*_*rus 5

同意,这是主观的,但我的前提是我不想“转到定义”来弄清楚方法调用的作用。这个名字不应该扩展到小说中,但具有描述性当然不会有什么坏处。