and code formatter (from ofﬁcial documentation). • a useful tool to make a team’s coding standard explicit and automatically executable. • an AST-based tool with complex internals, while most customization can be done by simply editing YAML ﬁles.
team’s coding rule/ standard with YAML ﬁles. • Coding rules are enforceable/executable by various ways such as CI, which makes your code more maintainable. • Autocorrect feature with editor plugins enables us to edit code faster.
has a rule of offense and sometimes knows how to ﬁx a problem (autocorrect). • “Autocorrect” is a feature of RuboCop modifying code with a rule automatically if possible (eg. ﬁxing indentation). • “Conﬁg ﬁle” is a ﬁle named “.rubocop.yml”, which conﬁgures RuboCop’s behavior. • “Todo ﬁle” is a YAML ﬁle similar to normal conﬁg ﬁle but generated by RuboCop command.
style guide at Ruby Style Guide (https://github.com/ rubocop-hq/ruby-style-guide) • This guide is not “approved by” authorities nor admitted by the whole Ruby community. • There are more guides, such as Cookpad’s one (https://github.com/cookpad/styleguide/blob/ master/ruby.en.md)
4k era, not vt100 era (however, some people argue character length makes sense). • Double negation is a famous Ruby idiom but RuboCop warns you by default. • Percent literal delimiters default is … IMHO most of us prefer (), right?
you introduce RuboCop to an ongoing project) • Disable all cops for auto generated ﬁles like bin, schema.rb, etc.. • Use auto-gen-conﬁg feature to generate todo ﬁle for ﬁxing problems later unless your project is brand new.
plugin for Ruby, RuboCop or syntax checker, you might be able to run RuboCop on the ﬂy, while you edit code. • Autocorrect works on the ﬂy as well. • If your editor does not have a plugin, I recommend changing an editor (use Vim if you have no preference )
to suit your team. Don’t believe the default rules. • Don’t try to ﬁx all problems at once if your project is mature/ongoing. Agree on coding standards of your team ﬁrst, and write conﬁg for RuboCop following it.