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

Create Slash.yml #111

Merged
merged 7 commits into from
Jul 1, 2024
Merged

Create Slash.yml #111

merged 7 commits into from
Jul 1, 2024

Conversation

alexvonme
Copy link
Contributor

I added the slash rule.

I also inelegantly added exceptions for both "AMD64/Intel 64" and "Wi-Fi/Bluetooth card" since their use was suggested in the style guide.

@ccoVeille
Copy link
Contributor

I'm a bit afraid this rule would need a lot of maintenance to add every exception needed

At least you used suggestion level

@ccoVeille
Copy link
Contributor

I will try to run it on my code base.

But I can at least can think about CPU architecture:

  • linux/amd64
  • linux/arm64

More example here

https://docs.docker.com/build/building/multi-platform/

@alexvonme
Copy link
Contributor Author

I'm a bit afraid this rule would need a lot of maintenance to add every exception needed

At least you used suggestion level

Absolutely, which is why I put suggestion as the level and added a generalized message.

@alexvonme
Copy link
Contributor Author

alexvonme commented Jun 30, 2024

I will try to run it on my code base.

But I can at least can think about CPU architecture:

  • linux/amd64
  • linux/arm64

More example here

https://docs.docker.com/build/building/multi-platform/

Different organizations may have different principles. In this case, SUSE appears to approach acceptable slashes cautiously. So, for now at least, I don't think we should add anything that wasn't explicitly allowed in the style guide to the rule here.

I thought about adding a lot of other stuff as well, but we should consider those within jargonLint/jargonLint/discussions/33. If a larger rule there becomes useful, then we can suggest it here as well.

@ccoVeille
Copy link
Contributor

Make sense

common/Slash.yml Show resolved Hide resolved
common/Slash.yml Show resolved Hide resolved
@alexvonme
Copy link
Contributor Author

@ccoVeille I understand your frustration with the rule's current limitations, but I'd still argue that the rule serves its purpose of warning users not to use slashes. It is not perfectly thorough, though for such a simple rule, that doesn't strike me as a problem. Slash rules are fairly popular in other Vale repositories as well, and most of them will prompt more false positives than this one.

For my part, I used it in Kanidm, which is under openSUSE and the rule was useful. Filenames as in /etc/foo were overwhelming excluded, so were links, while the rule correctly identified a lot of occasions where slashes shouldn't have been used. As such, I believe this rule would still be an asset to projects under SUSE and openSUSE, since it non-intrusively warns for a clear rule in the style guide.

I'd also prefer not to dwell too much on the rule, like we did in Latin.yml(#103). This rule isn't perfect and, in the short term at least, that should be acceptable.

@ccoVeille
Copy link
Contributor

I agree and accept your detailed explanations.

The problem I'm struggling with is the existence of suse "no slash" rule, more than your implementation

common/Slash.yml Outdated Show resolved Hide resolved
common/Slash.yml Outdated Show resolved Hide resolved
common/Slash.yml Show resolved Hide resolved
common/Slash.yml Show resolved Hide resolved
@alexvonme
Copy link
Contributor Author

@ccoVeille Is there anything else you want to add?

Copy link
Contributor

@ccoVeille ccoVeille left a comment

Choose a reason for hiding this comment

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

A few more example to avoid issues if a refactoring is made

tests/Slash-good.txt Show resolved Hide resolved
tests/Slash-good.txt Show resolved Hide resolved
@alexvonme
Copy link
Contributor Author

@tbazant this branch seems ready to merge. I've also added test files, sorry for neglecting those in earlier rules.

Co-authored-by: ccoVeille <[email protected]>
@tbazant
Copy link
Contributor

tbazant commented Jul 1, 2024

@dariavladykina do we have strong opinions about using slashes? if so, does it align with suggested changes?

Copy link
Contributor

@tbazant tbazant left a comment

Choose a reason for hiding this comment

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

LG, thanks!

@alexvonme
Copy link
Contributor Author

alexvonme commented Jul 1, 2024

@dariavladykina do we have strong opinions about using slashes? if so, does it align with suggested changes?

Just to be clear, I try to add rules that SUSE clearly asks for in the language section while keeping exceptions limited to what is explicitly allowed.

@dariavladykina
Copy link
Contributor

All of these additions for good and bad slash uses seem OK to me. Do we also have a rule to not use space around slashes? I.e. to avoid slash / slash? Thanks!

@alexvonme
Copy link
Contributor Author

alexvonme commented Jul 1, 2024

All of these additions for good and bad slash uses seem OK to me. Do we also have a rule to not use space around slashes? I.e. to avoid slash / slash? Thanks!

Yes, the regexp matches and therefore disallows them, which I had to write for my main project Kanidm, where we previously used and need to correct a lot of those.

'(?<!/)\w+\s?\/\s?\w+'

The \s? parts in specific satisfy that need.

Copy link
Contributor

@dariavladykina dariavladykina left a comment

Choose a reason for hiding this comment

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

LGTM!

@tbazant tbazant merged commit d26cc6a into openSUSE:main Jul 1, 2024
@alexvonme alexvonme deleted the slash branch July 18, 2024 15:51
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