Code Monkey home page Code Monkey logo

Comments (10)

pirj avatar pirj commented on May 25, 2024

You must be referring to the %w guideline:

Prefer %w to the literal array syntax when you need an array of words (non-empty strings without spaces and special characters in them). Apply this rule only to arrays with two or more elements.

with the following examples:

# bad
STATES = ['draft', 'open', 'closed']

# good
STATES = %w[draft open closed]

Do you have some counterexamples in mind?

As the style guide strives to follow the community usage of the Ruby language,

A style guide that reflects real-world usage gets used

would you like to harvest real-world-ruby-apps meta-repo to have some evidence that the literal string array syntax is used more often than %w?

from ruby-style-guide.

nello avatar nello commented on May 25, 2024

Thanks for the reply.

The example that keeps occurring for me is the process of adding another token to a %w-ified list. As array elements in nearly all languages have commas between them, silently automatically adding the comma into the token just causes pain.

The other one is long lines:

STATES = %w[This is an example of what happens when you wrap over a line and there are more words than I,
or anyone else can parse in a gestalt]

Is there a way to harvest real-world usage from before the recommendation was added to the style guide? It has an undue influence for better or worse, as it gets rolled into tooling (especially IntelliJ/RubyMine in my case).

from ruby-style-guide.

pirj avatar pirj commented on May 25, 2024

silently automatically adding the comma into the token just causes pain

The guideline non-ambiguously tells to "strings without ... special characters in them", where a comma is a special character. Such usage would be detected by a corresponding cop and would save you from the pain:

Within %w/%W, quotes and ',' are unnecessary and may be unwanted in the resulting strings

Are there other real daily usage examples that are problematic for you?

Is there a way to harvest real-world usage from before the recommendation was added to the style guide?

Things are as they are now. We don't doubt much about the effectiveness of boolean logic vs tri-state logic, using null, or byte length, even though, as an after-thought, those might not have been the best design decisions. I'm just stating that the guide reflects modern real-life usage, even though early iterations of the guide might have affected real-world usage.

from ruby-style-guide.

bbatsov avatar bbatsov commented on May 25, 2024

Agreed. We generally try to avoid affecting real-world usage, but rather reflect it in the guide. Btw, I'm not a big fan of %-literals myself and I've often publicly criticized them, but we can't deny they have always been quite popular in the wild.

from ruby-style-guide.

nello avatar nello commented on May 25, 2024

Re the "corresponding cop" suggestion I'm pretty dubious that fixing issues exacerbated by tooling with more tooling is a virtuous cycle. I think that the guide has a degree of influence it's wrong to minimise. If a practice is poor, is popularity enough to make it a recommendation?

from ruby-style-guide.

pirj avatar pirj commented on May 25, 2024

Are you confident enough to state that a certain practice is poor, basing on just your personal experience? If you look at this real-world- meta-repos, you would notice that not all of them use RuboCop, and they might even use alternative Ruby style guides. We are not affiliated with those meta-repos, and use them as an open data reference.

If a practice is poor, is popularity enough to make it a recommendation?

I understand what you mean. Yes. As Bozhidar mentions above about his personal preference to avoid %w, I have my personal preferences, too, that are going against what the style guide tells, usage of or/and being a notable example. Still, we try to be objective and unbiased towards personal preferences.

from ruby-style-guide.

Drenmi avatar Drenmi commented on May 25, 2024

The argument for this is reduced git churn for multiline lists, as only one line will be touched when re-ordering, preserving git blame, etc. To that end, the argument of problems with commas apply equally to the "normal" form, as it has happened quite frequently at work that someone re-ordered an array literal and forgot to move the comma. 😅

To me the strongest argument against using this style is that it can't be consistently applied. I prefer rules that aren't applied conditionally, like this one is as it requires the qualifier "non-empty strings without spaces and special characters in them".

Personally I'm on the fence about which one is "better". There's clearly a case to be made for either. But as it's a community style guide, I think we need to tolerate that the community might not always share our personal preferences.

from ruby-style-guide.

JohnCoates avatar JohnCoates commented on May 25, 2024

would you like to harvest real-world-ruby-apps meta-repo to have some evidence that the literal string array syntax is used more often than %w?

@pirj I'm interested in this issue as well. Is there a guide for harvesting?

from ruby-style-guide.

pirj avatar pirj commented on May 25, 2024

@JohnCoates something like:

  1. Clone it with sub modules (might require fixing refs as there are dead ones, and ones with renamed integration branches)
  2. Write a cop that would raise an offense for %i usage
  3. Write a cop that would detect %w
  4. Write a cop that would detect []
  5. Run those three cops separately against the metarepo. You may need to remove all .rubocop*.yml files from there.
  6. Compare the number of offences for each

there was a tool that would save you on steps 2-5 that just goes through a directory and prints all matched usages https://jonatas.github.io/fast/, but I have never used it.
Grep would not be a viable option.

from ruby-style-guide.

pirj avatar pirj commented on May 25, 2024

easily lead to errors with commas

I believe there is or should be a cop that would catch punctuation inside percent literals, as they certainly are unintentional in most cases if not always.

from ruby-style-guide.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.