Typo-checking instead of static typing

[Ben Giddings]

That's about my most common error too (it ties with a parse error due
to a missing 'end' statement).

Python to the rescue! See, when your language doesn't have end statements
you can't *possibly* have any of these types of problems, right? *grin*

Ok, but seriously. We have "ruby -w" and "ruby -c" and "unit tests".

So let's have an analogy. Someone writs the following bit of C code:

int do_something(int foo) {
int i;

if (foo > 500) {
printf("Whoa, %d is too many times! I can't do that!", fo);
}
else {
for (i=0; i<foo; i++) {
printf("%d\n", i);
}
}
}

int main(int argc, char **argv) {
do_something(argv[1]);
}

The typical approach of a C programmer would be to try to compile that, and
if they noticed no errors, they'd run it.

The compiler would immediately catch:
* do_something() is being called with an character pointer as an arg, but
is declared as accepting an integer
* The variable used in the printf line "fo" was never declared.

Once the programmer fixed those two issues, the code would do what the
author intended.

The equivalent Ruby code would be:

def do_something(foo)
if foo > 500
puts "Whoa, #{fo} is too many times! I can't do that!"
else
foo.times { |i| puts i }
end
end

do_something(ARGV[0])

"ruby -c" would say this is perfect syntax, which it is. So that's kinda
useless for typos and brainos

"ruby -w" would run it, and it would barf with this message:

foo.rb:4:in `>': undefined method `>' for false:FalseClass (NoMethodError)
from tmp/foo.rb:4:in `do_something'
from tmp/foo.rb:11

The line number is useful, but the message sure isn't. It turns out that
string > number complains about FalseClass. I dunno why. Anyhow, it's
obvious there is *some* error, so presumably the programmer would remember
to 'to_i' the arg to do_something().

Then there's the typo in the "puts" line. Until the person happens to try
an arg greater than 500, they will have no indication the code has a flaw.

Now, would a unit test catch this? If the programmer was careful, maybe.
But maybe not.

So, what advice would you guys give to a C programmer who wants a Ruby tool
to look over lines of code he may rarely execute?

Ben

 

[Joao Pedrosa]

Hi,

So, what advice would you guys give to a C programmer who wants a Ruby tool
to look over lines of code he may rarely execute?

Go with Java and use Generics. Avoid reflection, bytecode engineering
and AOP.

Cheers,
Joao

 

[Joost Diepenmaat]

On Thu, May 05, 2005 at 03:49:30AM +0900, Ben Giddings wrote:
[ snip ]

def do_something(foo)
if foo > 500
puts "Whoa, #{fo} is too many times! I can't do that!"
else
foo.times { |i| puts i }
end
end

do_something(ARGV[0])

[ snip ]

Then there's the typo in the "puts" line. Until the person happens to try
an arg greater than 500, they will have no indication the code has a flaw.

Now, would a unit test catch this? If the programmer was careful, maybe.
But maybe not.

So, what advice would you guys give to a C programmer who wants a Ruby tool
to look over lines of code he may rarely execute?

Use a code coverage tool to run over your unit tests, and fix your
tests to go to 100% coverage. That's what I usually try to do in Perl anyway.

Pointers to coverage tools for ruby anyone?

Joost.

 

[Florian Frank]

Hal Fulton wrote:


is

(flori@lambda:flori 0)$ gem list -r |grep covera
coverage (0.2, 0.1)

 

[Ben Giddings]

Use a code coverage tool to run over your unit tests, and fix your
tests to go to 100% coverage. That's what I usually try to do in Perl

anyway.

What unit tests would you suggest for that bit of sample code, keeping in
mind that the original code is only 8 lines long.

Ben

 

[Ben Giddings]

On Thu, May 05, 2005 at 03:49:30AM +0900, Ben Giddings wrote:
[ snip ]

def do_something(foo)
if foo > 500
puts "Whoa, #{fo} is too many times! I can't do that!"
else
foo.times { |i| puts i }
end
end

do_something(ARGV[0])

Use a code coverage tool to run over your unit tests, and fix your
tests to go to 100% coverage. That's what I usually try to do in Perl anyway.

Pointers to coverage tools for ruby anyone?

I sent an email reply to this, but nobody followed up, but I'm really
interested to hear the answer.

The suggestion here was to write unit tests to make sure that the line with
the typo is caught ("Whoa, #{fo} ..." instead of "Whoa, #{foo} ...")

My question is this. If the "Ruby Way" to find this bug is by unit tests,
what suite of tests would be recommended for this snippet of code? Keep
in mind, that the original code is only 8 lines long.

Is it realistic to expect that someone would write more than 8 lines of
unit tests?

Ben

 

[Saynatkari]

On Thu, May 05, 2005 at 03:49:30AM +0900, Ben Giddings wrote:
[ snip ]

def do_something(foo)
if foo > 500
puts "Whoa, #{fo} is too many times! I can't do that!"
else
foo.times { |i| puts i }
end
end

do_something(ARGV[0])

Use a code coverage tool to run over your unit tests, and fix your
tests to go to 100% coverage. That's what I usually try to do in Perl anyway.

Pointers to coverage tools for ruby anyone?

I sent an email reply to this, but nobody followed up, but I'm really
interested to hear the answer.

I have a feeling I am answering to the wrong person, but:

Did you try Ryan Davis' zentest[1]? It automatically generates
tests for an existing codebase and should even take into account
any existing tests. I have not used it extensively but it might be
a good starting point?

The suggestion here was to write unit tests to make sure that the line with
the typo is caught ("Whoa, #{fo} ..." instead of "Whoa, #{foo} ...")

My question is this. If the "Ruby Way" to find this bug is by unit tests,
what suite of tests would be recommended for this snippet of code? Keep
in mind, that the original code is only 8 lines long.

Is it realistic to expect that someone would write more than 8 lines of
unit tests?

Ben

E

[1] http://www.zenspider.com/ZSS/Products/ZenTest/