Запрос NDepend для рассмотрения геттера и сеттера для свойства как одного метода

Я перешел по ссылке Могу ли я найти количество методов без количества геттеров через CQL? и исключил свойства из одного из моих запросов NDepend.

Одно из наших правил кодирования также заключается в том, чтобы количество свойств в классе (включая автоматические свойства) не превышало 10 (чтобы соответствовать другому правилу, согласно которому для класса может быть определено не более 20 методов).

Проблема в том, что даже если у нас есть 10 свойств в классе, что находится в определенных пределах, количество методов отображается как 20. Я понимаю, что это связано с тем, что get_ и set_ для одного свойства считаются двумя разными методы. Но есть ли способ, с помощью которого мы можем изменить запрос NDepend, чтобы методы get_ и set_ для свойства учитывались как один метод?

Спасибо


ndepend
person PRN    schedule 20.05.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Вот правила CQLinq, которые предупреждают о типах, имеющих более 10 свойств, и перечисляют свойства через геттер или (эксклюзивный) сеттер. Проницательность заключается в использовании таблицы Lookup, где геттеры и/или сеттеры индексируются по имени свойства, полученному из имен геттеров/сеттеров:

// <Name>A class should not have more than 10 properties</Name>
warnif count > 0 

from t in Application.Types

let accessers = t.Methods.Where(m => m.IsPropertyGetter || m.IsPropertySetter)
where accessers.Count() > 0 // Optimization!

// Here we build a lookup that associate for each property name, the getter, the setter, or both.
// The property name is getter and/or setter simple names, without "get_" or "set_" prefixes (4 chars).
let propertiesLookup  = accessers.ToLookup(a => a.SimpleName.Substring(4, a.SimpleName.Length -4))
where propertiesLookup.Count() > 10

let properties = propertiesLookup.Select(p => p.First())
select new { t, properties  }

Это правило также перечисляет свойства для каждого совпавшего класса.

NЗависимое правило CQLinq

У нас есть спрос на наш User Voice для создание интерфейса NDepend.CodeModel.IPProperty, который облегчит разработку такого правила, не стесняйтесь голосовать за это!

person Patrick from NDepend team    schedule 20.05.2014
comment
Спасибо, отлично работает. Я также проголосовал за создание интерфейса IProperty. - person PRN; 28.05.2014