Class Member Organization

Question

What is the best way to sort class members?

I am in conflict with a team member about this. He suggests that we should sort the members alphabetically. I think it’s better to organize in a semantic way: important attributes first, related methods, etc.

What do you think?

Answer 1

I like semantics. Apparently, I have nothing to interpret in alphabetical terms, because when you look for a member, you rarely know exactly what it called. Also, if you use any kind of naming convention (e.g. Hungarian), you can alphabetically group by type, which may not be what you want.

Answer 2

Group-related class members together. I think this will help other programmers more easily understand your interface when they first see it.

Some also find it useful to organize accessors and modifiers together in separate sections.

Answer 3

I studied this exact question as part of my master's thesis.

An alphabetic or public / private organization is better for finding specific things. However, in some IDEs, you can configure the outline tool to sort alphabetically and to use special indicators for public / private.

My approach was to group methods based on which members they use: there is often a conceptual relationship between methods that use the same fields.

I actually created a visualization that helped me quickly navigate and understand the structure of huge classes.

Answer 4

This is just my opinion, which, I am sure, will be unpopular, but the problem with semantic sorting is its subjective. Each person will have a different opinion about which methods should be close.

Alphabetic has the advantage of being completely objective. It also reduces large differences with small changes, which is typical when one encoder chooses a different semantic order.

Most IDEs have outlines or hyperlinks to facilitate navigation.

EDIT: Clarification: I still sort publicly at first on a personal, but in alphabetical order at the same access level. Actually, I am not involved in sorting - I allow my IDE to attach a file for me when saving.

Answer 5

I never look for a member while looking at the code. When I want to go to the definition of a member, I either select it from the navigation / description panel of the document / class, or I right-click and select "Go to definition". You do not need to sort the participants if you have a decent IDE. This works very well in Visual Studio, and another environment that I use when necessary, KDevelop, supports at least the basics of this.

In any case, I tend to group members by functionality, i.e. All fields / properties / methods that are part of a particular functionality are combined. And since classes should not be too long, that’s enough.

Answer 6

Do you write a phone book?

With a semantic approach, you can easily show what are the most important methods. Usually I use Constructor, Destructor, and then important methods, followed by getters and setters, and ultimately different. methods. Finally, I use a similar approach for internal parts (private methods, attributes ...).

The alphabetical order does not convey any useful information about your class. If you really want the methods to be sorted alphabetically, you should rely on the function of your IDE.

Answer 7

You can move from semantic to alphabet by sorting “display methods” in your IDE.

You cannot switch (automatically) from alphabetical to semantic.

Hence: semantic.

Answer 8

Assuming you are using a modern IDE, finding the method you want is rarely more than two clicks away, so I'm not sure if you managed to organize a specific way to organize your methods. I use stylecop ( http://code.msdn.microsoft.com/sourceanalysis ), which orders me using public / private / method / properties - I found that it is quite anal.

The only time I ever thought that this was important was when I wrote a very large jscript program, and the editor at that time did not offer any help in finding functions. Alphabetical organization was very helpful. With alphabetization, it is easy to figure out which path in the file you need to find in order to find the method. A semantic organization would be completely useless.

Answer 9

At a higher level, I would organize my class as follows:

• Constructor
• Destructor
• Private fields
• The properties
• Methods / Functions

Then for methods / functions, I would again break the functionality. For example, I would put the methods that implement the interface in one region, I would put the methods of event handlers in one region, etc.

Rwendi

Answer 10

I think I'm one of the random cases that prefer alphabetical lists.

First of all, my experience was that grouping methods together “semantically” tend to be temporary. Now, if we are talking about grouping them by volume / visibility, this is another thing. But then, if a member changes its scope, you must fork out to move the member to save the current code. I don’t want to waste time shuffling the code to watch this.

I am also not a big fan of the regions. When properties and methods are grouped by volume, they tend to scream out for an application in a region. But attached code in collapsing regions tends to hide poorly written code. As long as you don’t need to look at it, you don’t have to worry about how to reorganize it to make it supported.

So, I prefer alphabetical organization. It is simple, direct and accurate. I have no temptation to attach groups to the regions. And since the IDE makes it easy to move on to defining a function or property, the physical layout of the code is controversial. It used to be that you wanted people to focus on your public members first. Modern IDEs make this a largely pointless argument in favor of area-based layouts.

But the biggest advantage in an alphabetical layout is this: printed code samples during code reviews. And I use a lot of them. This allows you to quickly find a function or property. If you've ever had to wade through a lot of code to find a function or property when things weren't just in alphabetical order, you'll find out what I'm talking about.

But, as they say, these are my subjective views on this topic. Your mileage may vary.