I don’t care whether or not we use rubocop to enforce a particular style.
However, if we don’t use rubocop to enforce a style, we should stay away from enforcing a hash style by commenting in PRs. Those comments would be too trivial and distracting to me. David On Fri, Aug 19, 2016 at 3:03 AM, Lukas Zapletal <[email protected]> wrote: > > As discussed on IRC yesterday there should be consistency and there is an > > option to autofix with rubocop if the style is changed to change existing > > code with less effort. > > TL;DR - Let's keep Rubocop away from rockethash thing. > > What the consistency gives us? We all know there are two ways and both > will work. Let's avoid big bangs that will make cherry picking harder > and just let's slowly improve as the time goes on. > > I see no point in changing a single line of code from old to new syntax > just for that. We should only change it when changing logic. > > Even if Rubocop is able to check only for changed lines, I won't like > that at all. I do not want to switch my brain between Smart Proxy and > Foreman Core codebases. Both ways should work and be accepted. Let's > only make the old syntax preferable when reviewing and that's it. > > I think we implemented Rubocop far beyond what's reasonable point. It > make sense for dangerous constructs, but not in this case (and few > others). > > -- > Later, > Lukas #lzap Zapletal > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
