Syntax checker?

Discussion in 'Ruby' started by William E. Rubin, Dec 7, 2005.

  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).
     
    William E. Rubin, Dec 7, 2005
    #1
    1. Advertising

  2. On 07/12/05, William E. Rubin <> 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 =3D=3D 0
    super(name, *args, &block)
    end

    foo()
    bar(foo())

    cheers,
    Brian

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

    Stringed instrument chords: http://chordlist.brian-schroeder.de/
     
    Brian Schröder, Dec 7, 2005
    #2
    1. Advertising

  3. William E. Rubin

    pat eyler Guest

    I'm not sure I understand your request, but are you looking for ruby -c scr=
    ipt?

    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 <> 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
    -------------------------
     
    pat eyler, Dec 7, 2005
    #3
  4. William E. Rubin

    Pit Capitain Guest

    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/rubyworld.html#UA)

    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
     
    Pit Capitain, Dec 7, 2005
    #4
  5. 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".
     
    William E. Rubin, Dec 7, 2005
    #5
  6. William E. Rubin

    Dougan Guest

    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.
     
    Dougan, Dec 7, 2005
    #6
  7. ------=_Part_1301_19053959.1133977154316
    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable
    Content-Disposition: inline

    On 12/7/05, 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".



    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.




    --
    =3D=3D=3DTanner Burson=3D=3D=3D

    http://tannerburson.com <---Might even work one day...

    ------=_Part_1301_19053959.1133977154316--
     
    Tanner Burson, Dec 7, 2005
    #7
  8. > 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.
     
    William E. Rubin, Dec 7, 2005
    #8
  9. William E. Rubin

    Jamis Buck Guest

    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
     
    Jamis Buck, Dec 7, 2005
    #9
  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.
     
    William E. Rubin, Dec 7, 2005
    #10
  11. 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
     
    James Edward Gray II, Dec 7, 2005
    #11
  12. William E. Rubin

    Jim Weirich Guest

    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-9058373-1662348?v=glance&n=283155)

    * 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?key=topic&topic=Test Driven Development)

    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 Weirich




    --
    Posted via http://www.ruby-forum.com/.
     
    Jim Weirich, Dec 7, 2005
    #12
  13. > Here are some resources:

    Thanks! I'll check them out.
     
    William E. Rubin, Dec 7, 2005
    #13
  14. William E. Rubin

    Ross Bamford Guest

    On Wed, 07 Dec 2005 17:30:17 -0000, 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".
    >


    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?

    --
    Ross Bamford -
    "\e[1;31mL"
     
    Ross Bamford, Dec 7, 2005
    #14
  15. On Dec 7, 2005, at 1:26 PM, Jim Weirich wrote:

    > Here are some resources:
    >
    > * Test Driven Development: By Example (Kent Beck)
    > (http://www.amazon.com/gp/product/0321146530/104-9058373-1662348?
    > v=glance&n=283155)
    >
    > * 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?
    > 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 Gray II
     
    James Edward Gray II, Dec 7, 2005
    #15
  16. > 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.
     
    William E. Rubin, Dec 8, 2005
    #16
  17. >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.
     
    William E. Rubin, Dec 8, 2005
    #17
  18. William E. Rubin

    Jim Weirich Guest

    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.

    --
    Posted via http://www.ruby-forum.com/.
     
    Jim Weirich, Dec 8, 2005
    #18
  19. William E. Rubin

    ako... Guest

    this is a test driven learning i suppose. not a development. ;-)
     
    ako..., Dec 8, 2005
    #19
  20. William E. Rubin

    Ross Bamford Guest

    On Thu, 08 Dec 2005 18:52:24 -0000, William E. Rubin
    <> wrote:

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


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

    --
    Ross Bamford -
    "\e[1;31mL"
     
    Ross Bamford, Dec 9, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert
    Replies:
    6
    Views:
    2,699
    Jim Michaels
    Feb 3, 2006
  2. neerashish
    Replies:
    2
    Views:
    301
  3. Kinokunya
    Replies:
    3
    Views:
    419
  4. Pager O Rama

    MSN BLOCK CHECKER-MSN STATUS CHECKER-MSN PROBLEMS

    Pager O Rama, Apr 4, 2006, in forum: ASP General
    Replies:
    0
    Views:
    296
    Pager O Rama
    Apr 4, 2006
  5. Jacob Grover
    Replies:
    5
    Views:
    351
    Jacob Grover
    Jul 18, 2008
Loading...

Share This Page