In my company, the style guide requires imports, class properties, enumerations, and consecutive variable declarations to be sorted alphabetically. I find this unnecessarily tedious. What are the possible benefits from this practice being enforced?
On imports, it groups similar imports together, and makes it easier to see what is being imported from certain packages. Typically, sorting alphabetically has the side effect that all your local imports are grouped together, all your third party packages are grouped together, and all your standard library imports are grouped together. Specific packages go in the same place, so it's easier to see at a glance if a file uses it or not.
For variable declarations, it makes it just a tiny bit faster to find a declaration in a large list. Remember, you read code far more than you write it.
In vim, I use
:sort to sort lines, and my understanding is most IDEs can do it for you. Also, if you have so many imports that it becomes burdensome to maintain the sorting, that's sort of a sign you might have bad cohesion.
In addition to Karl's answer, there is another benefit that I learned about when playing around with Go: if you make a rule that things can only be done one way, then nobody has to waste time thinking about how to do it.
In the Go community, there is a rule that pull requests are only accepted when they are "idempotent under
gofmt". In other words, PRs must be formatted with
gofmt doesn't take any arguments telling it how to format your code! So, unlike every other well-known source formatting tool, you cannot configure how it is going to format your code.
Ken Thompson wrote that at first, he thought that he would absolutely hate this; after all, he was involved in the creation of several programming languages (B) and operating systems (Unix, Plan 9), and shaped the style of C, and he has very strong opinions. But to his own surprise, he found that these strict rules were very liberating: he just didn't need to think about where to place braces, where to put whitespace, whether to use tabs or spaces, what order to put declarations in, what order to put imports in, and so on. He could focus on writing the code, and
gofmt does the rest.
Another advantage he mentioned, is that when all code looks exactly the same, it is very easy to navigate a third-party codebase, because again, you can focus on the semantics, the control flow, the data flow instead of "why is this brace here and not there?"
And an advantage that I found, is that when all code looks exactly the same, it is very hard to see who wrote it, which makes achieving the lofty goal of collective code ownership easier.
I set up my IDE to automatically format code as I type, following whatever the accepted community style guide is for the language I am writing in. And then I just don't care anymore. It really is liberating and time-saving.
The only advantage of sorting alphabetically is that it can be automated easily by tools. If your team decides that they want to sort a particular list alphabetically, then they should automate that and then forget about it.
The counter-advantage of alphabetical sorting is that it means that you can't encode semantics into the sorting order, as alphabetical order is semantically meaningless order. Any half-assed semantic sorting is usually better at making the code clear than alphabetical order, even if the semantic sorting rule is unclear and inconsistent across the codebase, they're usually still better than alphabetical (as long as it's not intentionally trying to be bad).
There's no point in enforcing the code style of a consistent, semantically meaningless sort order only to then have people manually maintain the sorting.
If you don't have tooling support to automatically sort the list in alphabetical order, then you should instead take advantage of sort order to encode some meaning into it. For example, if you a have a rectangle class, sorting alphabetically means that the code for height() and width() will likely be far apart from each other, even when these are methods are semantically related to each other. With semantic ordering, they should've been close to each other on the code.
Personally, I like sorted imports. There's not much useful meaning you can encode in import statements, and most languages have pretty good tool support for automating that. The list of imports can also get pretty large, so it's handy to have them sorted.
Sorting classes/properties/methods/CSS declarations though, I find to be usually counter productive. There are much more useful groupings/orderings that you can do than alphabetical order.
Sorting variable declaration is usually the wrong question to ask. If your methods had so much variables that you can benefit from sorting their declarations, you've way exceeded the reasonable length limit for a method. Additionally, sorting variable declarations in most languages also usually means that you can't set the value of that variable inline. In almost any code you'd want to assign variables in a certain order because the algorithm/logic requires the variables in that order. You can't just nilly willy reorder variables without changing the code. Having rules about sorting these declarations alphabetically means that you'll be forced to have separate declaration and assignments, which is also a style guide that only makes sense if your methods are way bigger than they should be.
Two more reasons not explicitly mentioned above so far: Duplicate imports as well as code merges.
I've been in files in which the same import has shown up two, three, or maybe even more times perhaps due to carelessness or due to merges.
Speaking of merges, we had spent time during merging to go through merge conflicts in the imports as well. With alphabetized sorting automatically required, I haven't come across any merge conflicts at all since git has taken care of it automatically.
Note that I'm only referring to imports here although the original question asked about other constructs as well. I can see the same benefits for a long list of enum values too.
In addition to the other benefits: Alphabetically sorted imports make it easier to look if the right module is imported.
In Java Spring there is an annotation
@Component. Some weeks ago I simply typed the name of this annotation and pressed a key shortcut to add the import. There were 3 annotations (!) with this name in different packages and 3rd-party-libraries. Unfortunately I choosed the wrong one and the code doesn't work.
Because the imports were sorted and grouped it was easy to see what went wrong. Assume they were not: how long would it has taken to find the mistake?
While sorting imports, class properties, enumerations or consecutive variable declarations alphabetically may seem a bit tedious, there are significant benefits, especially as the code base grows and evolves.
One advantage is the ease of performing search and replace operations. Consider a scenario where you need to add a new field to multiple similar interfaces or types. If the sort order is enforced, you can use a regular expression replace with confidence, knowing the order of the fields. Without an enforced sort order, constructing a complex regular expression becomes more challenging. Even if you're making changes manually, having an ordered list makes it easier to locate specific fields, especially when dealing with a larger number of them.
Sorting also makes comparing similar interfaces or types easier. If you have two structures that you want to compare, using a diff tool is more effective when the fields are sorted. While it's possible to sort the fields at the time of comparison, this adds an extra step and it becomes more complicated if there are comments or other non-field elements, making a simple line sort impractical.
While your current interface may be small and unlikely to expand significantly, it's important to consider the future. Larger projects often bring unforeseen requirements that can introduce new elements and complexity. By sticking to consistent principles such as alphabetical sorting, you ensure scalability and maintainability as the code evolves. Additionally, maintaining a standard practice across projects can foster code consistency and make it easier for other developers to navigate and understand.
Don’t overdo it. I’ve seen documentation that treated getters/setters as methods, so the letter G was two dozen getters and one or two other methods, and the letter S was two dozen setters - very hard to find which properties were read-only because you had to compare the lists.
Swift has a feature that turns source code into what header files would be if it had header files, so private items are gone, code is gone, non-documentation comments are gone. Since this requires hard work, optionally sorting things any way you like would be possible.