Re: newbie: need inspiration

From: Stachu 'Dozzie' K. (dozzie_at_dynamit.im.pwr.wroc.pl.nospam)
Date: 08/30/05 

Date: Tue, 30 Aug 2005 18:30:22 +0000 (UTC)

On 30.08.2005, Ed Morton <morton@lsupcaemnt.com> wrote:
>
>
> Stachu 'Dozzie' K. wrote:
><snip>
>> In my code script waits for user input. Value holding input isn't really
>> overloaded (at least at this point), is it? Now look closer at the code:
>> why should I introduce one more variable? Loop should end when user
>> enters some kind of input, or rather loop should be repeated until the
>> user enters something valid, thus the finish condition is dependent on
>> that input. Why don't use this input explicitly?
>
> The loop should end because the user input a value, but it should not
> end based on a specific value of the variable that holds the users
> input. That would be overloading the variable (it now has 2 purposes -
> controlling the loop and holding the input) which leads to coupling. For
> example, using the 2 styles we used earlier, if I have these 2 programs:
>
> a)
> login=
> while [ -z "$login" ]; do
> echo "enter a login"
> read login
> done
>
> b)
> waiting4input=true
> while [ "$waiting4input" = true ]
> do
> echo "enter a login"
> read login
> if [ -n "$login" ]
> then
> waiting4input=false
> fi
> done
>
> What if I have to enhance my program in future to require a password in
> addition to a login? I'd have to change them as follows (assume they do
> something with the login and password after the loop):
>
> a)
> login=
> passwd=
> while [ -z "$login" -a -z "$passwd" ]; do # or just test passwd
> echo "enter a login"
> read login
> if [ -n "$login" ]
> then
> echo "enter a password"
> read passwd
> fi
> done

And that's exactly what I want to see in the code. I see clearly _when_
the loop ends. Not because there is somewhere assignment instruction
which changes value of waiting4input, but because no login or no
password was given.

> b)
> waiting4input=true
> while [ "$waiting4input" = true ]
> do
> echo "enter a login"
> read login
> if [ -n "$login" ]
> then
> echo "enter a pasword"
> read passwd
> if [ -n "$passwd" ]
> then
> waiting4input=false
> fi
> fi
> done
>
> Notice that to enhance "a" I had to add 6 lines and modify 1 (which was
> tha main loop control line!), while to enhance "b" I had to add 5 lines
> and just indent 1.

Not too big difference, huh? (Yeah, you told that later)
And you count adding indent as simple operation. It's not simpler/faster
than adding something in one line, even if you use a really good editor
(Vim, Emacs).

> Obviously this is a simple example, so the differences between the 2
> approaches are small, but the point is there ARE differences that you
> can measure in the impact of adopting either approach and that as the
> functionality required of your code increases, so does the degree of
> difference between the 2.

But if you need to add very sophisticated condition, then your solution
starts hiding that condition, which is very bad for readability.
I woulnd't say that effort put into implementing new functionality
according to my way doesn't pay.
And simpler cases, where single "do_until_something_magical_happens"
doesn't degrade readability, are not too complicated and effort is
similar for both kinds of conditions.

><snip>
>>
>> In general I would rather see clearly real finish condition instead of
>> something masked by strange variable like "do_next_iteration" (I don't
>> mean just the name of variable). I don't need to look where that
>> "do_next_iteration" was set to false.
>>
>> Of course there are cases when a set of such variables improves
>> readability (or even allows to write finish condition), but this takes
>> place for really complex conditions. And even then I'd like to see few
>> variables, each responsible for small condition, for example
>> "file_exists", "user_is_superuser", "user_has_rights" can compose
>> #v+
>> if (file_exists && (user_is_superuser || user_has_rights))
>> remove_file;
>> #v-
>> Single variable "file_can_be_deleted" does not satisfy me, if it is used
>> only in one condition (if it's used many times, then of course such
>> variable has its sense).
>
> Yes, it's all about picking the right level of abstraction for your code
> and that depends on many current and expected future aspects of your
> requirements, architecture, etc. It's definitely art, not science.

Aha. And hence there are different trends out there. As we see, in this
case we belong to different trends. 

-- 
Feel free to correct my English
Stanislaw Klekot

Relevant Pages

  • Re: newbie: need inspiration
    ... Value holding input isn't really ... Loop should end when user ... That would be overloading the variable (it now has 2 purposes - ...
    (comp.unix.shell)
  • Re: C# Command to Wait a Specified Period of Time
    ... But the key to use the query syntax is you don't do the for each loop yourself, instead you state what you want, not how to do it. ... I'm sure that once one gains experience with these newer language constructs that they do enhance "readability" - for the people who know and use them. ... But don't go around saying that a code block consisting of delegates and anonymous methods is "more readable" than a simple "for loop". ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: std::vector : begin, end and insert - Using Objects instead of ints
    ... When there's a choice, prefer preincrement to postincrement, because pre ... The thing is, efficiency can be measured objectively, while "readability" ... split the operation into two statements, e.g. when erasing a list iterator. ... certain kind of loop that omits stmt3 in a for-loop header when you decide ...
    (microsoft.public.vc.mfc)
  • Re: Login into secure web site and download data into worksheet?
    ... Sub Login() ... Cells(RowCount, ColCount) = Col.innertext ... > DoEvents ...
    (microsoft.public.excel.programming)
  • Re: wich is faster
    ... On the premature optimisation front - it has to be a judgement call by ... an "& 1" and a simple loop dividing n by odd numbers from 3 to sqrt. ... I do not accept that readability is an excuse ...
    (comp.programming)