Author |
Topic |
|
nholthaus
Junior Member
20 Posts |
Posted - Feb 19 2016 : 11:28:35 AM
|
for classes with a lot of methods and/or members, the first (and sometimes best) way to organize them is often simply through alphabetical order.
VA provides a sort function, but running it on a class ends up sorting by return type, which isn't helpful. It would be nice if VA had a similar feature, accessible by the VA menu or the context menu when hovered over a class, to sort the class members/methods, but using the member or method name instead of the type/return type.
Additionally: - if the implementations are in a .cpp, those should be reordered as well to match the declaration order. - So-called 'Group of 5' constructors/destructors should always end up at the top of the sort, in some canonical order determined by you (or settable in a snippet?). - If possible, sort overloads of functions from least inputs -> most inputs (e.g. setValue(int) would come before setValue(int, int) ) - sorting should occur independently for members and methods. - sorting should occur independently for each access level within the class. |
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Feb 19 2016 : 11:53:12 AM
|
This makes sense. Sorting comes up now and then, but surprisingly, I don't recall anyone suggesting sorting an entire class in one go like this, so I have put in a feature request to see what our developers make of this:
case=95167
Thank you for being so thoughtful here, it saves me asking all of these questions, since sorting isn't automatically as simple as it sounds
For now, are you aware you can manually organise / sort your class members by using drag and drop in VA Outline:
http://docs.wholetomato.com/default.asp?W187
For finding a class member, you can tell VA to show the Alt-M list in alphabetical order
http://docs.wholetomato.com/default.asp?W192
not the same, but I find this very helpful when searching a class for a given member / item.
For the group of 5, what options are you considering? My first thought would simply be constructors first, in the order of the number of parameters they take, followed by the destructor. |
zen is the art of being at one with the two'ness |
|
|
nholthaus
Junior Member
20 Posts |
Posted - Feb 19 2016 : 3:09:23 PM
|
My inspiration for this actually comes from the 'encapsulate field' feature, because I always want to group the getters and setters.
For group of 5, I'd think: - constructors in order of number of args - copy constructors in order of args - move constructors in order of args - destructors
My instinct then would be to put assignment operators (copy then move)... it's what I'd do in my classes since they logically go with the constructors. It might be slightly weird (or not) to do the rest of the operators (arithmetic/equality) alphabetically with the methods. Personally I think I'd typically put the rest of the operators after the group of 5 stuff, before user defined methods. I might also separate static/non static methods and members. Maybe those could be check-box options somewhere. |
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Feb 22 2016 : 2:44:21 PM
|
Grouping all of the overloaded operator functions together makes sense, and this is what I would personally expect to see, since they are "of a type". But since they use the word "operator" I would expect sorting them to group them together anyway.
Separating static members and methods makes sense, but also illustrates that this is getting a little complex. I have put a note onto the case about static items. We probably won't want to handle to many complexities here, to keep the feature fairly well defined. |
zen is the art of being at one with the two'ness |
|
|
|
Topic |
|
|
|