| Author |
 Topic  |
|
|
rwomack
Junior Member
United Kingdom
15 Posts |
 Posted - Dec 03 2006 : 2:01:54 PM
|
| If I rename a parameter to a method in the c++ file, the decalration in the header file is not renamed, unlike if I rename the method. |
Thanks,
Roger |
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Dec 04 2006 : 08:41:48 AM
|
for now use Change Signature to rename the parameter, this will update both the header file and the .cpp file.
case=1140 |
zen is the art of being at one with the two'ness |
 |
|
|
rwomack
Junior Member
United Kingdom
15 Posts |
Posted - Dec 06 2006 : 1:44:35 PM
|
That works, but there are 2 annoying effects :-
1. It adds a space after the opening bracket and one before the bracket in the .cpp file
2. In the .h file it removes existing formatting.
I would really prefer it to preserve my formatting.
Thanks |
Thanks,
Roger |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Dec 07 2006 : 10:52:46 AM
|
For point 1 edit the autotext entry "Refactor Create Implementation" to have the formatting you want.
For point 2 there are a couple of cases open about formatting changes. How was the line formatted before you ran Change Signature? And how was it formatted afterwards? |
zen is the art of being at one with the two'ness |
|
|
|
rwomack
Junior Member
United Kingdom
15 Posts |
Posted - Dec 07 2006 : 1:35:50 PM
|
Thanks, point 1 now sorted.
Point 2, I align my declarations in the .h file so that the function return type commences in column 5, and the function name commences in column 29 (padded with multiple tabs) these tabs are lost during the changing of the signature, ie only 1 tab is placed between the return type and the function name.
|
Thanks,
Roger |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Dec 08 2006 : 1:08:02 PM
|
I see the problem, but I am not sure about the best solution. It is easy to say "don't change the formatting", but Change Signature allows you to change the return type, and many other things, which will break the formatting you are using.
Have you considered using a dedicated code formatting program? One free and often suggested program is:
http://sourceforge.net/projects/gcgreatcode/ |
zen is the art of being at one with the two'ness |
|
|
|
WalderMort
New Member
7 Posts |
Posted - Dec 08 2006 : 2:20:24 PM
|
I think it would be more convenient if there was a configuration file for things like formatting. I'm thinking of something like an ini file where we can override items like indentation of the header file. I like to format my headers in such a way that return type, function name and function paramaters are all aligned to an overall column. Currently VAX does not do this and I have to go back to the header and do it manualy.
I would also like to see the coloring of hard coded numerals in future releases ( especialy for hex values ). |
|
|
|
rwomack
Junior Member
United Kingdom
15 Posts |
Posted - Dec 08 2006 : 2:51:25 PM
|
That's exactly what we need. |
Thanks,
Roger |
|
|
|
rwomack
Junior Member
United Kingdom
15 Posts |
Posted - Dec 08 2006 : 2:53:45 PM
|
| And another thing, could user changed autotext items be stored in seperate file and be loaded in after the standard autotext so that user defined autotext is not lost when a new version is released. |
Thanks,
Roger |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
|
|
rwomack
Junior Member
United Kingdom
15 Posts |
Posted - Jan 08 2007 : 6:14:31 PM
|
| I have discovered further information for point 2, what VA is doing is translating tab characters into single spaces and doesnt alow me to enter tabs |
Thanks,
Roger |
|
|
|
sl@sh
Tomato Guru
Switzerland
204 Posts |
Posted - Jan 09 2007 : 03:47:08 AM
|
As an aside:
In my experience tabs are causing formatting problems all by themselves, especially when seperate teams are working on the same project, or some people working on the project use different tools. All of these can usuallly be fixed with the right settings and project guidelines and if all project members adhere to the standards set for the project, but most often the easiest way is to avoid tabs at all and use spaces instead. Most editors nowadays allow replacing tabs with the appropriate amount of spaces when saving, so there is no overhead in typing either.
I myself would greatly appreciate if all tools out there would deal with tabs formatting correctly, but unfortunately that is not the case, so I decided to not use them. In exchange for just a little extra effort (usually finding the right settings for your editor does the trick) I'll never run into formatting problems.
That said, the problem VAX has here isn't so much the formatting in itself, but it's lack of formatting information in the face of all kinds of changes it has to perform. While it would probably be possible for VA to determine just how many spaces make up one tab, what the tab stop positions are (some editors might independently define those), and what the column starts for each part of the declaration originally were, it doesn't even know what the formatting is based on or if *any* kind of standard formatting is being used at all and it is actually expected to keep some kind of formatting standard that in fact isn't there in the first place. Moreover, the original code might not even adhere to the formatting standard you would like - after all you might be working on code that is under heavy development at the moment.
If a function declaration starts at column 9 with the return type, and the type name is 19 characters long, then the function name starts at 29, what then is VAX to do with this? If the signature change involves adding "virtual", should it be placed at column 9 or at column 1? If the changed type's name is longer than 19 characters where then should it place the new function name? If the new type's name is shorter, should VAX place the function name right behind it or stick with column 29?
In many cases answers to all of these questions might be guessed, but in some cases it's simply impossible to *know* what the user really wants. And since VAX really isn't a formatting tool I'd never expect it to keep a certain style of formatting when what I'm doing is *not* calling a formatting, but a refactoring function. Whenever the refactoring changes a symbol not to the utmost right of a line it *will* definitely mangle up formatting for *someone*. The only way to avoid this would be a clear and unambiguous formatting description independent of the existing code, and that is definitely beyond the scope of VA. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Jan 09 2007 : 10:50:35 AM
|
sl@sh this is a very good explanation of why we just don't want to touch formatting. Have a look at a proper code formatting tool, and see just how many options it requires, and then see if you can make it format your code the way you want 
I have looked at a couple over the years, and found they did not really want to format to the "official standards" that I was supposed to be using.
quote:
Originally posted by rwomack
I have discovered further information for point 2, what VA is doing is translating tab characters into single spaces and doesnt alow me to enter tabs
to reply to this, imagine the line of code looks like this:
const int & testFunctionToShowThings
(
int parameter1,
const char * parameter2,
unsigned long parameter3
)
const
that is not going to fit into the dialog we show, since it only has a single line edit field. So we compress white space, so that you get something you can reasonably edit in a simple dialog. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
1541 renaming c++ method parameters
