Bonsoir Antoine, On Sun, 2010-11-28 at 13:21 -0800, Antoine V wrote: > Hello, > > I am writing a rule to check the compatibility between satellites > assemblies resources and main assembly resources. > The code is here : > https://github.com/avandecreme/mono-tools/commit/cf719d7361569c5975b95193ec3979d042355ca2 > Thanks Sebastien for helping writing Makefiles. > > It currently report a defect if : > - a resource exist in a satellite resource but not in the main > resource. It is not a major defect but less code is always better ;) > - a resource haven't the same type in the main and satellite > assemblies. Major defect here because the code will probably throw an > InvalidCastException latter. > - the resource is a string resource with string.Format parameters ({0} > - {1} ...) and the number of parameters don't match in both > assemblies. Major defect too (can raise InvalidFormatException), but > lower confidence since I don't check if a formatting method is > actually called.
Sounds awesome :-) > > I have some questions about this rule : > > -in which assembly should we provide it ? It is currently in > Gendarme.Rules.Maintainability but maybe a new > Gendarme.Rules.Globalization assembly would be better (fxcop have such > assembly but not such rule, see > http://msdn.microsoft.com/en-us/library/ms182184.aspx > ) Go with Gendarme.Rules.Globalization. It's more precise (that makes user selection easier) and I don't doubt we'll, eventually, get more globalization rules :-) > -which name ? It is currently RemoveOrphanResourcesRule but that only > fit the first point. Maybe SatelliteResourceDoNotMatchMainResourceRule > (very long :/ ) maybe just "SatelliteResourceMismatchRule" ? > And a more coding interrogation : > - in the rule I write a method to count the number of parameters of > string.Format like in ProvideCorrectArgumentToStringFormatRule (but > with bug fixes, for example "{1} - {2}" is a valid format which > require 3 parameters, see > http://msdn.microsoft.com/en-us/library/txafckwd.aspx Yes, there are other limitations as well (iirc max 10 items). > ) This method is quite complex and I think it should be shared between > the two rules (and maybe others) so I don't know where to write it. Always start with your own (new) rule and make it work (i.e. debug) there. Once committed (and we've a bit of time to find bugs, false positives...) then we can talk about re-using it (and how best to do it). > Also I think this method should have a variant to get exactly which > parameters are used (for example if the input string is "{0} - {2}", > the method return a List<int> with values 0 and 2) to allow : Allocation-wise I'd prefer a Bitmask<long> but I see your point ;-) > * the ProvideCorrectArgumentToStringFormatRule to check unused > parameters as it is often (always ?) a typo > * the "RemoveOrphanResourcesRule" to check if the used parameters > are identical in main and satellite assemblies. In general it's best to avoid over-designing in rule X for another rule Y. Find the best solution for your rule and, afterward, we can see if it's play well for other rules (reuse), adapt well for many use (refactor) or if two, quite similar, methods are best. > And a last question, I would like to have a > AvoidUnusedInternalResourceRule very similar to > AvoidUncalledPrivateCodeRule. Actually it would be exactly the same > code excepting the beginning checks to determine if the rule apply. I > don't know if we must adapt the current rule to support the resources > too or create a new rule and share the common code. Same advice. Start with AvoidUnusedInternalResourceRule by copy-pasting AvoidUncalledPrivateCodeRule. Once the rule is complete (and tested) then look if it still makes sense to share code between them (it sounds like a good idea - but Murphy might have other plans for this ;-) If everything works up as expected then we'll look into (a) inheritance or (b) re-factoring parts of it into an Engine (which is something I considered for the above rule - but lacked enough justification to do ;-) > > Sorry for this long post with lot of questions and thanks in advance > for replying whether to answer to my questions or to suggest anything > about the rule, resources checks or my code. > > Regards, > Antoine > -- You received this message because you are subscribed to the Google Groups "Gendarme" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/gendarme?hl=en.
