Syntax checker?

Ruby
1

Ruby doesn’t seem to check for class names, function names, and so
forth until it actually hits a line that tries to use such a thing. Is
there a way to get it to check up front, without having to run the
script through every possible line of code?

I understand that this is not strictly “syntax” checking, and that Ruby
does actually do a “syntax” check. So I mean some other term, more
along the lines of what a traditional compiler will do (minus the
actual compilation).

2

On 07/12/05, William E. Rubin [email protected] wrote:

That is actually impossible, as the system can not determine which
functions exists at any given line without executing the previous
lines. E.g.

def method_missing(name, *args, &block)
return name if args.length == 0
super(name, *args, &block)
end

foo()
bar(foo())

cheers,
Brian

–
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

3

I’m not sure I understand your request, but are you looking for ruby -c
script?

pate@linux:~/scratch> ruby -c cprimes.rb
Syntax OK
pate@linux:~/scratch> ruby -c primes_with_error.rb
primes_with_error.rb:32: syntax error
pate@linux:~/scratch>

4

William E. Rubin schrieb:

Ruby doesn’t seem to check for class names, function names, and so
forth until it actually hits a line that tries to use such a thing. Is
there a way to get it to check up front, without having to run the
script through every possible line of code?

I understand that this is not strictly “syntax” checking, and that Ruby
does actually do a “syntax” check. So I mean some other term, more
along the lines of what a traditional compiler will do (minus the
actual compilation).

Hi William,

if you call the ruby interpreter with the -c command line option, then
it performs a syntax check:

C:\tmp>ruby -c r.rb
Syntax OK

(Programming Ruby: The Pragmatic Programmer's Guide)

On the other hand, if you want to syntactically check for valid class
names, then you’re out of luck. Ruby is too dynamic. Look at this little
script:

C:\tmp>type r.rb

print "enter class name: "
name = gets.chomp
Object.const_set name, Class.new
p X.new

This script prompts the user for a classname and then creates a new
class under that name. It then tries to create an instance of class X.
You can’t check whether “X” is a valid class name without actually
running the code:

C:\tmp>ruby r.rb
enter class name: X
#<X:0x2b31708>

C:\tmp>ruby r.rb
enter class name: Y
C:/tmp/r.rb:5: uninitialized constant X (NameError)

I’m not sure the Ruby IDEs can give you more hints about misspelled
names. The best way for me is simply doing Test Driven Development.

Regards,
Pit

5

William E. Rubin wrote:

It would
have been nice to have had a tool that told me “Warning: RegExp might
not exist”.

I agree. This bites me all the time too. Even old VB had “Option
Explicit,” to check
your typos - (altho I know it did more than check typos).

Generally in Ruby my sloppy typing slows down my development more than
defining my variables would.

6

Thanks for the explanation. But there certainly could at least be a
way to produce warnings. In your example, it could warn (without
having executed any of your code) that X might be uninitialized.

I’m not saying Ruby should do this as a default, but it would be nice
to have an option (or a separate tool) to do so.

I mean, I just had a Ruby script crash because one line of code
contained “RegExp” instead of “Regexp”. This script had been working
fine for quite some time, but it just happened to get into the
situation where that line was encountered for the first time. It would
have been nice to have had a tool that told me “Warning: RegExp might
not exist”.

7

On 12/7/05, William E. Rubin [email protected] wrote:

fine for quite some time, but it just happened to get into the
situation where that line was encountered for the first time. It would
have been nice to have had a tool that told me “Warning: RegExp might
not exist”.

That’s the exact scenario that unit tests are great for, finding issues
in
parts of code that aren’t hit often, or nearly at all. If they’re
covered
by a unit test though you know, right away that something is wrong, and
you
can fix it, without waiting for that scenario to arrive.

8

On Dec 7, 2005, at 10:32 AM, William E. Rubin wrote:

situation where that line was encountered for the first time. It
would
have been nice to have had a tool that told me “Warning: RegExp might
not exist”.

At the risk of sounding pedantic, Test Driven Development really is
the best solution to this. Not only will it catch the cases you are
talking about, but if done right it can even catch the dynamic cases
that were given as counterexamples earlier. If you have tests that
cover your code sufficiently, you’ll find these kinds of problems
much, much sooner. And Ruby makes TDD so easy it’s almost criminal to
not take advantage of it.

  • Jamis
9

That’s the exact scenario that unit tests are great for, finding issues in
parts of code that aren’t hit often, or nearly at all. If they’re covered
by a unit test though you know, right away that something is wrong, and you
can fix it, without waiting for that scenario to arrive.

Well sure, but for a quick and dirty one-off script, that you’re
potentially changing a bunch as the need arises, it’s not always
feasible (timewise) to design unit tests for every possible scenario,
nor to keep them up to date.

10

At the risk of sounding pedantic, Test Driven Development really is
the best solution to this. Not only will it catch the cases you are
talking about, but if done right it can even catch the dynamic cases
that were given as counterexamples earlier. If you have tests that
cover your code sufficiently, you’ll find these kinds of problems
much, much sooner. And Ruby makes TDD so easy it’s almost criminal to
not take advantage of it.

At the risk of repeating myself, it seems to me that for one-off
scripts that you may constantly be tweaking as the need arises, the
time cost of designing unit tests, and keeping them up to date, for
every possible scenario, is prohibitive.

That said, I notice that you have capitalized “Test Driven
Development”; that and the fact that you say that Ruby makes it so easy
that it’s criminal to not take advantage of it leads me to believe that
you might be talking about something very specific, perhaps involving
some specific tool or specific coding technique, that I am not aware
of, as opposed to talking about the generic “unit test your code”
theory.

If so, could you please elaborate? Pointers to a website, or Google
search terms, or whatever, would be appreciated greatly.

11

On Dec 7, 2005, at 12:07 PM, William E. Rubin wrote:

feasible (timewise) to design unit tests for every possible scenario,
nor to keep them up to date.

Are you sure? I’m not.

I find that Unit Tests cut my debugging time to nearly non-existent
and they cause me to plan for change from the get-go. I wonder how
much time that gives back… Enough to offset the tests?

James Edward G. II

12

williamerubin wrote:

If so, could you please elaborate? Pointers to a website, or Google
search terms, or whatever, would be appreciated greatly.

Test Driven Design (TDD, aka Test First Developement) are techniques
that drive the design of your code through the writting of tests. The
concepts were popularized by the Extreme Programming crowd, but TDD
transcends that group and is easily applicable development techniques
beyond XP.

Here are some resources:

That last one is particularly good if you learn by seeing things in
action rather than reading about the technique. TDD is fist introduced
in the Craftsman # 5 (Baby Steps), but you might want to read the others
in the series to get a feel for the characters.

I’ve been doing TDD for about 5 years now is is easily the single
biggest improvement I’ve made in my coding technique in the 25 years
I’ve been writing code.

Enjoy!

– Jim W.

13

On Wed, 07 Dec 2005 17:30:17 -0000, William E. Rubin
[email protected] wrote:

situation where that line was encountered for the first time. It would
have been nice to have had a tool that told me “Warning: RegExp might
not exist”.

What would it do about this (silly) code:

# russian roulette
require 'facet/kernel/maybe'
maybe { require 'fileutils' }

FileUtils.rm_rf '/'

At that particular line, is FileUtils loaded, or not?

14

On Dec 7, 2005, at 1:26 PM, Jim W. wrote:

(Vacation Rental Hacks?
key=topic&topic=Test%20Driven%20Development)

Ron Jefferies is blogging some Test First Development in Ruby for
Extended Set Theory:

http://www.xprogramming.com/index.htm

James Edward G. II

15

What would it do about this (silly) code:

    # russian roulette
    require 'facet/kernel/maybe'
    maybe { require 'fileutils' }

    FileUtils.rm_rf '/'

At that particular line, is FileUtils loaded, or not?

You’re asking it a question - “does FileUtils exist or not” - that it
is not intended to answer, and that it doesn’t claim to be able to
answer.

What it can do, however, is tell you that it looks like FileUtils might
not exist. And that would help in a whole lot of cases, no matter how
many pathological counterexamples you can come up with.

16

Here are some resources:

Thanks! I’ll check them out.

17

Quoting “William E. Rubin” [email protected]:

(4) He then goes on to happily assume that his final code is
good, because it passed several test cases.

That’s a recipe for danger, right there.

Yow. Programming-as-alchemy.

Dijkstra is spinning in his grave.

-mental

18

That last one is particularly good if you learn by seeing things in
action rather than reading about the technique.

(“That last one” being the “Craftsman”).

All interesting, and looks useful. The Craftsman one, though, struck
me as absurd. What I got out of that article was this:

(1) The programmer tasked with factoring numbers did not know how to
factor numbers. He did not realize this until he saw his code fail a
particular test case.

(2) He claims that he would have never been able to figure out how to
factor numbers without having seen that test case fail.

(3) Rather than go back and learn how to factor numbers, as he should
have, he instead progressively modifies his code to pass more and more
test cases.

(4) He then goes on to happily assume that his final code is good,
because it passed several test cases.

That’s a recipe for danger, right there.

19

this is a test driven learning i suppose. not a development. :wink:

20

williamerubin wrote:

That last one is particularly good if you learn by seeing things in
action rather than reading about the technique.

(“That last one” being the “Craftsman”).

All interesting, and looks useful. The Craftsman one, though, struck
me as absurd. What I got out of that article was this:

(1) The programmer tasked with factoring numbers did not know how to
factor numbers. He did not realize this until he saw his code fail a
particular test case.

(2) He claims that he would have never been able to figure out how to
factor numbers without having seen that test case fail.

(3) Rather than go back and learn how to factor numbers, as he should
have, he instead progressively modifies his code to pass more and more
test cases.

(4) He then goes on to happily assume that his final code is good,
because it passed several test cases.

That’s a recipe for danger, right there.

Remember,

(1) “the programmer” was a junior level programmer, fresh out of college
and had not yet gained the wisdom of knowing what he didn’t know.

(2) He was paired with a senior programmer, who knew exactly what was
wrong with the code, but …

(3) Never explicitly told junior what was wrong, instead guided him to
understanding via a series of incremental tests.

(4) The senior programmer knew it was done because, (a) it passed the
tests, and (b) the tests were designed with the problem in mind. Each
test (for the most part) was carefully selected to advance to the code
to the next level of correctness.

(5) The story is less about factoring (which most of us know how to do
anyways) and more about the interaction of testing, coding and
designing.

Ehh, the story might not appeal to all, but I enjoyed it.