Spelling mistakes!

[bb]

Terry> But not faster than use a dict server! Why not just use (e.g.)
Terry> kdict?


Sybren> Lame excuse. If you don't have something but you do want to
use Sybren> it, you get it.

I don't think I want it badly enough to figure out how to get it to work
on
my Mac. (I'm assuming the "k" prefix implies it's part of KDE.) I'm
happy to continue googling for words I want defined.

kdict is, as you correctly assume, part of KDE. But it's just an interface
to query a dict server. And there are command line clients for that as
well.

 

[Steve Holden]

I've spent hours trying to find a bug that was a simple spelling
mistake.

in an init method I declare a variable self.someLongName

later in a different method of the class I use
self.sumLongName
Now I really meant self.someLongName.
In fact I don't want a variable called sumLongName.
Frankly how are you ever to know if this type of error is occuring?

pychecker

 

[Antoon Pardon]

Since
1- The unit test will obviously fail in this case, telling you in which
code unit the issue is

Not in general. Several unit tests can fail. And if you have a variable
spelled differently, the code unit that fails is not dependant on which
occurence was spelled correct and which was spelled wrong. So it is very
well possible that the code unit with the issue is the one in which the
variable is spelled correctly.

2- Unit Test favor extremely modular coding with very short increments
(as a somewhat extreme example, Robert Martin gets nervous if his test
suites don't validate the code every 5 minutes, you usually don't write
200 lines and their unit tests in 5 minutes)

I have a unit test that takes at leas 2 minutes. If I would validate
each five minutes I wouldn't get any work done.

We can deduce that unit testing will detect the typo extremely early and
that the field of research will span about 5 to 10 lines, making the
tracking quite easy to perform.

Not necessary. You may have started with misspelling the variable and
spelled it correctly in your last edit session. Doing your research
in the 5 to 10 lines last edited will then reveal nothing.

 

[Terry Hancock]

Op 2006-01-06, Terry Hancock schreef


I don't think unit tests are that helpfull in this case.
Unit tests help you in finding out there is a bug, they
don't help that much in tracking down a bug.

I for some reason a person is reading over the difference
between sumLongName and someLongName and doesn't notice
the different spelling in his source a unit test won't
be of much help.

Well, if you are doing fairly frequent unit tests, then you
will have written a unit test to test the "someLongName"
method, and if you manage to type "sumLongName" in BOTH the
code and the unit test, then there must be some Freudian
reason you really did want to use "sumLongName". ;-)

It's a bit like the standard practice of making you type a
password twice. In fact, most of the common "bug avoidance"
methods in programming all come down to this -- you have to
type the same thing twice in two different places to get
the result.

C and C++ make you do declarations -- so you have
to mention the name before you can use it. You have to type
the variable names twice.

Interfaces define the "publically viewable" parts of a
class, then you have to actually create them in a separate
class definition. You have to type the methods twice.

In unit testing, you write the code, then write code to test
the code, which must correctly identify the methods in the
code. So you have to type 'everything' twice.

And so on.

The ideal of "don't repeat yourself" seems to get
nudged out by "repeat yourself exactly once" when it's
really important to get it right. ;-)

It's really just a fancy way to force you to proof-read your
own work carefully enough (which is tricky because you
tend to ignore stuff that's too repetitious).

Cheers,
Terry

 

[Peter Hansen]

Xavier Morel enlightened us with:

Given the assumption the same mistake hasn't been made in the test as
well.

If the spelling in the test matches the spelling in the code, then
obviously it isn't a mistake at all! <0.5 wink>

-Peter

 

[Steve Holden]

Terry Hancock wrote:
[...]

The ideal of "don't repeat yourself" seems to get
nudged out by "repeat yourself exactly once" when it's
really important to get it right. ;-)

I suppose most readers aren't old enough to remember the punch card
days, when you would hand your work in on coding sheets to the punch
room and it would be punched onto cards using huge machines (anyone
remember the 026 and 029 punches?).

Before you got the cards back they were processed twice: one operator
would actually punch the cards, and another would re-key the same input
on a verifier machine that alerted them to any differences between what
was on the card and what was keyed.

It's really just a fancy way to force you to proof-read your
own work carefully enough (which is tricky because you
tend to ignore stuff that's too repetitious).

That's why two different operators would do the punching and the verifying.

regards
Steve

 

[Dennis Lee Bieber]

I suppose most readers aren't old enough to remember the punch card
days, when you would hand your work in on coding sheets to the punch
room and it would be punched onto cards using huge machines (anyone
remember the 026 and 029 punches?).

FORTRAN and COBOL on 029s -- and had to submit the school ID card to
check-out a drum; coding a drum card was actually taught in the COBOL
class.

Had to be in a second year course before one obtained an account
that would work on the Hazeltine 1200s...
--

 

[Antoon Pardon]

Well, if you are doing fairly frequent unit tests, then you
will have written a unit test to test the "someLongName"
method, and if you manage to type "sumLongName" in BOTH the
code and the unit test, then there must be some Freudian
reason you really did want to use "sumLongName". ;-)

Who says someLongName is a method?

It's a bit like the standard practice of making you type a
password twice. In fact, most of the common "bug avoidance"
methods in programming all come down to this -- you have to
type the same thing twice in two different places to get
the result.

C and C++ make you do declarations -- so you have
to mention the name before you can use it. You have to type
the variable names twice.

But that is not an accepted idea here in c.p.l. I also find
it strange that redundancy via type declarations is so hard
resisted here and is then defended with the argument it
isn't needed is you test sufficiently (with unit tests)
which is also a kind of redundancy.

Interfaces define the "publically viewable" parts of a
class, then you have to actually create them in a separate
class definition. You have to type the methods twice.

In unit testing, you write the code, then write code to test
the code, which must correctly identify the methods in the
code. So you have to type 'everything' twice.

But you don't type attribute names twice in unit tests,
because attributes are in general implementation details
that are of no concern to the tester. So unit tests can
not introduce the redundancy to find out a missed spelled
attribute in some methods.

The ideal of "don't repeat yourself" seems to get
nudged out by "repeat yourself exactly once" when it's
really important to get it right. ;-)

It's really just a fancy way to force you to proof-read your
own work carefully enough (which is tricky because you
tend to ignore stuff that's too repetitious).

Yes and you also tend to read over your own spelling errors.

 

[Mike Meyer]

FORTRAN and COBOL on 029s -- and had to submit the school ID card to
check-out a drum; coding a drum card was actually taught in the COBOL
class.

Pretty much everything on the 029. Like you, I had to punch things
myself. And had a drum card with one track for FORTRAN and a second
for ALGOL.

Of course, I was employed to work with them. At one point, I actually
"helped" someone do data processing with the card sorter.

<mike

 

[skip]

Steve> I suppose most readers aren't old enough to remember the punch
Steve> card days, when you would hand your work in on coding sheets to
Steve> the punch room and it would be punched onto cards using huge
Steve> machines (anyone remember the 026 and 029 punches?).

I do remember the IBM Model 29 punch card machines, though as a student
nobody was there to punch my cards or verify them for me... :-(

Skip

 

[Hans Nowak]

But you don't type attribute names twice in unit tests,
because attributes are in general implementation details
that are of no concern to the tester. So unit tests can
not introduce the redundancy to find out a missed spelled
attribute in some methods.

I wouldn't call attributes "implementation details", at least not in
Python. And while it is true that unit tests might not find the
misspelling *directly* (i.e. you rarely test if you have misspelled
something), your tests should definitely show unexpected behavior and
results, if that attribute is of any importance. Otherwise there's a
loophole in your tests.

 

[Antoon Pardon]

I wouldn't call attributes "implementation details", at least not in
Python. And while it is true that unit tests might not find the
misspelling *directly* (i.e. you rarely test if you have misspelled
something), your tests should definitely show unexpected behavior and
results, if that attribute is of any importance. Otherwise there's a
loophole in your tests.

But now we are back to my first doubt. Sure unit test will be
helpfull in finding out there is a bug. I doubt they are that
helpfull in tracking the bug (at least this kind).

 

[skip]

Antoon> But now we are back to my first doubt. Sure unit test will be
Antoon> helpfull in finding out there is a bug. I doubt they are that
Antoon> helpfull in tracking the bug (at least this kind).

This thread seems to be going in circles. Maybe it's time to simply drop it
and move onto other things. The clear evidence from people who admit to
having practical experience using unit tests (or pylint or pychecker) is
that catching misspellings is an extremely shallow bug to find and fix if
you use the tools at your disposal.

Skip

 

[Terry Hancock]

Terry Hancock wrote:
[...]

The ideal of "don't repeat yourself" seems to get
nudged out by "repeat yourself exactly once" when it's
really important to get it right. ;-)

I suppose most readers aren't old enough to remember the
punch card days, when you would hand your work in on
coding sheets to the punch room and it would be punched
onto cards using huge machines (anyone remember the 026
and 029 punches?).

Punch cards were still in use for students at The University
of Texas as late as 1986, so I'm old enough to remember.
(Yes, the CS department had terminals and editors, but some
classes still required cards -- I guess it was supposed to
"build character" ;-)). However, I wasn't a CS student, so
I never had to use one. ;-) We had VT-220 terminals in the
Astronomy computer lab, which is where I first learned to
use Unix, Fortran, and other fun things.

 

[Antoon Pardon]

Antoon> But now we are back to my first doubt. Sure unit test will be
Antoon> helpfull in finding out there is a bug. I doubt they are that
Antoon> helpfull in tracking the bug (at least this kind).

This thread seems to be going in circles. Maybe it's time to simply drop it
and move onto other things. The clear evidence from people who admit to
having practical experience using unit tests (or pylint or pychecker) is
that catching misspellings is an extremely shallow bug to find and fix if
you use the tools at your disposal.

I have no problem with the statement:

"Spelling errors are easy to fix if you use the tools at your disposal."

But that statement doesn't limit the tools to unit testing.