| T O P I C R E V I E W |
| tom_seddon |
Posted - Oct 14 2009 : 09:57:00 AM
It would be useful if the parameter list suggestion that you get when typing a function definition didn't (or, at least, could optionally not) include the default arguments. This is mainly because they are added in using /*...*/, which is annoying as it makes it hard to reliably comment out large blocks of code using /*...*/. (I feel that tools should never introduce block comments, for this reason.)
I don't mind continuing to carefully remove them every time this happens, but it's a bit annoying. |
| 12 L A T E S T R E P L I E S (Newest First) |
| sean |
Posted - Jun 26 2014 : 01:50:35 AM
case=3495 is implemented in build 2042 (see Refactoring page of VA Options dialog). |
| feline |
Posted - Oct 22 2009 : 09:36:48 AM
My mistake, I was not as clear as I should have been. The time spent with GC was at my old job, when I was trying to make it format code according to the companies code standards, and even after quite a lot of time I did not manage to achieve the desired result. This was quite worrying, when you consider just how MANY options GC has for code formatting.
Code formatting is one of those things that people thing is simple, but everyone who wants it seems to want their code formatted differently, and normally with a very high degree of control over "minor" spacing and formatting. This is going to require a LOT of options, and a lot of code to do this, all of which has to work without getting in the way of or breaking anything else.
It may happen one day, but not right now. Our current focus is on getting support for VS2010 up and running properly, since this is something we need to address and cannot ignore. |
| drac |
Posted - Oct 21 2009 : 12:57:03 PM
quote:
Originally posted by feline
This is very optimistic on your part. I once spent quite a lot of time looking into GC
http://sourceforge.net/projects/gcgreatcode/
Remember you also need to deal with Tabs vs Spaces, different tab indents, macro's, invalid code, etc. The more you think about code formatting the harder it gets.
It would be a good idea to have that time invested and not spent. You already did the research, there is a starting point why not just continue?
Write down all the enumerated things to know the requirements and start hacking the code. 
Because it's not easy that's why VA should have it! |
| feline |
Posted - Oct 21 2009 : 10:31:58 AM
This is very optimistic on your part. I once spent quite a lot of time looking into GC
http://sourceforge.net/projects/gcgreatcode/
trying to make it do exactly what I wanted. It has a LOT of options, so it would take a lot more than 2 days just to define how all of the different options would interact, and outline one test per combination of options. After all, the code does have to be tested before it is released.
Remember you also need to deal with Tabs vs Spaces, different tab indents, macro's, invalid code, etc. The more you think about code formatting the harder it gets. |
| znakeeye |
Posted - Oct 21 2009 : 04:36:37 AM
It surprises me that you don't want to get into code-formatting. With an AST of the source code (which I assume you have), it's like two days of coding - INCLUDING a lot of styling-options. |
| feline |
Posted - Oct 20 2009 : 12:08:07 PM
znakeeye details of white space formatting, some of this you can change by editing the VA refactoring snippets. Some of it... to provide "total" control would require a LARGE number of formatting options, and get us heavily into code formatting, which is not something we want to do right now.
Plus this is the implementation, removing the comment block leaves you with invalid code, the default parameter can only be specified on the declaration.
andre.horst this would probably be done as a VA option, and not via the refactoring snippet, since changing the snippet would not help the case where you type the function name manually, and accept the parameter portion via a tooltip.
Making the declaration multi line like this just invites extra problems with Change Signature and other refactoring commands, since multi-line declarations open up a whole pile of edge cases, and thats before you start looking at code formatting. |
| andre.horst |
Posted - Oct 20 2009 : 05:24:45 AM
What about a snippet for this?
$SymbolType$ $SymbolContext$( $ParameterListWithOutcommentedArgs$ ) $MethodQualifier$
{
$end$$MethodBody$
}
And of course there could be two different out-commenting refactorings.
void foo( int i /* = 10 */ )
{}
or
void foo( int i1 // = 10
int i2 // = 20
)
{
}
{}
|
| znakeeye |
Posted - Oct 20 2009 : 03:53:01 AM
Personally, I find it annoying that a leading and trailing space is added to the comment.
foo(int x /* = 0 */){}
I don't like it. If I remove the comment there are two spaces there, which is bad styling.
Actually, the "misuse" of spaces is one of the reasons I don't use VAX refactoring. |
| feline |
Posted - Oct 19 2009 : 3:37:02 PM
The idea of case=3495 is that you can tell VA to never add the defaults to the implementations, even when using refactoring commands to generate the implementations.
Another option is to wrap the code to comment out in #if 0, #endif. I know this is another work around, but you might find the idea helpful. |
| Luke1410 |
Posted - Oct 19 2009 : 11:01:45 AM
We'd also like to be able to set VAX not to include default parameter comments at all when using the rafactoring methods as originally requested by Tom.
Even though the planned case 3495 would improve the situation, it doesn't really help with the case where we add manually /* and */ (which for us is a much more likely scenario, since we could already use VAX //-comment feature, if we wanted to use VAX to comment out code blocks).
|
| feline |
Posted - Oct 15 2009 : 12:45:34 PM
We are considering adding an option to control this:
case=3495
For now, take this simple C++ code:
void simpleWithDefaults(int nParam1 /* = 2 */, int nParam2 /* = 3 */)
{ }
Select these two lines and press * to tell VA to surround them with a block comment, and you get:
/*
void simpleWithDefaults(int nParam1 / * = 2 * /, int nParam2 / * = 3 * /)
{ }
*/
Note that the block comments for the parameters have been "fixed" so they do not break the wrapper block comment. If you later on select the comment block and press * to uncomment it VA will return the comments on the parameters to their correct form. |
| khb |
Posted - Oct 15 2009 : 10:11:23 AM
I like that behavior. So when it is going to be modified then please do it by option so that I can keep the current behavior.
Regards
Marcus |
