tailor parses Ruby files and measures them with some style and static analysis "rulers". Default values for the Rulers are based on a number of style guides in the Ruby community as well as what seems to be common. More on this here http://wiki.github.com/turboladen/tailor.
tailor's goal is to help you be consistent with your style, throughout your project, whatever style that may be.
- Checks for bad style in Ruby files
- Recursively in a directory, or...
- A given file, or...
- A glob ('lib/*/.rb')
- Checks for:
- Horizontal spacing
- Indentation
- Use of hard-tabs
- Line length
- Trailing spaces at the end of lines
- Spacing after commas
- Spacing before commas
- Spacing around { and before }
- Spacing after [ and before ]
- Spacing after ( and before )
- Spacing after a conditional
- Vertical spacing
- Trailing newlines (at the end of the file)
- Max code lines in a class/module
- Max code lines in a method
- Name cases
- Snake case class & module names
- Camel case method names
- Common syntax
- Conditionals wrapped in parentheses
- Unnecessary interpolation in strings
- Unnecessary use of double-quotes for strings
- Valid Ruby (warns by default)
- Horizontal spacing
- Configurable
- Specify style in
- ~./tailorrc
- PROJECT_ROOT + .tailor
- as CLI options
- "File sets" allow for applying different styles to different groups of files
- Set problems to :warn or :off instead of :fail
- Specify style in
- Define custom "Rulers"
- CI/Build Integration
- (Well, this may be stretching things a bit, but...) Exit 1 on failures
If you're reading this, there's a good chance you already have your own reasons for doing so. If you're not familiar with static analysis, give tailor a go for a few days and see if you think it improves your code's readability.
At tailor's inception, there were some other static analysis tools for Ruby, but none which checked style stuff; tailor started off as a means to fill this gap. Since then, a number of those tools have dropped by the wayside due to various Ruby 1.9 incompatibilities, and left a bigger tool gap for Rubyists. Right now it's mostly a style-checker, but might into a tool for analyzing other aspects of your Ruby code.
tailor 1.x is a marked improvement over 0.x. While 0.x provided a few (pretty inconsistent) style checks, its design made the code get all spaghetti-like, with lots of really gnarly regular expression matching, making it a really bear to add new features and fix bugs. tailor 1.x is completely redesigned to make that whole process much easier.
Check all files in a directory:
$ tailor path/to/check/
Check a single file:
$ tailor file_to_check.rb
Check only files ending in .rb under the 'test' directory:
$ tailor test/**/*.rb
Check defaults (lib/*/.rb):
$ tailor
Printing the results in a output file (if using a formatter that accepts output files, like 'yaml'):
$ tailor path/to/check --output-file=my-results.yaml
$ tailor --output-file=my-results-from-defaults.yaml
Use defaults via a Rake task (if you have a .tailor file, it'll use those settings):
require 'tailor/rake_task'
Tailor::RakeTask.new
The features list, above, shows some aspects of style that should be fairly straightforward (as to their meaning and reason), however, others make some big assumptions--particularly the indentation checking "ruler". There are a number of popular indenting conventions... In the case of multi-line parameters to a method, some like do this:
def a_really_freakin_long_method_name(my_really_long_first_parameter,
my_next_param)
# ...
end
...while others prefer:
def a_really_freakin_long_method_name(my_really_long_first_parameter,
my_next_param)
# ...
end
...and yet some others prefer:
def a_really_freakin_long_method_name(my_really_long_first_parameter,
my_next_param)
# ...
end
At this point, tailor only supports the style used in the first example. If this style isn't to your liking, then definitely take a look at the Configurable section here to see how to turn this off. Other styles will probably be supported in the future.
All that to say, though, that this isn't the only case where tailor makes style assumptions. Another discrepancy in popular styles is with regard to aligning operators in different lines. Some like:
my_hash[:first][:thing] = 1
my_hash[:eleventy][:thing] = 2
...while others prefer:
my_hash[:first][:thing] = 1
my_hash[:eleventy][:thing] = 2
...and yet some others prefer:
my_hash[:first][:thing] = 1
my_hash[:eleventy][:thing] = 2
Again, tailor only supports the first example here.
The goal is certainly not to force you to use the style that tailor currently uses; it just might not support your style yet. If tailor doesn't support your style, please feel free to take a look at the issues list and make a request. ...or fork away!
Not everyone prefers the same style of, well, anything really. tailor is configurable to allow you to check your code against the style measurements that you want.
It has default values for each of the "rulers" it uses, but if you want to customize these, there are a number of ways you can do so.
At any time, you can tell tailor to show you the configuration that it's going to use by doing:
$ tailor --show-config
To see, amongst other options, the style options that you can pass in, do
$ tailor --help
If, for example, you want to tell tailor to warn you if any of your code lines are > 100 chars (instead of the default of 80):
$ tailor --max-line-length 100 lib/
If you want to simply disable a ruler, just pass off
to the option:
$ tailor --max-line-length off lib/
While you can drive most tailor options from the command line, configuration files allow for some more flexibility with style rulers, file lists, and (eventually) report formatters. To create one with default settings, do:
$ tailor --create-config
With the documentation that's provided in the file, the settings should be
straightforward (if they're not, please let me know!). You don't have to
specify all of those settings in your config file--those are just rendered so
you have a starting ground to tweak with. If you only want to override a
single value, you can delete the rest of the code from your config. This
would accomplish the same as the --max-line-length
example above:
# .tailor
Tailor.config do |config|
config.file_set 'lib/**/*.rb' do |style|
style.max_line_length 100
end
end
This brings us to the concept of "file sets"...
File sets allow you to use different style rulers against different groups of files. You may, for example, want your Rails app code to allow for longer lines, or fewer code lines in methods... You may want your RSpec code to be more lenient with curly-brace usage... You may just want to specify a few file globs to use the default set of rulers... File sets allow for those sorts of things.
In the default config file, you see a single parameter being passed to
config.file_set
--this is the glob that defines the list of files for that
file set. While you don't see it, config.file_set
takes a second optional
parameter that allows you to label your style properties, and thus use
different sets of style properties for different sets of files. The label is
simply just a name to refer to that file set by; it will show in your report
(in the case that problems were found, of course) so you know what set of
rulers caused the problem to be found.
# .tailor
Tailor.config do |config|
# All defaults; implies "default" label
config.file_set 'lib/**/*.rb'
config.file_set 'app/**/*.rb', :rails_app do |style|
style.max_line_length 100
# All other rulers will use default values
end
# Uses default style, but labelled in the report with "features"
config.file_set 'features/**/*.rb', :features
config.file_set 'spec/**/*.rb', :rspec do |style|
style.spaces_after_lbrace false
style.spaces_before_lbrace false
style.spaces_before_rbrace false
# All other rulers will use default values
end
end
If it suits you better, use "recursive file sets" to get all matching files in your current path. If you wanted to critique all .rb files:
# .tailor
Tailor.config do |config|
# All defaults; implies "default" label
config.recursive_file_set '*.rb'
end
Similarly to the CLI, if you want to turn off a default Ruler, set its problem
level to :off
:
# .tailor
Tailor.config do |config|
config.file_set 'lib/**/*.rb' do |style|
style.indentation_spaces 2, level: :off
end
end
By default Tailor uses the text formatter, printing the results on console. Tailor also provides a YAML formatter, that accepts an output file if using the option --output-file=*.yaml
# .tailor
Tailor.config do |config|
config.formatters 'text', 'yaml'
# just one
config.formatters 'text'
end
While tailor provides a number of Rulers for checking style, it also provides a way for you to add your own rulers without having to delve into its innards. To do this, you need to do the following.
Before jumping in to this, take a look at {Tailor::Ruler} and any of the
existing Rulers in lib/tailor/rulers/
. There are some key things a new
Ruler must have:
-
the class name ends with "Ruler"
-
it inherits {Tailor::Ruler}
-
it's defined within the {Tailor::Rulers} module
-
#initialize
defines two parameters: 1.config
sets@config
to the "golden rule" value for what you're measuring 2.options
is a Hash, that should at least be passed the:level =>
you want the problem to be logged as -
#add_lexer_observers
gets passed a list of {Tailor::Lexer} event types that the ruler should get notified on -
it defines call-back methods for {Tailor::Lexer} to call when it comes across an event of interest
-
it calls
#measure
to assess if the criteria it's checking has been met -
it adds a {Tailor::Problem} to +@problems+ when one is found in
#measure
Internally, this all happens in lib/tailor/configuration/style.rb
, but you
can add information about your ruler to your config file. If you created a
Ruler:
# max_lines_in_block.rb
class Tailor
module Rulers
class MaxLinesInBlockRuler < Tailor::Ruler
def initialize(config, options)
super(config, options)
add_lexer_observers :ignored_nl, :kw
end
def ignored_nl_update(lexed_line, lineno, column)
# ...
end
def kw_update(token, lexed_line, lineno, column)
# ...
end
def measure
# ...
end
# ...
end
end
end
...then require this and add it to the Style list of properties:
# .tailor
require 'tailor/configuration/style'
require 'max_lines_in_block'
Tailor::Configuration::Style.define_property :max_lines_in_block
Tailor.config do |config|
config.file_set 'lib/**/*.rb' do |style|
style.max_lines_in_block 10, level: :error
end
end
Next time you run tailor, your Ruler will get initialized and used.
Sometimes you could use tailor as a lib, getting the results as a hash and manipulate them according your domain.
require 'tailor/cli'
# only results from a specific path
tailor = Tailor::CLI.new %w(app/controllers)
tailor.result # result should be a hash {"filename" => [problems]}
# using other file config (hiding path, it'll use from default config)
Tailor::CLI.new %w(--config-file=.other-config)
Tailor::CLI.new [] # uses file set from .tailor file config
# printing the results in a output file
tailor = Tailor::CLI.new %w(--output-file=results.yaml)
tailor.execute!
- Rubies (tested)
- ruby-2.0.0
- ruby-2.1.4
- Gems
- log_switch
- nokogiri
- term-ansicolor
- text-table
$ (sudo) gem install tailor
- rubocop. A robust Ruby code analyzer, based on the community Ruby style guide.
- cane. Code quality threshold checking as part of your build
- roodi. Ruby Object Oriented Design Inferometer
- reek. Code smell detector for Ruby
- flog. Flog shows you the most torturous code you wrote. The more painful the code, the higher the score.
- foodcritic. Foodcritic is a helpful lint tool you can use to check your Chef cookbooks for common problems.
- metric_fu. A fist full of code metrics
(The MIT License)
Copyright (c) 2010-2014 Steve Loveless
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.