Safety net for convention methods?

Jul 7, 2013 at 1:04 PM
I remember discussing this long ago, maybe years, but cannot remember the outcome.

I have a method DoSomething(...)
Then I have methods HideDoSomething, ValidateDoSomething, Choices0DoSomething, and Choices1DoSomething.
At some point one of our team members decides that method's name is not accurate enough and so refactors it to DoSomethingNice(...).
Obviously the convention methods do not get renamed in the refactor, and sometimes we forget to manually go and rename them. Those methods then appear on the UI, usually discovered at some random later time.
We would love to have an automated way of catching these as early as possible.
Can the framework, on start up, check for convention methods starting with it's recognized set of prefixes that do not have any matching logic methods, and display warnings for those? They could then be suppressed with an attribute if in fact the developer intended them.
Editor
Jul 8, 2013 at 7:43 AM
+1 on this; I've taken the liberty of creating an issue [1] to track this idea.

Dan

[1] https://nakedobjects.codeplex.com/workitem/222
Coordinator
Jul 8, 2013 at 8:27 AM
Edited Jul 8, 2013 at 8:27 AM
Can the framework, on start up, check for convention methods starting with it's recognized set of prefixes that do not have any matching logic methods, and display warnings for those?
It is certainly something that could be done. (Though the warnings would be logged, not displayed). Another long term option - when 'compiler as a service' becomes properly available, is to do a kind of Naked Objects compile and issue warnings at compile time
Those methods then appear on the UI, usually discovered at some random later time
The fact that your renamed method no longer has choices or validation should have immediately been picked up by your XATs - which suggests to me that you aren't making effective use of them. (A particular bug-bear of mine is over-belief in unit tests. Personally I write true unit tests only for methods that do something quite complex - but I try to make extensive use of XATs, because they test the methods in context. Granted, they are more brittle to changes than Unit Tests, but they are quite easy to update.)

A further tip: I am always quite rigorous about object layout, insisting that, for example, an action method and all its associated methods are placed within a single region:
#region Action: DoSomething

#endregion
This doesn't guaranteed anything, but I find that it is more likely to prompt a developer when renaming an action to remember that that method is part of a set of associated methods.

Finally, there is lots of scope for writing helper utilities in VS. For example, you could write a 'Naked Objects Rename' helper that automatically renamed associated methods. Dan did this many years ago for the original Java version of the framework using the TogetherJ IDE.