Forum: Ruby Syntax checker?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
williamerubin (Guest)
on 2005-12-07 17:50
(Received via mailing list)
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).
ruby.brian (Guest)
on 2005-12-07 17:59
(Received via mailing list)
On 07/12/05, William E. Rubin <removed_email_address@domain.invalid> 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/
pat.eyler (Guest)
on 2005-12-07 18:03
(Received via mailing list)
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>
pit (Guest)
on 2005-12-07 18:15
(Received via mailing list)
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

(http://www.ruby-doc.org/docs/ProgrammingRuby/html/...)

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
williamerubin (Guest)
on 2005-12-07 19:32
(Received via mailing list)
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".
walsha2000 (Guest)
on 2005-12-07 19:41
(Received via mailing list)
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.
tanner.burson (Guest)
on 2005-12-07 19:41
(Received via mailing list)
On 12/7/05, William E. Rubin <removed_email_address@domain.invalid> 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.
williamerubin (Guest)
on 2005-12-07 20:09
(Received via mailing list)
> 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.
jamis (Guest)
on 2005-12-07 20:09
(Received via mailing list)
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
williamerubin (Guest)
on 2005-12-07 20:25
(Received via mailing list)
> 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.
James G. (Guest)
on 2005-12-07 20:34
(Received via mailing list)
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
Jim W. (Guest)
on 2005-12-07 21:26
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:

* Test Driven Development: By Example (Kent Beck)
(http://www.amazon.com/gp/product/0321146530/104-90...)

* Introduction to Test Driven Development (article by Scott W Ambler)
(http://www.agiledata.org/essays/tdd.html)

* The Craftsman Serie (Bob Martin)
(http://www.objectmentor.com/resources/listArticles...)

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.
williamerubin (Guest)
on 2005-12-07 21:56
(Received via mailing list)
> Here are some resources:

Thanks! I'll check them out.
rosco (Guest)
on 2005-12-07 22:20
(Received via mailing list)
On Wed, 07 Dec 2005 17:30:17 -0000, William E. Rubin
<removed_email_address@domain.invalid> 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?
James G. (Guest)
on 2005-12-08 00:33
(Received via mailing list)
On Dec 7, 2005, at 1:26 PM, Jim W. wrote:

> (http://www.objectmentor.com/resources/listArticles?
> 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
williamerubin (Guest)
on 2005-12-08 20:59
(Received via mailing list)
> 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.
williamerubin (Guest)
on 2005-12-08 21:08
(Received via mailing list)
>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.
mental (Guest)
on 2005-12-08 21:45
(Received via mailing list)
Quoting "William E. Rubin" <removed_email_address@domain.invalid>:

> (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
Jim W. (Guest)
on 2005-12-08 22:49
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.
akonsu (Guest)
on 2005-12-08 23:06
(Received via mailing list)
this is a test driven learning i suppose. not a development. ;-)
rosco (Guest)
on 2005-12-09 14:16
(Received via mailing list)
On Thu, 08 Dec 2005 18:52:24 -0000, William E. Rubin
<removed_email_address@domain.invalid> wrote:

> 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.
>

Well, I don't see how it could really do that, without executing all
code
up to a certain point. Again, bear in mind that at the same point in
that
script, FileUtils may or may not be loaded, depending on what's already
happened. How about if you had another script using the above:

def suicide
   begin
     eval File.read('roulette.rb')
   rescue
     unless FileUtils
       require 'fileutils'
       retry
     end
   end
end

Regardless of what the example does, my point is, how should it warn
you?
When? If it worked just by looking at whether it _may_ be undefined,
then
surely it'd always warn you in the above situation?

I can see that it would probably help in a lot of cases, but it would be
an annoying gripe in a lot of the more complex cases, which is where
Ruby
shines. It's that dynamicity that attracted me to Ruby, the fact that
pretty much everything is executable code, and I think it'd be an
enormous
shame to start imposing static-language requirements on it so a few
people
can avoid writing a few testcases ...

Just my opinion...
William E. Rubin (Guest)
on 2005-12-13 21:00
(Received via mailing list)
> Regardless of what the example does, my point is, how should it warn you?

By saying "foo might be undefined at line 2351".

> When?

When you ask it to.  I'm not saying that such warnings should be output
by default.

> If it worked just by looking at whether it _may_ be undefined, then
> surely it'd always warn you in the above situation?

Assuming that you asked it to, then yes.  Or, potentially, there could
be a way to state, within the source code, for the benefit of this new
tool, that "Yeah, I already know that it looks like 'foo' might be
undefined on the next line (or in this function, or in this file).
Don't bother telling me about that".

> I can see that it would probably help in a lot of cases

I agree.

> but it would be
> an annoying gripe in a lot of the more complex cases, which is where Ruby
> shines.

Then don't use it in such cases.  Or, if you find it useful in some
complex case except for such annoyances, use it, but invoke the "Yeah,
I know" option described above.
This topic is locked and can not be replied to.