Соглашения о присвоении имен для дополнительных пространств имен метода и классов спонсора
Массив . length Метод - это не количество элементов массива, а самый высокий индекс. даже когда элемент был установлен на undefined
var a = [];
a.length; // === 0
a[10]; // === undefined
a[10] = undefined;
a.length; // === 11
a.pop(); // === undefined
a.length; // === 10
, это поведение вряд ли можно отличить от ошибки проектирования языка.
2 ответа
For the Namespace - I would focus on the standard framework guidelines for namespace names. Put the extension methods into a namespace where they will typically be used/associated meaningfully, and avoid having an extra namespace just for this.
For the sponsor class - in this case, it's fairly unimportant. I would try to pick a class name that is meaningful, but there does not seem to be a fixed guideline.
The important thing here, though, is that the sponsor class is never really directly used/seen by the user of your extension methods. As long as the namespace has been included, the extension method is found correctly. I personally use something very similar to jrummell for my extension methods, but Microsoft does not follow this in the Framework (a good example of this is the Enumerable class).
Я не видел никаких официальных рекомендаций, но я организовал свои классы расширений, такие как [NameSpace]. [ClassName] Extensions:
ProjectName.Web.Util.ControlExtensions
ProjectName.Data.Util.CollectionExtensions