Regarding `instance()` method / `instance` field - to clarify my point - we
usually use that in many places. While it is quite easy to access by method
rather than by a field from the beginning, regardless if there is a need
for a mock immediately or not, it would be a much bigger change in terms of
lines/conflicts when we decide to change that later. This is just a
suggestion to make it more testable in our world full of singleton without
mass refactoring.
Obviously, we can formulate the requirement in different words - do have
80%+ coverage of unit tests (not in-jvm dtests) for the new / changed code.
thanks
- - -- --- ----- -------- -------------
Jacek Lewandowski
On Sun, Mar 20, 2022 at 8:55 PM Mick Semb Wever <m...@apache.org> wrote:
>
>
> On Tue, 15 Mar 2022 at 11:46, Ruslan Fomkin <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();
>
>
>
