> I support this too… leads to more noise in, and less readability of, the > patch.
Readability of the patch is not harmed with modern tooling (with whitespace being highlighted differently to content changes). Legibility of the code (not patch) should always be preferred IMO. To aid code comprehension, we should aim for density of useful information for the reader; wasting a dozen or more lines on zero information density, solely to solve a problem already handled by modern diff tools, is a false economy. > I also agree that several arguments on the one line should be avoided, that > too many method parameters is the problem here. Method parameters aren’t a problem if they are strongly typed, parameters are cleanly grouped, and all call-sites utilise approximately the same behaviour. The alternatives are builders or mutability, the latter of which we broadly avoid. Builders make code navigation clunkier (creating more indirection to navigate when searching callers), as well as potentially creating additional heap pressure and code pollution (both in the call sites and the builder itself). Builders are helpful when there are lot of different ways to configure an object, but the more common case of simply propagating a relevant subset of existing parameters (plus perhaps a couple of new but required parameters), at just a handful of equivalent call-sites, they are IMO unhelpful. Note also that builders have the exact same legibility concerns as parameter-per-line: a significant amount of screen real-estate is taken up by scaffolding/noise. This is only useful if the builder call-sites communicate some unique configuration details about the particular call-site. > I would also like to suggest that an operator should always carry on line > wraps For the ternary operator I agree, however I am less convinced in other cases. String concatenation is probably cleaner with the opposite norm, so that string literals are aligned. From: Mick Semb Wever <m...@apache.org> Date: Sunday, 20 March 2022 at 19:55 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: Updating our Code Contribution/Style Guide On Tue, 15 Mar 2022 at 11:46, Ruslan Fomkin <ruslan.fom...@gmail.com<mailto:ruslan.fom...@gmail.com>> wrote: … I support Jacek’s request to have each argument on a separate line when they are many and need to be placed on multiple lines. For me it takes less effort to grasp arguments on separate lines than when several arguments are combined on the same line. IMHO the root cause is having too many arguments, which is common issue for non-OOP languages. I support this too. It has always bugged me that by having the first parameter not on a newline, then when the method (or variable assigned) name changes it causes all subsequent wrapped parameter lines have to be re-indented, which leads to more noise in, and less readability of, the patch. For example, method( "aaaaaaaaaaaaa", "bbbbbbbbbbbbb", "ccccccccccccc" ) is better than method("aaaaaaaaaaaaa", "bbbbbbbbbbbbb", "ccccccccccccc" ) I also agree that several arguments on the one line should be avoided, that too many method parameters is the problem here. I would also like to suggest that an operator should always carry on line wraps. This makes it faster to read the difference between arguments per line wrapping, and operations over multiple lines. For example, ensuring it looks like var = bar == null ? doFoo() : doBar(); and not var = bar == null ? doFoo() : doBar();
