Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Feature Requests
 Indentation for class members
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

znakeeye
Tomato Guru

379 Posts

Posted - May 23 2007 :  04:54:48 AM  Show Profile  Reply with Quote
Switching back to VS, I just realized I'm missing a feature in VAX. Most programmers indent member variables in classes in this way:


class X
{
    int              m_int;
    CMyClass         m_class;
    double           m_double;
    CMyExtendedClass m_class2;
};


Similarly, when you declare multiple variables (often seen in class constructors):


void foo()
{
   int x           = 0;
   MyStruct s      = { 0, 0, 0 };
   int longVarName = 0;
}


Hence, would it be possible to add a hotkey for such class member indentation?

Edited by - znakeeye on May 23 2007 06:57:22 AM

RickHodgin
Senior Member

44 Posts

Posted - May 23 2007 :  07:36:39 AM  Show Profile  Reply with Quote
quote:
Hence, would it be possible to add a hotkey for such class member indentation?

I would like to add/suggest two hotkey options allowing various forms of auto-indentation. When I assign variables I do it like this (tab aligned to the next largest tab):

void foo()
{
   int         x           = 0;
   MyStruct    s           = { 0, 0, 0 };
   int         longVarName = 0;
}


If two options were available...:

1) Align variables?
2) Align assignments?

...then all cases of indentation style could be handled by the same hotkey. There might need to possibly be a third option which would specify either a maximum indentation to extend assignments to (and possibly a forth if you always wanted the type to be properly spaced) or simply an option to ignore unusually long variable names (the term unusually applying to relative context, meaning that if one or two variables out of a list are notably longer than the rest, they are considered unusually long):

3) Maximum indentation? or Ignore Unusually Long Variable Names?

This would specify that extremely long variable names are not included in the length determination and wind up being indented like this:

void foo()
{
   int         x   = 0;
   MyStruct    s   = { 0, 0, 0 };
   int         ExtremelyLongVariableName = 0;
   OtherThing  ot  = 5;
}


The ExtremelyLongVariableName, since it's above the threshhold, would just be assgined as above, rather than aligning anything. Just a thought.
Go to Top of Page

znakeeye
Tomato Guru

379 Posts

Posted - May 23 2007 :  1:00:13 PM  Show Profile  Reply with Quote
I agree. Another possibility is to perform the indentation incrementally (the hotkey is Alt+I):


   int x = 0;
   unsigned y = 0;
   unsigned int z = 0;
   int extremelyLongVariableName = 0;
   ExtremelyLongVariableType name = 0;
   previouslyDefinedVariable = 0;

User presses Alt+I:

   int      x = 0;     // OK
   unsigned y = 0;     // OK
   unsigned int z = 0; // Still wrong indentation...
   int      extremelyLongVariableName = 0; // OK
   LongVariableType name = 0; // Wrong...
   previouslyDefinedVariable = 0;

User presses Alt+I a second time:

   int          x = 0;
   unsigned     y = 0;
   unsigned int z = 0;
   int          extremelyLongVariableName = 0;
   LongVariableType name = 0; // Just one more to go...
   previouslyDefinedVariable = 0;

User presses Alt+I a third time:

   int              x = 0;
   unsigned         y = 0;
   unsigned int     z = 0;
   int              extremelyLongVariableName = 0;
   LongVariableType name = 0;
   previouslyDefinedVariable = 0; // Variable name not indented!

With this method, the user can decide when an extremely long variable type has been found, and stop pressing Alt+I. Logically, this means we need another hotkey for the assignments. I suggest Alt+R.

The user presses Alt+R:

   int              x    = 0;
   unsigned         y    = 0;
   unsigned int     z    = 0;
   int              extremelyLongVariableName = 0;
   LongVariableType name = 0;
   previouslyDefinedVariable = 0;

And again...

   int              x        = 0;
   unsigned         y        = 0;
   unsigned int     z        = 0;
   int              extremelyLongVariableName = 0;
   LongVariableType name     = 0;
   previouslyDefinedVariable = 0;

And finally...

   int              x                         = 0;
   unsigned         y                         = 0;
   unsigned int     z                         = 0;
   int              extremelyLongVariableName = 0;
   LongVariableType name                      = 0;
   previouslyDefinedVariable                  = 0;

The question is if it is worth two hotkeys. I think I like your idea of thresholds better. Alt+I twice, and you're done :)
Go to Top of Page

RickHodgin
Senior Member

44 Posts

Posted - May 23 2007 :  1:33:26 PM  Show Profile  Reply with Quote
quote:
I agree. Another possibility is to perform the indentation incrementally:

I like this idea even better!
Go to Top of Page

sl@sh
Tomato Guru

Switzerland
204 Posts

Posted - May 24 2007 :  03:26:33 AM  Show Profile  Reply with Quote
Personally I'm not in favor of alignments based on symbol lengths within a local block of code. Mostly I use this kind of alignment within comments (e.g. function header comments with lists of parameters and what they're for), and there I would like the indentation to be fixed to certain columns over all of the file (all of the project, actually). Whether unusally long typenames or variable names break the indentation locally, or some code blocks have gaps of a dozen spaces or more is mostly not a concern.

That said, I'm sure there's countless people out here who would like yet different indentation styles, and I'm sure it's impossible to make them all, or even just a majority (i.e. > 50%) happy by any kind of solution in the ways suggested above. Any such method would have to be customizable to some degree, or else it would be useless to the majority of users.

We're into formatting here, and as feline often pointed out before, this is just too big a field to dig in (yet). There are lots of tools specifically made for formatting issues like this which probably do a much better job than VA will ever (or at least for a very long time) do.

I'd rather have the VA developers concentrate on removing those few bugs that still exist and putting in additional features that require intelligent parsing of projects (not files, as formatters do), than divert their energy to stuff VA wasn't designed to do in the first place.

Edited by - sl@sh on May 24 2007 03:30:23 AM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19014 Posts

Posted - May 24 2007 :  07:19:33 AM  Show Profile  Reply with Quote
First a personal perspective, what happens when the type is 70 characters long? 90 characters long?

Start making template types like:

std::map< std::string, std::pair<long_structure_name, std::pair<different_long_structure_name, bool> >

and the whole idea of aligning variables goes right out the window. I know this, since a while ago I ended up writing a LOT of code full of types like this. There were very good reasons, before someone suggests I should not have done that.

I like the idea of aligning variables, BUT I personally find this only works if the types and variable names are a similar length, since if there is 40 spaces between a variable type and the variable name I find I cannot scan the code and match the two up.

Which quickly gets me to sl@sh's point, any simple rule is going to irritate more people than it helps.

We are discussing the idea of code formatting internally, but this may not come to anything. Hard coding the formatting rules is not going to work. Provide options for everything... you get a LOT of options.

For now you may want to have a look at GC http://sourceforge.net/projects/gcgreatcode/

zen is the art of being at one with the two'ness
Go to Top of Page

RickHodgin
Senior Member

44 Posts

Posted - May 25 2007 :  07:25:33 AM  Show Profile  Reply with Quote
quote:
...what happens when the type is 70 characters long? 90 characters long?

Truncated, per the operation which ignores unusually long variable names and/or declaration names.

quote:
I know this, since a while ago I ended up writing a LOT of code full of types like this. There were very good reasons, before someone suggests I should not have done that.

Typedefs. I can't think of any "very good reason" to do something like that without typedefs, unless you're using generated code, and then formatting isn't an issue.

quote:
I like the idea of aligning variables, BUT I personally find this only works if the types and variable names are a similar length,

Which is most often.

quote:
since if there is 40 spaces between a variable type and the variable name I find I cannot scan the code and match the two up.

Hence the need for the maximum length.

quote:
Which quickly gets me to sl@sh's point, any simple rule is going to irritate more people than it helps.

I don't think that's what sl@sh said. I think sl@sh's point was that you won't make everyone happy. I don't think it would irritate anyone because 1) they don't have it now 2) they don't have to use it when it's available and 3) it seems very easy to implement as suggested.

quote:
We are discussing the idea of code formatting internally, but this may not come to anything. Hard coding the formatting rules is not going to work. Provide options for everything... you get a LOT of options.

Ever think of opening up that API? This would be an ideally suited use.

quote:
For now you may want to have a look at GC http://sourceforge.net/projects/gcgreatcode/

I think the idea of having this in VAX is to do it on the fly.

- Rick C. Hodgin
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19014 Posts

Posted - May 25 2007 :  2:25:10 PM  Show Profile  Reply with Quote
Unusually long... that sounds like something that would need an option. Add another one to the list of formatting options

typedef's, I hate them when using templates. The reason, the code in question was using the template collection classes from the Qt 3 C++ library. This was because the code had to compile on both Win32 and SCO UNIX. In Qt 3 different collections need to be scanned / accessed differently.

The same applies, to a smaller degree, to the STL classes. Start adding in typedef's and I loose instant knowledge of the collection type, so I know longer know how to manipulate it. Making me dig through 3 different system headers to find out how to scan the datatype that has just been returned via a function does not make me happy *sigh*

Variable types of a similar length, this may be the case in your code, but I have worked in code where this is often not the case. This is one of those things that is going to vary quite a lot from person to person.

An API, this gets us back to the previous discussion about API's, and all of the problems this brings with it.

Formatting on the fly, I know this is very popular, I personally would love to have this done for me, but I am not sure I want to support it The popularity of this feature is the main reason we are discussing the idea internally.

zen is the art of being at one with the two'ness
Go to Top of Page

sl@sh
Tomato Guru

Switzerland
204 Posts

Posted - May 29 2007 :  05:43:37 AM  Show Profile  Reply with Quote
Typedefs: I am not in favor of using those - not because I wouldn't know what they stand for (in most cases there would only be a handful of types that I'd use anyway), but because typedefs increase the need of unneccessarily including headers into headers!

Example:

Foo.h:
class CFoo {
public:
    virtual void doIt();
};
typedef class CFoo * PFoo;

Bar.h:
class CBar {
private:
    PFoo m_foo;
};

Looking at Bar.h above, I would need to #include Foo.h. Had I written
CFoo* m_foo;
instead, a forward declaration of class CFoo would suffice!

Moreover, typedefs are often used to circumvent the need to always type namespaces. However, if a certain type is nested within another class or namespace, one of the reasons this has been done is to avoid cluttering the global namespace. Defining a typedef to circumvent this counteracts this precaution and I'd consider it bad style.

Tools like VA reduce the need for typedefs: type just a few characters and you can easily generate names/types with dozens, or even more than a hundred characters. True, this becomes more difficult if you're dealing with several nested layers of types, but then you're probably better off with just a simple using directive!
Go to Top of Page

znakeeye
Tomato Guru

379 Posts

Posted - Sep 13 2007 :  03:03:59 AM  Show Profile  Reply with Quote
A lightweight solution is to tell VAX to indent class members to a certain column. For instance, at my company we indent class members/functions to column 25. If the type/return value is longer than 25 columns, the member variable/function is put on the next line.


int                m_myInteger;
CMyLongVariableType*
                   m_myLongVariable;

Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19014 Posts

Posted - Sep 13 2007 :  08:56:24 AM  Show Profile  Reply with Quote
That is a light weight solution, but also one I don't think I have ever seen before, so I suspect it would irritate far more of our users than it helped. Which gets me right back to the point about code formatting being a very individual thing.

zen is the art of being at one with the two'ness
Go to Top of Page

hotzenplotz
Senior Member

Austria
34 Posts

Posted - Sep 16 2007 :  6:19:18 PM  Show Profile  Reply with Quote
I used to visually align stuff in source code for a long time. However at some time I came to the conclusion that it's really bad once you start refactoring code.
e.g. when I rename a class/variable/function I really don't want to go to all places where references were changed to visually re-align the code. And if I don't fix the alignment it will be off, which is really ugly IMO.

So now I just don't align them anymore. After a while you get used to it. By now I even find the visually aligned code looks ugly and twisted -- I think it's just a question of what you're used to.

Edited by - hotzenplotz on Sep 16 2007 6:20:46 PM
Go to Top of Page

sl@sh
Tomato Guru

Switzerland
204 Posts

Posted - Sep 17 2007 :  05:44:19 AM  Show Profile  Reply with Quote
I agree. Depending on who's coding, some people even go ahead and align consecutive lines of code that just happen to be 'almost' aligned anyway, e.g. intialization of a set of local variables. However, other members of the developer team might not see the need if they happen to add sth, and in the end you get a partially aligned block of code that looks even worse than not aligning anything at all!

When you're working in a team, the only reliable way to use and maintain certain formatting standards, is using a tool that goes over all the code before committing it to the repository. So it doesn't really matter what formatting anyone applies locally.

Of course, when you're on your own, having the editor (or VAX, in this case) help you formatting stuff just a bit, would be a nice feature. But even then you might be better off just writing a couple of macros. That would have the added advantage of being able to adjust them exactly to your personal needs, instead of relying on a tool's assumptions.

Edited by - sl@sh on Sep 17 2007 05:45:02 AM
Go to Top of Page

znakeeye
Tomato Guru

379 Posts

Posted - Sep 22 2007 :  05:40:20 AM  Show Profile  Reply with Quote
Why not let VAX have a feature called "Automatically align class members/functions at column X". For instance, a common coding style is to place class variables at column 25. If the variable type is too long, the variable is placed on the next line at column 25 (or simply not indented).

Then in my header file:

class X
{
    // CMyClass<space>m_myMember;<enter> yields:
    CMyClass             m_myMember;
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19014 Posts

Posted - Sep 24 2007 :  12:15:06 PM  Show Profile  Reply with Quote
To quote myself from earlier on, as soon as your code uses types like:


std::map< std::string, std::pair<long_structure_name, std::pair<different_long_structure_name, bool> >


most "simple" formatting rules break down. I have used types like this before now.

Personally I do not want the variables wrapped onto the next line, since I feel this makes the code harder to read. This is a personal preference.

Code formatting is a rather complex, and highly personal area. Everyone has their own views and opinions. We are discussing the idea internally, but don't expect any instant fixes.

zen is the art of being at one with the two'ness
Go to Top of Page

graham.reeds
Ketchup Master

United Kingdom
51 Posts

Posted - Sep 26 2007 :  04:09:37 AM  Show Profile  Reply with Quote
Elastic Tabsstops?
Go to Top of Page

znakeeye
Tomato Guru

379 Posts

Posted - Sep 26 2007 :  1:12:25 PM  Show Profile  Reply with Quote
I get your point. I put my variables on the same line too. However, if the typename is shorter than ~20 characters, I put the variable name on column 25.

Those "Elastic Tabstops" seem interesting :)
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19014 Posts

Posted - Sep 26 2007 :  1:52:11 PM  Show Profile  Reply with Quote
An interesting approach, but not one we can use inside VA without reformatting the code to match the indenting every time you make an edit. We don't have full control of the editor, and have to accept where the IDE puts the words on the screen.

I have been exposed to various "formatting rules" over time, and personally I have concluded two things:
* you need to do something (anything) consistently
* there are always going to be exceptions and special cases where the rules don't work well

oh yes, put three programmers in a room, and 4 or more code styles will emerge

zen is the art of being at one with the two'ness
Go to Top of Page

sl@sh
Tomato Guru

Switzerland
204 Posts

Posted - Sep 27 2007 :  03:44:04 AM  Show Profile  Reply with Quote
I like the idea of elastic tabstops, but unless all editors not supporting it will be banned (i. e. uninstalled) from the developer teams' PCs it simply won't work, I'm afraid. The problem being that anyone not using the proper display functions will inevitably mess up the formatting on edit.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19014 Posts

Posted - Sep 27 2007 :  09:54:08 AM  Show Profile  Reply with Quote
Which also extends to any diff programs you use. I can see the list of programs that need to support this growing quite rapidly.

zen is the art of being at one with the two'ness
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000