|
From: Bart V. A. <bva...@ac...> - 2023-04-26 14:04:45
|
On 4/26/23 03:32, Nicholas Nethercote wrote:
> As I understand it, there are two main objections to mass-reformatting.
>
> * It breaks `git blame`. But as we've seen, this is entirely fixable.
> * "If it ain't broken, don't fix it." But I argue that it the
> current inconsistent formatting is a form of brokenness. Of course
> some care is required to fix it, e.g. the particular style should
> be chosen with care, and diffs should be reviewed by humans and
> not just blindly accepted. But there are high-quality, widely-used
> tools that make it straightforward. We should use them.
>
Are these the only disadvantages of reformatting the entire code base? I
see more disadvantages:
* Preserving the formatting of code that is in tabular format requires
manual annotation (/* clang-format off */ and /* clang-format on
*/). Who will do the tedious work of reviewing the entire code base
and annotating all the code for which formatting should be preserved?
* It is a certainty that reformatting the code with clang-format will
make formatting worse for a significant fraction of the code base. A
summary of the formatting made worse by clang-format for one
particular Linux kernel source file is available here: /Re: [PATCH]
scsi: megaraid: cleanup formatting of megaraid
<https://lore.kernel.org/linux-scsi/CAKwvOdnWHVV+3s8SO=Q8F...@ma.../>/.
* It is likely that the Valgrind .clang-format file will be modified
in the future. The Linux kernel .clang-format style file was
introduced in 2018 and since then has been modified 44 times:
$ git log .clang-format | grep -c ^commit
45
Will the entire Valgrind code base be reformatted every time the
Valgrind .clang-format file is modified?
Is the above list complete? Did I perhaps overlook any disadvantages?
Bart.
|