New `elvis_style` rule: `no_init_lists`

[bormilan]

Description

A brief description of your changes.

Closes #329;.

• [x] I have read and understood the contributing guidelines

---

EDIT: I made a checklist based on @elbrujohalcon 's comment to to make the progress traceable.

• [x] has init([|]) -> …: Should fail.

• [x] has init(A = [1,2,3]) -> …: Should fail

• [x] has init/1 implemented with multiple clauses, all of them expecting a list: Should fail.

• [x] - [ ] A module that has two behaviours and has init([]) -> should fail

• [x] has init/1 implemented with multiple clauses, one of them not being a list: Should pass, even if other clauses expect a list.

• [x] has init/1 implemented using a map, but init/2 implemented using a list in one of the arguments: Should pass.

• [x] has init/0 implemented using a tuple, but also init/0: Should pass.

• [x] A module that doesn't implement a behaviour and has init([1,2,3]) -> …: Should pass.

• [x] A module that has a behaviour that is not in the list of the rule's config -> should pass(with default config)

[bormilan]

Do we want to check that the module implements a gen_* behavior, or should we check every module like now? Oh, and I want to check if this rule can work on .beam files.

[paulo-ferraz-oliveira]

I tweaked the PR title since this'll go directly into the generated release Changelog.

[bormilan]

Thanks for the comments, I will solve all of them if I have some time. ❤️

[bormilan]

I still have some work to do, but it keeps getting better.

[elbrujohalcon]

@bormilan do you mind merging main into your branch, please?

[bormilan]

One more test (or maybe two, if you want a fail and a pass), @bormilan:

• A module that implements gen_server AND another behaviour…

-module(fail…).

-behaviour(gen_server).
-behaviour(another_behaviour).

-export([init/1]).

init([]) -> {error, "should not be a list"}.

Yes! I like making more and more tests to feel that my code is 100% good.

[elbrujohalcon]

Yes! I like making more and more tests to feel that my code is 100% good.

HA! I just saw that you were matching against a single [BehaviourNode] in your code… and I wondered "what would happen if we have multiple ones?"… so… we have to test that, right?

[bormilan]

Yes! I like making more and more tests to feel that my code is 100% good.

HA! I just saw that you were matching against a single [BehaviourNode] in your code… and I wondered "what would happen if we have multiple ones?"… so… we have to test that, right?

You're right. I'm working on the new logic right now, so it's the perfect time to add new tests and consider all the possible barriers.

[bormilan]

The only test that is not working now is the one with the init([]) because its attribute type is nil. I don't know how I will solve this, it may need some extra magic. Or is it a bug in katana_code?

[elbrujohalcon]

The only test that is not working now is the one with the init([]) because its attribute type is nil. I don't know how I will solve this, it may need some extra magic. Or is it a bug in katana_code?

Isn't it as simple as lists:member(ktn_code:type(Attr), [cons, nil])?

I think nil is precisely [], which is fine.

[bormilan]

The only test that is not working now is the one with the init([]) because its attribute type is nil. I don't know how I will solve this, it may need some extra magic. Or is it a bug in katana_code?

Isn't it as simple as lists:member(ktn_code:type(Attr), [cons, nil])?

I think nil is precisely [], which is fine.

Oh! Okay, that's nice, I started to dig into the code of katana, thanks for the clarification.