| Author |
 Topic  |
|
|
Mordachai
Tomato Guru
USA
224 Posts |
 Posted - Oct 14 2011 : 5:57:08 PM
|
I would like it when I move ctors to the .cpp file to have the following format:
Class:Class(args1, arg2)
<indent>: member1(arg1)
<indent>, member2(arg2)
{
<indent>body1
<indent>body2
<indent>body3
}
Currently, VA puts the member initialization list immediately following the ctor arg list - which is an old, outdated stylistic choice. |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Oct 14 2011 : 10:27:42 PM
|
The solution is either to keep the multi-line formatting you use or to make VA use multiple lines via a new keyword in the snippet for this refactoring or something like this:
case=1631 |
 |
|
|
Mordachai
Tomato Guru
USA
224 Posts |
Posted - Oct 17 2011 : 09:29:45 AM
|
Is that a reference to another thread, or how can I look up your solution? I'm not aware of the new keyword to which you refer?
And as always, VAX rocks. :)
Edit: http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=6993&SearchTerms=case=1631
Is this what you're referring to? Reading it now...
...read it, but I don't see the new keyword. Just a discussion of various issues? |
Edited by - Mordachai on Oct 17 2011 10:32:28 AM |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Oct 17 2011 : 6:02:38 PM
|
Sorry, I might have been too concise.
More on cases: http://docs.wholetomato.com?W318
case=1631 is generally about the problem that VA "collapses" multi-line declarations when using Change Signature, Move Implementation to Source Files or Create Implementation. It affects multi-line parameter lists and multi-line initializer lists.
This is an open case and we yet to be decided how to improve this behavior when we get to this case. Basically 2 way of dealing with this problem seems to be sensible:
1. You keep the original formatting.
If you like the formatting that you have presented in the initial post, chances that you already use this form before you use a command like Move Implementation to Source, are high 
2. Improve formatting capabilities
Nothing concrete have been decided here, either. The basic idea is to provide more tool to format your snippet, e.g. via introducing a new keyword which tells VA to use a multi-line form instead of single-line form. The formatting options will be somewhat limited with this approach, though. We don't want to get into the realm of code formatting which would require a lots of options to be able to customize virtually anything. But the more choices the better I think.
These are just ideas, nothing is set in stone yet. I had added a comment about you would like to see multi-line initializers and wrote some though about that, basically the ones I have elaborated here. The case is forming now and the sole purpose of case=1631 is to avoid the collapse behavior in some way.
Naturally, point 1. is a more passive approach, point 2. is a more active one, both have its advantages and disadvantages, and a 3. approach may be the final one. |
Edited by - accord on Oct 17 2011 6:18:02 PM |
|
|
|
Mordachai
Tomato Guru
USA
224 Posts |
Posted - Oct 18 2011 : 09:40:08 AM
|
I know that there will always be customers who insist that you support every possible option. I suppose I might even fall into that category asking that multiline be supported.
However, I wouldn't expect VA to support arbitrary formatting, just ones that are very easy to do machine intelligence for.
e.g. - what you have now - "collapsed", and what I'm proposing "one-per-line."
I know that there are folks who have some algorithm in their head (if it's a long name, then by itself or with one short, if short, then two other shorts, or one short + one medium...) - but for anything that complex, the very best VA can hope for is preserving their formatting, which seems to me to be a separate issue or separate approach.
The problem with "keep their formatting" is it complicates things for all of the commands which modify a function signature.
I'd rather have a very few, targeted style options (that help the formatter decide how to output refactoring) than a whole slew of complex twiddly options or even what-would-inevitably-be a tweeky attempt to maintain my formatting (which VA won't understand, so would get wrong).
But then I'm sure everyone could make the claim "what it does now + the one style I favor". ;)
Just my 2c.
Cheers |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Oct 18 2011 : 4:26:12 PM
|
Very unsentimental (not idealistic) approach.
When I talked about "keep formatting" I thought about a very simple thing: keeping new lines when copying initializer list or something like this. |
|
|
| |
Topic |
|
Move impl to source
