Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow {Module, Function} ignores in function_naming_convention/3 #118

Merged
merged 2 commits into from
Feb 27, 2020

Conversation

onno-vos-dev
Copy link
Contributor

@onno-vos-dev onno-vos-dev commented Feb 27, 2020

I'm slowly trying to modify as many rules as possible to accept a {Module, Function} or even {Module, Function, Arity} ignore. See: inaka/elvis#488 for a discussion that I had with @elbrujohalcon regarding this.

Rather than creating a big bang PR that fixes it in many places, I'd like to start small and fix one of the easiest ones to implement this for: function_naming_convention/3

I'm apparently able to update the Wiki (which seems a bit strange...?). Once approved and merged, I'll follow up with a PR in https://github.com/inaka/elvis/blob/master/rebar.config and edit the Wiki

Copy link
Member

@elbrujohalcon elbrujohalcon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little stylistic change, but also I don't see where we're limiting ignored functions to the scope of the module they belong to.
In other words, I would like to see a test with the following configuration not warning us for fail_function_naming_convention:camelCase but warning us for other_module:camelCase.

    #{regex => "^([a-z][a-z0-9]*_?)*$",
                    ignore => [ {fail_function_naming_convention, camelCase} ]
                   },

src/elvis_style.erl Show resolved Hide resolved
src/elvis_style.erl Outdated Show resolved Hide resolved
src/elvis_style.erl Outdated Show resolved Hide resolved
- Fix indentation
- Match out module when filtering functions
- Add test
@elbrujohalcon
Copy link
Member

Don't forget to update the wiki accordingly.

@onno-vos-dev
Copy link
Contributor Author

I'll do 👍 There are some more things to fix there since some rules that allow ignores aren't listed there so I'll go through the thing properly 👍 (And bump elvis once elvis_core is tagged)

@jfacorro jfacorro merged commit c5ae505 into inaka:master Feb 27, 2020
@onno-vos-dev
Copy link
Contributor Author

Could either of you create a new tag please?

@onno-vos-dev
Copy link
Contributor Author

Could either of you create a new tag please?

Thanks for the merge!

@jfacorro
Copy link
Contributor

@onno-vos-dev #119

@jfacorro
Copy link
Contributor

@onno-vos-dev Release created 0.6.0.

@onno-vos-dev
Copy link
Contributor Author

Thank you @jfacorro I found a lot of inconsistencies in the Wiki.

l'll try and do some form of PR by creating a Wiki on my github account and comment here. Am I just mis-reading things or could it be that the Wiki is (quite severally) outdated?

Line Length -> missing ignore
Nesting Level -> missing ignore
Module Naming Convention -> default regex seems wrong
Function Naming Convention -> missing ignore
Variable Naming Convention -> default regex seems wrong
Variable Naming Convention -> missing ignore
DRY -> missing ignore
Max Function Length -> IgnoreFunctions has wrong spec
No debug call -> default debug_functions is wrong
No deps master rebar -> rule doesn't seem to exist anymore?
Protocol for deps erlang.mk -> rule doesn't seem to exist anymore?
Protocol for deps rebar -> rule doesn't seem to exist anymore?
Old configuration format -> rule doesn't seem to exist anymore?
NO_SPACES_MSG -> not documented
no_seqbind-> not documented
no_useless_seqbind-> not documented

@jfacorro
Copy link
Contributor

jfacorro commented Feb 28, 2020

We have neglected the wiki page for a long time. Maybe we should add the documentation for each rule as an edoc in each function of elvis_style which would at least be ketp in sync with the code.

@onno-vos-dev
Copy link
Contributor Author

I like that idea, alternatively, we make it part of the README.md. That way at least it's version controlled and easier to block a PR if docs aren't updated with it?

@jfacorro
Copy link
Contributor

jfacorro commented Mar 3, 2020

Making it part of the README.md might make the file too big and discourage people to go through it. The reason why I was thinking about adding it to the edoc in each rule is because we could generate the edoc pages and publish them with each release.

@onno-vos-dev
Copy link
Contributor Author

Sounds good 👍 I'll move em over on the weekend and create a PR for it 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants