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

Issue#186 function names refactoring #277

Merged
merged 17 commits into from
Sep 28, 2015

Conversation

kbaird
Copy link
Collaborator

@kbaird kbaird commented Sep 27, 2015

No description provided.

@kbaird
Copy link
Collaborator Author

kbaird commented Sep 27, 2015

@elbrujohalcon I think this is ready for comments.

@elbrujohalcon
Copy link
Member

@kbaird can you add your rule to the elvis.config file, please?

@elbrujohalcon
Copy link
Member

and if you haven't already, please add your rule to the wiki as well. Thanks :)

{
elvis_style,
function_naming_convention,
#{regex => "^([a-z]*_?)*(_SUITE)?$"}
Copy link
Member

Choose a reason for hiding this comment

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

let's change that regex to something that says "lowercase ascii charts, underscores and digits", which is usually the default value for this rule, please

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I intentionally removed digits based on "Function names must use only lowercase characters" at https://github.com/inaka/erlang_guidelines#function-names. I also have a rule that forbids digits in function names.

I just want to confirm that you'd like that rule removed, and the regex to match the same one used for module names, which allows digits?

If so, can we update the quotation that I misinterpreted to say "only lowercase characters or digits" ?

Copy link
Member

Choose a reason for hiding this comment

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

We can update the quotation. Would you mind sending a PR with that change?

When I think of functions with numbers, I'm thinking in stuff like base64_encode or rfc###_… or iso6801_…, etc.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sure. pushing the change now, and will do that PR for the guidelines after that. Thanks.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

{
elvis_style,
function_naming_convention,
#{regex => "^([a-z][a-z0-9]*_?)*(_SUITE)?$"}
Copy link
Member

Choose a reason for hiding this comment

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

you still need to remove _SUITE from here :trollface:

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Why is the (_SUITE) present for the module_naming_convention? I was trying to follow the pattern established from module names by (_SUITE) being present in elvis.config but absent from style_SUITE.erl

If (_SUITE) is removed from the function use, should it also be removed from the module use?

Copy link
Member

Choose a reason for hiding this comment

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

because common-test modules must be called something_SUITE

So, no. It shouldn't be removed from the module name rule.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

OK, cool. Thanks. I was genuinely curious. Fix coming soon.

… is a common-test need for modules that does not apply to function names
elbrujohalcon pushed a commit that referenced this pull request Sep 28, 2015
@elbrujohalcon elbrujohalcon merged commit 0f091dd into inaka:master Sep 28, 2015
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.

2 participants