| Author |
 Topic  |
|
|
sl@sh
Tomato Guru
Switzerland
204 Posts |
 Posted - Oct 20 2006 : 08:19:41 AM
|
Hello everyone, I'm new to this forum.
(ok, that should do  )
I was experimenting with Refactoring and Autotext but couldn't find a ways to add some generic tracing code to my methods. What I was thinking of is a TRACE macro using a string that contains the method's parameter list and qualifier to better be able to differentiate the functions listed in my call stack. Unfortunately the __FUNCTION__ macro does not list the method argument types or method qualifier, so is bound to be unhelpful with classes that make heavy use of overloading.
What I'd need would be a refactor method invoked from the method symbol that inserts some context dependent autotext right behind the opening bracket of the function body.
For instance the refactor autotext would look like this:
_TRACE_ENTER(__FUNCTION__, "$ParameterList$", "$MethodQualifier$");
When applied to a method looking like this:
int foo (char* somestring) const
{
// ...
}
applying the refactor method would then result in this:
int foo (char* somestring) const
{
_TRACE_ENTER(__FUNCTION__, "char*", "const");
// ...
}
Would it be possible to add such a feature? (And while you're at it, could you add a similar method to add generic code/autotext to the end of a function body?  ) Or is it already possible in some way?
On a sidenote, I wondered whether it would be helpful to define various different autotext entries for the same refactoring method. This would probably require some thought regarding usage, but I could imagine some people would want i. e. different documentation styles for different projects, or different kind of functions. |
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Oct 20 2006 : 09:33:39 AM
|
using VS2003 and VA 1539 I simply changed the autotext rule for "Refactor Create Implementation" to read:
$SymbolType$ $SymbolContext$( $ParameterList$ ) $MethodQualifier$
{
_TRACE_ENTER(__FUNCTION__, "$ParameterList$", "$MethodQualifier$");
$end$$MethodBody$
}
which seems to do exactly what you want, when calling Create Implementation 
the quickest and easiest solution here would be to extend "Refactor Document Method", perhaps to:
//************************************
// Method: $SymbolName$
// FullName: $SymbolContext$
// Access: $SymbolVirtual$$SymbolPrivileges$$SymbolStatic$
// Returns: $SymbolType$
// Qualifier: $MethodQualifier$
// Parameter: $MethodArg$
//************************************
/*
_TRACE_ENTER(__FUNCTION__, "$ParameterList$", "$MethodQualifier$");
_TRACE_LEAVE(__FUNCTION__, "$ParameterList$", "$MethodQualifier$");
*/
it is then simple to cut / paste the two trace lines, and place when where you want them.
adding code at the start / end of the function body is not that easy. one reason is that VA is designed to help as you are coding, and while coding most of the time the code does not compile, so we cannot assume "well structured" code. plus you get nasty edge cases where people have used macro's to redefine the start or end of functions, plus the effects of different styles of code indenting and layout, not to mention one line (inline) functions
for now we don't want to add "overloaded" autotext rules for refactoring, because as soon as we do that we have to stop and ask the user questions. the whole design of VA's refactoring operations is to be as non intrusive as possible. lots of small operations that can then be chained together in the specific manor each individual person wants, rather than a 14 step wizard that tries to cover all possible options |
zen is the art of being at one with the two'ness |
 |
|
|
sl@sh
Tomato Guru
Switzerland
204 Posts |
Posted - Oct 23 2006 : 04:50:20 AM
|
Thanks for the answer. The first would work well only on code not implemented yet, as for methods with existing implementations I would also need to copy the created body to the right location and delete the original. Also Refactor Create Implementation only works from definitions, not implementations. So if I want to add tracing code to large modules of already implemented classes I would have to switch between header and implementation files all the time.
The second should work reasonably well though, especially in combination with a macro that does the copying for me. Thanks for the suggestion, I should've thought of that myself.
As for overloading autotext - I guess you're right, I really didn't want MS Office 'features' *cough* with VA...
Still - I would like the ability to define autotext entries that contain symbols referring to the method's context, just like Refactor. So if you type the appropriate shortcut you get to replace it with some autotext that includes things like the name or parameters of the method you're currently in. Overloading would not be a problem then, since it's the user who defines the autotext entries and appropriate individual shortcuts. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Oct 23 2006 : 12:58:42 PM
|
Certainly an interesting idea. The current refactoring autotext rules are only triggered under fairly specific and well defined conditions, when the tokens can be expanded sensibly. Allowing them to be used in any position means that some times the tokens will not have any value. Still, this should not be an insurmountable problem, so I have put in a request to see what the developers make of this.
case=3204 |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
|
|
Refactoring: adding code related to method
