This issue is stale because it has had no activity for the last 30 days.

@scheals Gonna discuss the rubocop stuff here. I'll assign you to work on it.

Feel free to ask any questions you may have. I'll post some of my notes, ideas, and links here later when I'm booted back in my Ubuntu environment, although the "Acceptance Criteria" in the OP (originally written by Chook), hits most of the main points I was planning to go over.

Just giving a heads up that I'm slowly working on it :) Your notes, ideas and links would be very appreciated!

Thanks for reminding me of this @scheals

In looking at my notes, I had most of the things pointed out above in the Acceptance Critera for my outline.

I think one of the important things is introducing the idea of linting/formatting. Why is this important? Can borrow ideas from how this is done in the JavaScript course. Probably a good idea to link to an article or wikipedia page or something that explains what "linting" even is. I think some good points to hit on the "why" of it might include:

• helps a team of developers achieve a more consistent style and formatting across the project
• helps catch common errors before runtime (like a missing end, for example)
• helps with integrating certain "good" practices. rubocop is nice about suggesting alternate ways to format nested conditionals for example.

I thought it'd be nice to have people create a new "project" or really a playground to install it and try things out. Gives people a place to practice with bundle init and adding things to the Gemfile. So maybe a little walk through doing that, have them add the rubocop gem, and then have them make a ruby file that has some blatant lint issues in it ie:

# linting_playground.rb

def badMethodDefinition a, b
  puts "This method definition has stylistic problems"
end

Then they could run the CLI against that and see the problems. Then maybe walk through how to integrate with VSCode and have the diagnostics show up in the IDE itself.

This was just my (unpolished) idea for introducing it. Feel free to ignore or change things lol.

That's about as far as I get with my thinking and development of this. Also think the Acceptance Critera in the original post has some important items to hit on (the style guide, rules that are difficult to understand, etc.)

Definitely let me know if you have any questions or just want feedback on any ideas or anything.

Cheers for this Josh. I've been eyeing the JS Linting lesson a little and so far have started to hit on those points I believe.

And as for the new "project" - in the WIP version I'm just getting folks to go back to their Caesar Cipher project. I am going to check like a dozen of such recently submitted projects to check if Rubocop picks up something in every single of them (I would expect that to be the case). This way they can improve something they've already worked on and it'll set the stage for the future test adding. So seems like great minds think alike :D

CLI -> VSC is my direction as well, especially since w/ VSC we've got the overhead of Ruby-LSP now and things might change.

Fingers crossed I have the first rough draft of the lesson finished by tomorrow.

Also, a mental note for both you and me:
Ruby-LSP VSC extension has moved to a monorepo, so we need to make sure our links in #27128 are updated.

This issue is stale because it has had no activity for the last 30 days.