[lnkForumImage]
TotalShareware - Download Free Software

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


 

Forums >

comp.lang.ruby

Re: Comments Are More Important Than Code

Lorenzo Jorquera

4/28/2005 8:31:00 PM

Really sorry for the mangled quotes

I meant

Eric Schwartz wrote:
"Dave Fayram" writes:
> I'd much prefer to see (this is pseudo and formatted for short lines,
> so bear with me):
>
> def my_appropriately_named_test
> long_name = "This name is far too long."
> assert_raise Module::InputValidationError,
> @inst.the_func( long_name )
> end
>
> Then I can test it. If I ever make a change and accidently invalidate
> it, then I'll know. If we ever eliminate that restriction, the test
> will break and we'll know to update it.

>How will you know if it's the test or the code that's broken? Without
>comments in the_func telling you why that exception is raised, you
>could end up fixing the wrong problem.

When you run your unit tests very often (tipically several times an hour) you will know exactly why the test failed.

>A not-uncommon case is that you have to call into a 3rd-party C or C++
>library (the infamous Jukebox example in Pickaxe 1, for instance), and
>that library enforces some restrictions that aren't necessarily
>obvious. Let's say we have implemented the infamous Jukebox
>application only supporting ASCII song titles, and we now want to add
>support for UTF-8. Since it's been some time, and the original coder
>has moved on to another company, we've forgotten that libjukebox
>doesn't work with, say, UTF-8.

>If I had a comment in the_func saying:

>/* libjukebox can't handle songs with UTF-8 encoded titles */
>raise Module::InputValidationError if has_utf8?(title)

>That helps me a lot more than just:

>raise Module::InputValidationError if has_utf8?(title)

>In the latter case, I might just think, "Okay, they didn't want to
>support UTF-8 in revision 1, so now i can take it out." In the former
>case, I know *why* they didn't support it, and it wasn't because they
>were lazy, or pressed for time. So instead of removing the code, and
>its associated test, I know to ask Jukebox, Inc. for a new library
>that does support UTF-8.

In this case, I would prefer a more especific exception:

raise Module::LibjukeboxCantHandleUTF8 if has_utf8?(title)

Lorenzo.





---------------------------------
Do You Yahoo!?
Todo lo que quieres saber de Estados Unidos, América Latina y el resto del Mundo.
Visíta Yahoo! Noticias.



---------------------------------
Do You Yahoo!?
Todo lo que quieres saber de Estados Unidos, América Latina y el resto del Mundo.
Visíta Yahoo! Noticias.
1 Answer

Stephen Kellett

4/28/2005 11:44:00 PM

0

In message <20050428203052.4537.qmail@web32207.mail.mud.yahoo.com>,
Lorenzo Jorquera <lorenzo_jorquera@yahoo.com> writes
>>How will you know if it's the test or the code that's broken? Without
>>comments in the_func telling you why that exception is raised, you
>>could end up fixing the wrong problem.
>
>When you run your unit tests very often (tipically several times an
>hour) you will know exactly why the test failed.

Wrong answer. You still are not documenting the "why".

Comments tell you what the code *SHOULD* be doing, not *WHAT* it is
doing. So many people responding to this thread seem oblivious to this
obvious, yet subtle and important fact.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.d...
RSI Information: http://www.objmedia.d.../rsi.html