lsegal-yard 0.2.3

Sign up to get free protection for your applications and to get access to all the features.
Files changed (8) hide show
  1. data/FAQ.markdown +28 -0
  2. data/LICENSE +22 -0
  3. data/README.markdown +221 -0
  4. data/Rakefile +34 -0
  5. data/bin/yard-graph +4 -0
  6. data/bin/yardoc +4 -0
  7. data/bin/yri +13 -0
  8. metadata +58 -0
data/FAQ.markdown ADDED
@@ -0,0 +1,28 @@
1
+ FAQ
2
+ ===
3
+
4
+ 1. **So, show me some cool stuff. What can YARD do?**
5
+ - [Visualize with GraphViz][graphviz] Visualize your classes and methods with GraphViz
6
+ - [Inline RSpecs][inline-rspecs] In your rspec files, call the following to refer back to and call the inline rspecs: `described_in_docs "String", "camelcase"`
7
+ - [Inline doc testing][inline-doctest] Use the 'docspec' command line tool to run the above tests. This is similar to [Ruby DocTest][rubdoctest]'s inline irb testing.
8
+
9
+ 2. **Why did you pick the @-symbol tags for documentation?**
10
+
11
+ Java, C++, Python and many other languages have standard documentation tools that use the @tag "standard". This has been extended to the Ruby language, and YARD takes advantage of this common style.
12
+
13
+ 3. **Can I tweak it to use some other documentation standard?**
14
+
15
+ Yes. YARD is flexible enough to have other documentation syntaxes put into use. [TODO: Add information about customization here.]
16
+
17
+ 4. **Why don't you use ParseTree, or sydparse? Why did you write your own parser?**
18
+
19
+ All ruby parsers that we are aware of have two limitations that are unacceptable to a documentation parser:
20
+ 1. They do not put comments into the parse tree.
21
+ 2. They all fail ungracefully on parse errors.
22
+
23
+ As a result, YARD uses its own ruby parser that pays particular attention to the comment sections so that all of the information that is needed can be gleened from code and comments alike.
24
+
25
+ [graphviz]:http://gnuu.org/2008/02/29/generating-class-diagrams-with-yard-and-graphviz/
26
+ [inline-rspecs]:http://github.com/lsegal/yard/tree/5b07d706eee6bc0d7f13d9ec1e6e0ab914d3679c/lib/yard/core_ext/string.rb
27
+ [inline-doctest]:http://github.com/lsegal/yard/tree/master/lib/yard/handlers/base.rb#L350
28
+ [rubydoctest]:http://github.com/tablatom/rubydoctest
data/LICENSE ADDED
@@ -0,0 +1,22 @@
1
+ Copyright (c) 2007-2009 Loren Segal
2
+
3
+ Permission is hereby granted, free of charge, to any person
4
+ obtaining a copy of this software and associated documentation
5
+ files (the "Software"), to deal in the Software without
6
+ restriction, including without limitation the rights to use,
7
+ copy, modify, merge, publish, distribute, sublicense, and/or sell
8
+ copies of the Software, and to permit persons to whom the
9
+ Software is furnished to do so, subject to the following
10
+ conditions:
11
+
12
+ The above copyright notice and this permission notice shall be
13
+ included in all copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
16
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
17
+ OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
18
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
19
+ HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
20
+ WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
21
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
22
+ OTHER DEALINGS IN THE SOFTWARE.
data/README.markdown ADDED
@@ -0,0 +1,221 @@
1
+ YARD Release 0.2.2 (June 16th 2008)
2
+ ===================================
3
+
4
+ **Homepage**: [http://yard.rubyforge.org](http://yard.rubyforge.org)
5
+ **IRC**: **Join us on IRC in #yard on irc.freenode.net!**
6
+ **Git**: [http://github.com/lsegal/yard](http://github.com/lsegal/yard)
7
+ **Author**: Loren Segal
8
+ **Copyright**: 2007-2009
9
+ **License**: MIT License
10
+
11
+
12
+ SYNOPSIS
13
+ --------
14
+
15
+ YARD is a documentation generation tool for the Ruby programming language.

16
+ It enables the user to generate consistent, usable documentation that can be

17
+ exported to a number of formats very easily, and also supports extending for

18
+ custom Ruby constructs such as custom class level definitions. Below is a

19
+ summary of some of YARD's notable features.
20
+
21
+
22
+ FEATURE LIST
23
+ ------------
24
+
25
+ **1. RDoc/SimpleMarkup Formatting Compatibility**: YARD is made to be compatible

26
+ with RDoc formatting. In fact, YARD does no processing on RDoc documentation

27
+ strings, and leaves this up to the output generation tool to decide how to

28
+ render the documentation.

29
+
30
+ **2. Yardoc Meta-tag Formatting Like Python, Java, Objective-C and other languages**:

31
+ YARD uses a '@tag' style definition syntax for meta tags alongside regular code

32
+ documentation. These tags should be able to happily sit side by side RDoc formatted

33
+ documentation, but provide a much more consistent and usable way to describe

34
+ important information about objects, such as what parameters they take and what types
35
+ they are expected to be, what type a
method should return, what exceptions it can
36
+ raise, if it is deprecated, etc.. It also allows information to be better (and more
37
+ consistently) organized
during the output generation phase. Some of the main tags
38
+ are listed below:

39
+
40
+ #### Table 1. Meta-tags and their descriptions
41
+
42
+ ##### `@param [Types] name Description`
43
+ Allows for the definition of a method parameter with
optional type information.
44
+
45
+ ##### `@yieldparam [Types] name Description`
46
+ Allows for the definition of a method parameter to a yield block with optional
47
+ type information.
48
+
49
+ ##### `@yield [paramnames] Description`
50
+ Allows the developer to document the purpose of a yield block in a method.
51
+
52
+ ##### `@return [Types] Description`
53
+ Describes what the method returns with optional type information.
54
+
55
+ ##### `@deprecated Description`
56
+ Informs the developer that a method is deprecated and should no
57
+ longer be used. The description offers the developer an alternative
58
+ solution or method for the problem.
59
+
60
+ ##### `@raise [Class] Description`
61
+ Tells the developer that the method may raise an exception and of what type.
62
+
63
+ ##### `@see name`
64
+ References another object, URL, or other for extra information.
65
+
66
+ ##### `@since number`
67
+ Lists the version number in which the object first appeared.
68
+
69
+ ##### `@version number`
70
+ Lists the current version of the documentation for the object.
71
+
72
+ ##### `@author name`
73
+ The authors responsible for the module
74
+
75
+ You might have noticed the optional "types" declarations for certain tags.

76
+ This allows the developer to document type signatures for ruby methods and

77
+ parameters in a non intrusive but helpful and consistent manner. Instead of

78
+ describing this data in the body of the description, a developer may formally

79
+ declare the parameter or return type(s) in a single line. Consider the

80
+ following Yardoc'd method:

81
+
82
+ ##
83
+ # Reverses the contents of a String or IO object.
84
+ #
85
+ # @param [String, #read] contents the contents to reverse
86
+ # @return [String] the contents reversed lexically
87
+ def reverse(contents)
88
+ contents = contents.read if respond_to? :read
89
+ contents.reverse
90
+ end
91
+
92
+ With the above @param tag, we learn that the contents parameter can either be
93
+ a String or any object that responds to the 'read' method, which is more

94
+ powerful than the textual description, which says it should be an IO object.

95
+ This also informs the developer that they should expect to receive a String

96
+ object returned by the method, and although this may be obvious for a

97
+ 'reverse' method, it becomes very useful when the method name may not be as

98
+ descriptive.

99
+
100
+ **3. Custom Constructs and Extensibility of YARD**: Take for instance the example:

101
+
102
+ class A
103
+ class << self
104
+ def define_name(name, value)
105
+ class_eval "def #{name}; #{value.inspect} end"
106
+ end
107
+ end
108
+
109
+ # Documentation string for this name
110
+ define_name :publisher, "O'Reilly"
111
+ end
112
+
113
+ This custom declaration provides dynamically generated code that is hard for a
114
+ documentation tool to properly document without help from the developer. To

115
+ ease the pains of manually documenting the procedure, YARD can be extended by

116
+ the developer to handled the `define_name` construct and add the required

117
+ method to the defined methods of the class with its documentation. This makes

118
+ documenting external API's, especially dynamic ones, a lot more consistent for
119
+ consumption by the users.

120
+
121
+ **4. Raw Data Output**: YARD also outputs documented objects as raw data (the

122
+ dumped Namespace) which can be reloaded to do generation at a later date, or

123
+ even auditing on code. This means that any developer can use the raw data to

124
+ perform output generation for any custom format, such as YAML, for instance.

125
+ While YARD plans to support XHTML style documentation output as well as

126
+ command line (text based) and possibly XML, this may still be useful for those
127
+ who would like to reap the benefits of YARD's processing in other forms, such

128
+ as throwing all the documentation into a database. Another useful way of

129
+ exploiting this raw data format would be to write tools that can auto generate
130
+ test cases, for example, or show possible unhandled exceptions in code.

131
+
132
+
133
+ USAGE
134
+ -----
135
+
136
+ There are a couple of ways to use YARD. The first is via command-line, and the
137
+ second is the Rake task. There are also the `yard-graph` and `yri` binaries to
138
+ look at, if you want to poke around.
139
+
140
+ **1. yardoc Command-line Tool**
141
+
142
+ The most obvious way to run YARD is to run the `yardoc` binary file that comes
143
+ with YARD. This will, among other things, generate the HTML documentation for
144
+ your project code. You can type `yardoc --help` to see the options
145
+ that YARD provides, but the easiest way to generate docs for your code is to
146
+ simply type `yardoc` in your project root. This will assume your files are
147
+ located in the `lib/` directory. If they are located elsewhere, you can specify
148
+ paths and globs from the commandline via:
149
+
150
+ $ yardoc 'lib/**/*.rb' 'app/**/*.rb' ...etc...
151
+
152
+ The tool will generate a `.yardoc` file which will store the cached database
153
+ of your source code and documentation. If you want to re-generate your docs
154
+ with another template you can simply use the `--use-cache` (or -c)
155
+ option to speed up the generation process by skipping source parsing.
156
+
157
+ YARD will by default only document code in your public visibility. You can
158
+ document your protected and private code by adding `--protected` or
159
+ `--private` to the option switches.
160
+
161
+ **2. Rake Task**
162
+
163
+ The second most obvious is to generate docs via a Rake task. You can do this by
164
+ adding the following to your `Rakefile`:
165
+
166
+ YARD::Rake::YardocTask.new do |t|
167
+ t.files = ['lib/**/*.rb', OTHER_PATHS] # optional
168
+ t.options = ['--any', '--extra', '--opts'] # optional
169
+ end
170
+
171
+ both the `files` and `options` settings are optional. `files` will default to
172
+ `lib/**/*.rb` and `options` will represents any options you might want
173
+ to add. Again, a full list of options is available by typing `yardoc --help`
174
+ in a shell. You can also override the options at the Rake command-line with the
175
+ OPTS environment variable:
176
+
177
+ $ rake yardoc OPTS='--any --extra --opts'
178
+
179
+ **3. `yri` RI Implementation**
180
+
181
+ The yri binary will use the cached .yardoc database to give you quick ri-style
182
+ access to your documentation. It's way faster than ri but currently does not
183
+ work with the stdlib or core Ruby libraries, only the active project. Example:
184
+
185
+ $ yri YARD::Handlers::Base#register
186
+ $ yri File::relative_path
187
+
188
+ **4. `yard-graph` Graphviz Generator**
189
+
190
+ You can use `yard-graph` to generate dot graphs of your code. This, of course,
191
+ requires [Graphviz](http://www.graphviz.org) and the `dot` binary. By default
192
+ this will generate a graph of the classes and modules in the best UML2 notation
193
+ that Graphviz can support, but without any methods listed. With the `--full`
194
+ option, methods and attributes will be listed. There is also a `--dependencies`
195
+ option to show mixin inclusions. You can output to stdout or a file, or pipe directly
196
+ to `dot`. The same public, protected and private visibility rules apply to yard-graph.
197
+ More options can be seen by typing `yard-graph --help`, but here is an example:
198
+
199
+ $ yard-graph --protected --full --dependencies
200
+
201
+
202
+ CHANGELOG
203
+ ---------
204
+
205
+ - **Jun.16.08**: 0.2.2 release. This is the largest changset since yard's
206
+ conception and involves a complete overhaul of the parser and API to make it
207
+ more robust and far easier to extend and use for the developer.
208
+
209
+ - **Feb.20.08**: 0.2.1 release.
210
+
211
+ - **Feb.24.07**: Released 0.1a experimental version for testing. The goal here is
212
+ to get people testing YARD on their code because there are too many possible
213
+ code styles to fit into a sane amount of test cases. It also demonstrates the
214
+ power of YARD and what to expect from the syntax (Yardoc style meta tags).
215
+
216
+
217
+ COPYRIGHT
218
+ ---------
219
+
220
+ YARD &copy; 2007-2009 by [Loren Segal](mailto:lsegal@soen.ca). Licensed under the MIT
221
+ license. Please see the {file:LICENSE} for more information.
data/Rakefile ADDED
@@ -0,0 +1,34 @@
1
+ require File.dirname(__FILE__) + '/lib/yard'
2
+ require 'rubygems'
3
+ require 'rake/gempackagetask'
4
+ require 'spec'
5
+ require 'spec/rake/spectask'
6
+
7
+ WINDOWS = (PLATFORM =~ /win32|cygwin/ ? true : false) rescue false
8
+ SUDO = WINDOWS ? '' : 'sudo'
9
+
10
+ task :default => :specs
11
+
12
+ load 'yard.gemspec'
13
+ Rake::GemPackageTask.new(SPEC) do |pkg|
14
+ pkg.gem_spec = SPEC
15
+ pkg.need_zip = true
16
+ pkg.need_tar = true
17
+ end
18
+
19
+ desc "Install the gem locally"
20
+ task :install => :package do
21
+ sh "#{SUDO} gem install pkg/#{SPEC.name}-#{SPEC.version}.gem --local"
22
+ sh "rm -rf pkg/yard-#{SPEC.version}" unless ENV['KEEP_FILES']
23
+ end
24
+
25
+ desc "Run all specs"
26
+ Spec::Rake::SpecTask.new("specs") do |t|
27
+ $DEBUG = true if ENV['DEBUG']
28
+ t.spec_opts = ["--format", "specdoc", "--colour"]
29
+ t.spec_files = Dir["spec/**/*_spec.rb"].sort
30
+ end
31
+
32
+ YARD::Rake::YardocTask.new do |t|
33
+ t.options = ["--files", "FAQ.markdown,LICENSE"]
34
+ end
data/bin/yard-graph ADDED
@@ -0,0 +1,4 @@
1
+ #!/usr/bin/env ruby
2
+ require File.dirname(__FILE__) + '/../lib/yard'
3
+
4
+ YARD::CLI::YardGraph.run(*ARGV)
data/bin/yardoc ADDED
@@ -0,0 +1,4 @@
1
+ #!/usr/bin/env ruby
2
+ require File.dirname(__FILE__) + '/../lib/yard'
3
+
4
+ YARD::CLI::Yardoc.run(*ARGV)
data/bin/yri ADDED
@@ -0,0 +1,13 @@
1
+ #!/usr/bin/env ruby
2
+ require File.dirname(__FILE__) + '/../lib/yard'
3
+
4
+ YARD::Registry.load
5
+
6
+ object = YARD::Registry.at(ARGV[0])
7
+ options = {
8
+ :format => :text,
9
+ :template => :default,
10
+ :serializer => YARD::Serializers::ProcessSerializer.new('less')
11
+ }
12
+
13
+ YARD::Generators::QuickDocGenerator.new(options).generate(object)
metadata ADDED
@@ -0,0 +1,58 @@
1
+ --- !ruby/object:Gem::Specification
2
+ name: lsegal-yard
3
+ version: !ruby/object:Gem::Version
4
+ version: 0.2.3
5
+ platform: ruby
6
+ authors:
7
+ - Loren Segal
8
+ autorequire:
9
+ bindir: bin
10
+ cert_chain: []
11
+
12
+ date: 2008-05-16 00:00:00 -07:00
13
+ default_executable:
14
+ dependencies: []
15
+
16
+ description:
17
+ email: lsegal, soen.ca
18
+ executables:
19
+ - yardoc
20
+ - yri
21
+ - yard-graph
22
+ extensions: []
23
+
24
+ extra_rdoc_files: []
25
+
26
+ files:
27
+ - LICENSE
28
+ - FAQ.markdown
29
+ - README.markdown
30
+ - Rakefile
31
+ has_rdoc: false
32
+ homepage: http://yard.soen.ca
33
+ post_install_message:
34
+ rdoc_options: []
35
+
36
+ require_paths:
37
+ - lib
38
+ required_ruby_version: !ruby/object:Gem::Requirement
39
+ requirements:
40
+ - - ">="
41
+ - !ruby/object:Gem::Version
42
+ version: "0"
43
+ version:
44
+ required_rubygems_version: !ruby/object:Gem::Requirement
45
+ requirements:
46
+ - - ">="
47
+ - !ruby/object:Gem::Version
48
+ version: "0"
49
+ version:
50
+ requirements: []
51
+
52
+ rubyforge_project: yard
53
+ rubygems_version: 1.2.0
54
+ signing_key:
55
+ specification_version: 2
56
+ summary: Documentation tool for consistent and usable documentation in Ruby.
57
+ test_files: []
58
+