8000 Const naming by BraisGabin · Pull Request #3150 · detekt/detekt · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Const naming #3150

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

Closed
wants to merge 2 commits into from
Closed

Const naming #3150

wants to merge 2 commits into from

Conversation

BraisGabin
Copy link
Member
@BraisGabin BraisGabin commented Oct 18, 2020

This is just a reopen for #2017 (I don't know why I can't reopen it). Extracted from there:

There are places where we allow to use: thisFormat or THIS_FORMAT but we should never allow to use This_Format. This PR fix this issue in the 3 places where we allow the use of _ in the naming: enums, object properties and top level properties.

Why am I reopening this?

After @arturbosch closed that PR I opened this issue to IntelliJ: https://youtrack.jetbrains.com/issue/KT-34508 It was accepted as a valid issue but after one year it's not fixed.

I think that we should rethink about merging this.

We have another related issue: private val _HELLO should not be valid and we are allowing it. I'm going to create another PR fixing it. 

@codecov
Copy link
codecov bot commented Oct 18, 2020

Codecov Report

Merging #3150 (5c808f7) into master (462ad50) will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master    #3150   +/-   ##
=========================================
  Coverage     80.04%   80.04%           
  Complexity     2653     2653           
=========================================
  Files           443      443           
  Lines          8090     8090           
  Branches       1540     1540           
=========================================
  Hits           6476     6476           
  Misses          790      790           
  Partials        824      824           
Impacted Files Coverage Δ Complexity Δ
...itlab/arturbosch/detekt/rules/naming/EnumNaming.kt 90.90% <100.00%> (ø) 4.00 <0.00> (ø)
...rbosch/detekt/rules/naming/ObjectPropertyNaming.kt 100.00% <100.00%> (ø) 12.00 <0.00> (ø)
...osch/detekt/rules/naming/TopLevelPropertyNaming.kt 100.00% <100.00%> (ø) 11.00 <0.00> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 462ad50...5c808f7. Read the comment docs.

val code = """
object O {
private val __NAME = "Artur"
private val MyNAME = "Artur"
private val n_a_m_e = "Artur"
private val _MY_NAME = "Artur"
Copy link
Member

Choose a reason for hiding this comment

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

Hm, as long as IntelliJ does not change it's own regex I would not like to change this.
All this cases are okay in IntelliJ when I paste them and would cause a lot of issues for our users

@arturbosch
Copy link
Member

This is just a reopen for #2017 (I don't know why I can't reopen it). Extracted from there:

Stale issues without comments get locked by our bot integration.

There are places where we allow to use: thisFormat or THIS_FORMAT but we should never allow to use This_Format. This PR fix this issue in the 3 places where we allow the use of _ in the naming: enums, object properties and top level properties.

Why am I reopening this?

After @arturbosch closed that PR I opened this issue to IntelliJ: https://youtrack.jetbrains.com/issue/KT-34508 It was accepted as a valid issue but after one year it's not fixed.

I would really like to have IntelliJ change its default before doing such a change which will lead to new issues for our users.

I think that we should rethink about merging this.

We have another related issue: private val _HELLO should not be valid and we are allowing it. I'm going to create another PR fixing it.

@BraisGabin
Copy link
Member Author
BraisGabin commented Oct 19, 2020

Right now our regex allow names like this: private val OneProperty: String. And that's clearly wrong and jetbrains agree with it. I tried to fix that in IntelliJ but I can't understand that project and how to run it's tests.

I think that our users expect that if someone in their teams adds a property with a name like the one in my example detekt will complain. I don't think that flaging more code to our users is bad thing. They relay on detekt to find issues in their code.

I understand that it will be better if IntelliJ implements it too and for that reason I waited nearly a year to reopen this issue. But if they don't fix it I don't see why we should keep this issue in our rule too.

But, this change should be merged for a minor release and not a patch.

@BraisGabin
Copy link
Member Author

Could we take a decision about this update @cortinico @schalkms what do you think about this? I think that it could be merged for the 1.15 relase if you agree. Or close the topic if disagree.

@schalkms
Copy link
Member

In my opinion detekt should be compliant to IntelliJs rules.

@cortinico
Copy link
Member

In my opinion detekt should be compliant to IntelliJs rules.

Agree.

I've 👍 -d your YouTrack ticket. Other than that, I believe we should try to align as much as possible to commonly used RegExes (like the one used in IntelliJ) unless we have a strong argument/case to change one. So far it seems this is a minor concern, and users that are interested in altering the inspection behavior to adhere to the official docs, can still update the Regex.

I believe if we end up waiting for JetBrains, we could still leave a note in the *Naming rules with a link to this issue or a mention of the alternate regex.

@BraisGabin
Copy link
Member Author

I believe if we end up waiting for JetBrains, we could still leave a note in the *Naming rules with a link to this issue or a mention of the alternate regex.

I added those comments but they look kind of strange there so I think that we should close this and if we get a notificacion that the issue was fixed we will update it. Maybe I try again to fix it in the intellij code but I have no idea how to run the test there.

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.

4 participants
0