Linting and RuboCop: Paragraph 'Convention time again' needs a little love

[ruben-vl]

Checks

• This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
• I have thoroughly read and understand The Odin Project Contributing Guide
• Would you like to work on this issue?

Describe your suggestion

There are some issues with the first paragraph under 'Convention time again':

• "variables are things like do_something(with_thing, another_thing)
  • I think this is wrong and an example of a method
• "Why there exists a preference for getting rid of if statements"
  • I don't know where this comes from, don't remember it from an earlier lesson, so maybe a reference to some source would be useful
• Typo in "some languages prefer loops while other+s prefer iterative approaches"
  • Also confusing what is meant exactly with 'iterative approaches'. Is this a reference to enumerables (each, map...)? Because loops are inherently an iterative approach as far as I understand (e.g. compared to recursion).

Path

Ruby / Rails

Lesson Url

https://www.theodinproject.com/lessons/ruby-linting-and-rubocop

(Optional) Discord Name

ruben-vl

(Optional) Additional Comments

Seems like an easy first contribution. Will volunteer after the weekend if no-one else is open to be assigned.

[scheals]

For the first one, it probably is just not-so-fortunate omission:

You have already been exposed to some of the conventions in HTML, CSS, JS and Ruby. This is why JS has its variables written likeThis while Ruby’s are like_this, why functions are verbs and variables are things like do_something(with_thing, another_thing).

"functions are verbs" -> do_something(), "variables are things" -> with_thing ; another_thing

So perhaps something like:

why functions are verbs and variables are things resulting in our function definitions looking like this: do_something(with_thing, another_thing).

should work a lot better. Now thinking about this, I wonder whether "functions" should be changed to "methods" but I think my idea was to bring it as close to what-has-been with JS as possible.

Why there exists a preference for getting rid of if statements
I don't know where this comes from, don't remember it from an earlier lesson, so maybe a reference to some source would be useful

You're right. This might be me coming from a different place. I'm pretty sure that at that point I read enough nasty nested if statements or "smart" ternaries to find them confusing but I did search for a short while and nothing in the curriculum seems to mention that. So the style guide is the first time someone might actually find this as guidance coming from TOP.

There's a spectre of polymorphism hiding behind this statement as well but before Chess, the benefits of polymorphism will probably be unknown to most. They were to me for sure!

Typo in "some languages prefer loops while other+s prefer iterative approaches"
Also confusing what is meant exactly with 'iterative approaches'. Is this a reference to enumerables (each, map...)? Because loops are inherently an iterative approach as far as I understand (e.g. compared to recursion).

Yeah this most likely should say iterative methods or something like that. It is indeed a reference to things like enumerables. Relevant Ruby Style guide bit.

[SumonGFC]

I like these:

1. "...why function names are verbs and variable names are nouns..."
2. "...why there is a preference for ternary operators instead of if/else blocks for simple conditional statements..."
3. "...why some languages prefer loops while others prefer iterators..."

Tangential:
It seems odd that this section of the lesson doesn't formally reference/hyperlink the Ruby Style Guide. if I recall correctly, the style guide is linked earlier in the course, but I don't remember where. Since Rubocop enforces many of the guidelines in the style guide, it would be nice to have a link to it that is within this section (or somewhere around the beginning of the lesson) so that learners can browse through it a bit.

[shirschfield]

Happy to submit a PR for this!