Best practices as code using RuboCop • Hacker News Board

Re: Best practices as code using RuboCop

#41

Post by Spivak » Fri, Jan 21, 2022, 5:49 PM UTC

LanceH wrote: post #35

d3nj4l wrote: post #27

Earlier quoted context omitted.

I don't know, your version in the example looks pretty bad to me? Sure, maybe the excessive line length of the combined if is a readability issue, but something about a postfix unless inside an if makes it very hard to follow what combination of flags would trigger it. In this scenario, I'd try to give meaningful names to the boolean expressions, and write a simpler conditional.

do_some_thing if ready_to_go(variables_needed_for_conditionals...)

If this pattern just the norm in Ruby because I loathe these single purpose functions that are basically comments that I have to jump to another function to see. It makes tracing what actually happens in some piece of code impossible without a notes file to make it all on-screen.

Re: Best practices as code using RuboCop

#42

Post by Spivak » Fri, Jan 21, 2022, 5:51 PM UTC

jaredsohn wrote: post #39

brightstep wrote: post #31

Earlier quoted context omitted.

I don't like either of your or rubocop's approach. If you have that many conditionals, bind a local variable that describes the condition being checked. Then you have an easy to read `if` with a single variable.

or a model method or private method in the class containing this code

But why?!?! There's no way this conditional is a well-defined named concept and just adds indirection for the sake of line length.

Re: Best practices as code using RuboCop

#43

Post by jaredsohn » Fri, Jan 21, 2022, 5:55 PM UTC

Spivak wrote: post #42

jaredsohn wrote: post #39

Earlier quoted context omitted.

or a model method or private method in the class containing this code

But why?!?! There's no way this conditional is a well-defined named concept and just adds indirection for the sake of line length.

>There's no way this conditional is a well-defined named concept

Sure about that? I'm saying if it is then extracting as a method might be clearer. All depends and these are other options.

Re: Best practices as code using RuboCop

#44

Post by brightstep » Fri, Jan 21, 2022, 6:59 PM UTC

Spivak wrote: post #42

jaredsohn wrote: post #39

Earlier quoted context omitted.

or a model method or private method in the class containing this code

But why?!?! There's no way this conditional is a well-defined named concept and just adds indirection for the sake of line length.

maybe two well-named concepts then? If you're unable to reduce it at all, I'd consider that a code smell.

Re: Best practices as code using RuboCop

#45

Post by hit8run » Fri, Jan 21, 2022, 7:51 PM UTC

I use standard.rb as a more opinionated and saner approach.

Re: Best practices as code using RuboCop

#46

Post by rapind » Fri, Jan 21, 2022, 9:19 PM UTC

jjgreen wrote: post #6

matthewmacleod wrote: post #4

Earlier quoted context omitted.

I don't understand this complaint – the convention is encoded in the defaults. If you actively choose configuration over convention, it doesn't make much sense to complain that you had to supply configuration!

I mean: the defaults are so dreadful and wrong that I would have to configure in order to use it; and I don't want to do that.

Saying style defaults are “wrong” is subjective (unless of course it actually breaks your code).

I don’t like rubocops defaults either though tbh.

Ultimately to be highly successful I think this has to happen at the language level, and early on (I.e golang).

Rubocop should still be useful for teams, but will probably annoy some of your members.

Re: Best practices as code using RuboCop

#47

Post by dapirian » Fri, Jan 21, 2022, 9:55 PM UTC

100% agree that documenting the practices of your repo is a losing battle: automate it or don't bother. I don't think you go far enough here. Every file in your repo should minimally have an autoformatter and some kind of linter/static analyzer/validator set up. Even shell scripts, ci pipeline configs, dockerfiles, terraform, etc. I recommend https://docs.trunk.io ;)

Re: Best practices as code using RuboCop

#48

Post by burke » Fri, Jan 21, 2022, 11:15 PM UTC

joevandyk wrote: post #12

jjgreen wrote: post #2

I dislike rubocop, not because I dislike linters (pep8 is fine), but because the defaults have strong opinions about things that don't matter if foo? then blah end will result in a complaint about how one should remove the "then". Sure, you can configure rubocop to not make that complaint, and then the next one, and then next one ... but whatever happened to convention-over-configuration? I choose the convention of n…

Using "then" in ruby definitely isn't idiomatic and goes against convention.

Yeah I’m sympathetic to this argument and I myself am often annoyed by rubocop’s apparent heuristic of “is it possible to encode an opinion on this? Great then let’s do it” … but in this case, I think this rule is beyond justifiable.

Re: Best practices as code using RuboCop

#49

Post by LanceH » Sat, Jan 22, 2022, 4:41 AM UTC

Spivak wrote: post #41

LanceH wrote: post #35

Earlier quoted context omitted.

do_some_thing if ready_to_go(variables_needed_for_conditionals...)

If this pattern just the norm in Ruby because I loathe these single purpose functions that are basically comments that I have to jump to another function to see. It makes tracing what actually happens in some piece of code impossible without a notes file to make it all on-screen.

Considering OP was a bit vague with:

if some_verbose_condition && some_other_verbose_condition do_the_thing unless excluded_case || other_excluded_case end Rubocop changed this to if (some_verbose_condition && some_other_verbose_condition) && !(excluded_case || other_excluded_case) do_the_thing end

I don't really know what the proper solution is. I present one possibility here. "verbose condition" may or may not be complex, I don't know. But it's definitely a candidate for putting in it's own function and making tests out of it if there is complexity, or if it's just hard to read.

I'll agree there are too many of the following in Ruby:

def red?(color) return color == "red" end

As we don't know what his conditions are, we don't know if a function makes sense or not. There are times when you want to see the conditions up front, and times when they are a mere afterthought and relegating them to a function in the guard clause is best.

For whoever is downvoting just because they don't like the style of code in a discussion of abstract code, there is always:

do_the_thing if a && b unless c || d

Nothing like double guard clauses for double the lint fun.

Re: Best practices as code using RuboCop

#50

Post by theonething » Sat, Jan 22, 2022, 7:08 AM UTC

joevandyk wrote: post #12

jjgreen wrote: post #2

I dislike rubocop, not because I dislike linters (pep8 is fine), but because the defaults have strong opinions about things that don't matter if foo? then blah end will result in a complaint about how one should remove the "then". Sure, you can configure rubocop to not make that complaint, and then the next one, and then next one ... but whatever happened to convention-over-configuration? I choose the convention of n…

Using "then" in ruby definitely isn't idiomatic and goes against convention.

Have used Ruby professionally for a few years now and had no idea "then" exists.

TIL (something not that useful)