[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Syntax checker?

williamerubin

12/7/2005 3:44:00 PM

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

21 Answers

Brian Schröder

12/7/2005 3:56:00 PM

0

On 07/12/05, William E. Rubin <williamerubin@dodgeit.com> wrote:
> 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).
>
>
>

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

Stringed instrument chords: http://chordlist.brian-sch...


pat eyler

12/7/2005 4:00:00 PM

0

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>


On 12/7/05, William E. Rubin <williamerubin@dodgeit.com> wrote:
> 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).
>
>
>


--
thanks,
-pate
-------------------------


Pit Capitain

12/7/2005 4:12:00 PM

0

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/rubywor...)

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

12/7/2005 5:30:00 PM

0

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

Dougan

12/7/2005 5:36:00 PM

0


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

12/7/2005 5:39:00 PM

0

On 12/7/05, William E. Rubin <williamerubin@dodgeit.com> wrote:
>
> 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".


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.




--
===Tanner Burson===
tanner.burson@gmail.com
http://tanner... <---Might even work one day...

williamerubin

12/7/2005 6:05:00 PM

0

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

12/7/2005 6:07:00 PM

0

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

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

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

12/7/2005 6:20:00 PM

0

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

12/7/2005 6:33:00 PM

0

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

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

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 Gray II