On Wed, Feb 04, 2026 at 02:54:18PM +0000, Matthew Wilcox wrote: > On Mon, Feb 02, 2026 at 01:14:23PM -0800, Eric Biggers wrote: > > - Used the code formatting from 'git clang-format' in the cases where it > > looks better than the ad-hoc formatting > > clang-format makes some bad choices. > > > static int ext4_mpage_readpages(struct inode *inode, struct fsverity_info > > *vi, > > - struct readahead_control *rac, struct folio *folio) > > + struct readahead_control *rac, > > + struct folio *folio) > > Aligning to the opening bracket is one of them. If anything changes > in a subsequent patch (eg function name, whether or not it's static, > adding a function attribute like __must_check, converting the return > type from int to bool), you have to eitheer break the formatting or > needlessly change the lines which have the subsequent arguments. > > Also, you've consumed an extra line in this case. Just leave the > two tab indent, it's actually easier to read.
Aligning to the opening bracket is the usual style as agreed on by the kernel community. This should also be clear if you look at the existing style in all the files this patchset touches. It's not done exclusively but is the more common way. clang-format just follows that. It's 2026. We generally shouldn't be formatting code manually. We have better things to do. If you're going to insist on ad-hoc formatting of argument lists, you'll need to be more specific about where and how you want it to be done. It certainly doesn't make sense in files that are already using the normal style exclusively, for example. - Eric _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
