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?