Automatic sorting of class/module members and its possible impact on productivity and code quality

Question

Recently I saw some possibilities of some IDEs (via plugins) to sort members of their classes/modules based on some criteria, sou you could have everything sorted automaticaly no matter where you would put the elements in time of writing it to editor.

Do you think that this kind of sorting in class/module may have positive impacts on productivity, readability, comprehensibility etc?

Answer 1

I find it funny that everybody seems to immediately say "No" to having the IDE automatically sort the members of a class. Working in C# quite a bit and abiding by StyleCop's default rules, I personally find it nice to have consistency in my code to have all fields, constructors, properties, and methods grouped together and within each group it's sorted by scope (public, protected, protected internal, private). Back before development stopped on it I made use of Regionerate to automatically group the code for me and make sure the members were in alphabetical order. I really wish my current team would view the benefits of this because for a number of base classes that we all have to modify (sometimes at the same time) having the tools to consistently structure where new members are placed would make merging a ton easier.

Answer 2

I do not think it would have a positive impact. We tend to group class members according to their purpose and function, and this is something that cannot be communicated by means of any simple criteria: it requires an understanding of what these things actually do.

For example, in hand-written code, a public method which manipulates some kind of elements and contains a call to a standard library routine to sort said elements might be immediately followed by the private callback method which compares said elements, so that the programmer can regard the two methods as a whole, since they work very closely together. I do not see any kind of criteria that could be used by an automated tool to figure out that these two methods should be grouped together.

Answer 3

No, it will not have a positive impact in kind of class I develop or have seen. I cant think of any criterion that can be used to group class elements. Self assumption from tool will mostly be bad assumption.

Answer 4

A lot of people organize themselves spatially. If the IDE is moving things around on you to enforce alphabetical order of member names, it will be disconcerting to a lot of people. Also, many IDEs provide direct access to the members of a class through a drop down list, which is sorted alphabetically. This ought to be enough to help people who need to scan for a class member.

Answer 5

I use a template that creates what you might called "structured comments" when I start a file, this provides a section (analogous to the C# #regions) for each classification of member, so the breakdown is like

internal members
  internal static members
  internal constant members
private members
  //etc
protected members
  //etc
public members
  //etc

then repeat above with properties

then the constructors

then repeat above with

commands:pub,prt,pvt (fns that return void)
event handlers
functions:pub,prt,pvt

end of class

This forces you to think of and remember the role a member has, before and after its creation. As development proceeds, I generally put new functions at the bottom of the proper section until they mature, then migrate them to a position in the section that is dependency or functionally based.

Once you have that in place, make some macros so you can quickly jump to the end of a section, I use a popup menu -

internal,public,protected,private |[static,const] |members,properties,ctors,commands,functions

so the keystrokes are alt-q, (popup), 1,3,2 -- to take me to internal const properties

(sorry about the lingo, a const property is simply one with no setter)

To add to this, I create an expansion macro that will popup a dialog asking for name, params and retval -- then it creates the stub according to the section you are in.

I have found that this type of boundary grouping works best, compared to clusters of members or some other scheme -- it forces you to think about architecture.

Here is a snippet of what it looks like in real life

//#+, public    members
  //;
  //#+*, public static     members
    // ReSharper disable UnaccessedField.Local
    // ReSharper disable InconsistentNaming
     /// <summary>
     /// Public Static Members
     /// </summary>
    private static object __UtilsWin32_public_static_members;
    // ReSharper restore InconsistentNaming
    // ReSharper restore UnaccessedField.Local
    #region "public_static_members"
    // Z_DOT typedef EnumWindowsProc(int hwnd_, int lparam_):bool ::UtilsWin32::UtilsCL:UtilsWin32.cs  z.1711900400436177.2009.05.18.07.08.11|+*,
       /// <summary>
       /// Delegate for EnumWindowsProc
       /// </summary>
       /// <param name="hwnd_">The window</param>
       /// <param name="lparam_">The lparam</param>
       /// <returns><c>true</c> to keep enumerating</returns>
      public delegate bool EnumWindowsProc(int hwnd_, int lparam_);
    // Z_DOT typedef EnumWindowsProcIntPtrIntPtr(IntPtr hwnd_, IntPtr lparam_):int ::UtilsWin32::UtilsCL:UtilsWin32.cs  z.3908448500234277.2011.06.16.12.14.08|+*,
       /// <summary>
       /// Delegate for EnumWindowsProcIntPtrIntPtr
       /// </summary>
       /// <param name="hwnd_">The window</param>
       /// <param name="lparam_">The lparam</param>
       /// <returns><c>true</c> to keep enumerating</returns>
      public delegate int EnumWindowsProcIntPtrIntPtr(IntPtr hwnd_, IntPtr lparam_);
    //;
    #endregion
    //#+*@, public static const members
      //;
  //#+@, public const     members
    //;
  //;
//#%, protected    members
  //;
  //#%*, protected static     members
    //;
    //#%*@, protected static const members
      //;
  //#%@, protected const     members
    //;
  //;

The //; is the expansion macro point mentioned above.