ndepend - Refining CQLinq rule for nested visibility -

we have ndepend 5.4.1 , want alter queries field/type/method have lower visibility. want query take scope of enclosing class account when deciding whether consider violation.

for example,

internal class x {    public int a;    public void b() { }    public class c    {       // …    } } 

we don’t want a, b or c generate violation saying of them should made internal. if class x public, on other hand, , none of a, b , c used outside assembly, should generate violations.

to accomplish this, added following line queries:

 // consider visibility of enclosing class  f.parenttype.visibility < f.optimalvisibility 

so fields, new query looks like:

// <name>fields have lower visibility</name> warnif count > 0 f in justmycode.fields    f.visibility != f.optimalvisibility &&  !f.hasattribute("ndepend.attributes.cannotdecreasevisibilityattribute".allownomatch()) &&  !f.hasattribute("ndepend.attributes.isnotdeadcodeattribute".allownomatch()) &&  // consider visibility of enclosing class  f.parenttype.visibility < f.optimalvisibility  select new { f,               f.visibility ,               couldbedeclared = f.optimalvisibility,              f.methodsusingme } 

i altered query method visibility , type visibility in similar manner, except types make sure there enclosing parent type:

(t.parenttype == null || t.parenttype.visibility < t.optimalvisibility) 

at first glance , after running tests, seems doing right thing. question whether generate false positives or miss violations, since not sure whether enum visibility orderings (comparisons) right thing in cases.

here ndepend.codemodel.visibility enumeration declaration:

   public enum visibility {       none = 0,       public = 1,       protectedandinternal = 2,       protectedorinternal = 3,       internal = 4,       protected = 5,       private = 6    } 

hence x.parenttype.visibility < x.optimalvisibility means x parent type visibility strictly less restrictive x optimal visibility.

notice protected ordered more restrictive internal not true neither internal more restrictive protected. had provide arbitrary ordering between these 2 visibility level.

notice method/field/nested type can declared in nested type (recursive) correct we'd need gather outter types visibility.

these 2 facts make me thing construct edge cases rule return false positive, after tinkering bit didn't succeed so.

what advice @ code base(s) how custom rules behave see if should modified. if fine, consider fine until find false positive.

---

there long related debate on eric lippert blog if member of internal type should declared public or internal. there solid arguments on both side, , way our code rule written favor side it should declared internal, , change favor side it should declared public.