1

I'm currently working with a group of developers (as outside contractors) on an existing codebase (in kotlin) and the lead dev (the client) is blocking merging of pull requests (GitHub) because methods and variables in any given Kotlin class are not "alphabetized".

Only some of the classes are currently alphabetized in this manner but the majority of the existing code is not and there are far more egregious problems with the codebase that I would think should be the focus of any refactoring effort.

I've been writing software for quite some time in a variety of languages, platforms and version control systems and have never had anyone reviewing my code flag it for not being alphabetized. Has anyone in this community ever heard of such a thing?

The response I get from the lead dev is that it helps with readability. I have found many problems with this codebase and I can tell you that looking at code that has been alphabetized has not helped my comprehension especially when some of the classes are more than 2k lines long.

2
  • Tell them that their problem is that they need to have them sorted in the first place. It's not something that's helping readability, it's a symptom of much more serious issues, and that if you are to do the job you were contracted for, you are going to end up dismantling a lot of their preexisting structure anyway. Commented Oct 24, 2022 at 20:28
  • I'm a bit confused by why this question can be deemed opinion-based. I'm asking about their professional coding experiences. I'm asking about coding conventions and whether anyone feels a particular coding requirement is, well, conventional.
    – Gail
    Commented Oct 25, 2022 at 14:34

4 Answers 4

7

Sorting method definitions by alphabet is definitely unusual, and I can't see it helping readability in any way - professional code bases should be handled with IDEs that make the findability of definitions irrelevant because you can look them up with a single keypress.

On the other hand, if you do get this requirement by a senior, you're almost certainly not going to argue them out of it. Since it is easy to find and integrate a filter which automatically re-sorts your code before submitting, simply do that and concentrate on the more important issues.

3
  • As someone who insists on alphabetising - it isn't so much to help you find the function as it is to reduce merge conflicts. If everyone orders the file the same then conflicts only occur when the same thing really has been edited. That said, you set up a linter tool to reformat the file once and then never worry about it again.
    – Sean Reid
    Commented Oct 24, 2022 at 13:16
  • @SeanReid Good point about the merging, I only thought about readability. Commented Oct 24, 2022 at 13:19
  • 7
    @SeanReid: this argument does not convince me. When someone refactors code to smaller functions (which is the most frequent refactoring), in an alphabetized code base these new functions will be scattered all over the code file. In a logically top-down ordered code base, the new functions will occur directly below the function where they were extracted from, in one block. So I don't see how alphabetizing will reduce merge conflicts compared to a logically ordered code base, quite the opposite.
    – Doc Brown
    Commented Oct 24, 2022 at 13:41
6

There are some standard coding conventions for Kotlin, directly provided by JetBrains. They recommend this:

Do not sort the method declarations alphabetically or by visibility, and do not separate regular methods from extension methods. Instead, put related stuff together, so that someone reading the class from top to bottom can follow the logic of what's happening. Choose an order (either higher-level stuff first, or vice versa) and stick to it.

Of course, your team is in no way obligated to follow these rules, but if you are going to exchange Kotlin code with other teams, or reuse some open-source code, expect them to follow the former recommendation. And if you do, too, that will typically reduce the friction.

1

Alphabetized members is one of several potential code organization strategies. They are generally aimed at making it easier to navigate within files predictably, which is particularly helpful with lightweight IDEs. This may not help every developer but it will help some.

I do like alphabetized files personally but I would expect some sort of code guideline or working agreement to codify such a preference. Without a codified approach, there is unpredictability and potential lack of consensus. What if the next reviewer prefers a different organization style?

As far as existing code, it’s a reasonable strategy to require new or updated code to meet stricter guidelines knowing that existing code doesn’t (yet!) meet them.

0

Credo (a static code analysis tool for the Elixir language) has a similar option, although only for aliases: https://hexdocs.pm/credo/Credo.Check.Readability.AliasOrder.html

So it is a thing indeed

On a personal note: I have seen it used on one project only, and IMHO it was only good for making your CI/CD pipeline fail when you forget to do the ordering before pushing the code

Not the answer you're looking for? Browse other questions tagged or ask your own question.