[go: up one dir, main page]

Skip to content

Sort C/C++ Header Files before Source files in Merge Requests

Problem to solve

Prevent losing context in code review because the default sort ordering does not take into account semantics of the source code organization.

Intended users

Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->

Further details

When reviewing C/C++ code, I often find myself getting confused and without context until I realize that I'm seeing the source file before the header file. In C/C++ I use the header file to orient myself with how the source code is supposed to work, especially because our practice is to put the documentation in the header. Because this happens so often, I'm starting to think that it would be helpful to depart from the alphabetical ordering merge requests display into one that's more semantic.

Proposal

Change the sort ordering of code review such that:

  • Files lower in the tree are seen first (I assume that most projects are built from the base up, and the most generic files are shallower in the file tree.)
  • Documentation files (*.md, *.rst, *.txt) are seen first; to give an overview either of what we should be seeing in the following changes.
  • Then header/api documentation files (*.h, *.hpp, *.ads, ...)
  • Finally source files.

I could definitely see the last two being pairs. E.g. given files a.h, a.cc, b.h, b.cc. I would probably like to review them in that order rather than both header files first and then the source files.

Permissions and Security

None additional required.

Documentation

I can easily see this being very confusing going from a "bottom up" to a "top down" review flow. So some form of documentation, especially around what the ordering rules are will be useful. Especially if the ordering rules are customizable.

Testing

This would benefit from some broader user testing to identify other stories where certain files types should/shouldn't be ordered in one way or another.

What does success look like, and how can we measure that?

As a user; success for me means no longer having to go to the file tree to manually look at files out of order. Some file tree navigation is still expected to go back and re-read things though.

What is the type of buyer?

Any software developer.

Links / references

Edited by Matthew Walker