2010/4/14 Doriano Blengino <doriano.bleng...@fastwebnet.it>:
> And here we return on your idea about a good compiler - and it is mine
> idea too.
I don't want judge if the Gambas compiler is good or not, I feel that
I don't have the knowledge or experience required for do that. But, I
shared with you about the taste for a compiler that to say at
programmer: "This is right. That's not a good idea".
> First of all, I must say that I see your point. May be that all the
> issue is about personal style.
Yes, I have to admit that the style surely have influence in the
beauty criteria.
> But I did a quick research in my sources
> to let you see some example. I have little code in gambas - I use a lot
> C, about which I could have many examples but, as stated by someone
> other, it is forbidden to talk about C...
Ha! Is forbidden if you want that I can understand you. That is true :)
> First example. I store some bookmarks in a file by using the Settings
> class. Every bookmark is stored with a name like "Bmark1", "Bmark2" and
> so on, but I don't know how many of them are in the file. I know when
> there are no more values, instead. So the routine is the following:
>
> i = 1
> DO
> st = settings["Bmark" & i, ""]
> IF st = "" THEN BREAK
> men = NEW Menu(mnBooks) AS "chgBook"
> men.Caption = st
> INC i
> LOOP
> ...
>
> I could break out the loop using a logic variable, but this way I save a
> variable. Or I could test the variable in the loop construct, like this:
> ...
>
> but, as you see, there are TWO tests instead of one, and there is an
> added line of code.
I don't agree the criteria for saving one variable or one expresion if
it is not justified.
> May be that I am missing something, but the BREAK
> instruction is really useful here.
I don't say that BREAK (and other sentences) haven't utility, but that
isn't strictly necessary (perhaps I said unnecesary and this word may
be incorrect).
> The second example is a textual search on a treeview. If the user types
> some text, the selection is moved on the next item beginning with that
> text. If no more items satisfy the criterium, the search must start
> again at the top, but only once. So the code (there is a ME.MoveBelow()
> just before this code, I omitted it for simplicity):
>
> i = Len(searchstring)
> FOR tries = 1 TO 2 ' to search again from the top
> DO
> IF Upper(Left(ME.item.Text, i)) = searchstring THEN
> ' found item
> RETURN
> ENDIF
> IF ME.MoveBelow() THEN BREAK
> LOOP
> ME.MoveFirst
> NEXT
>
> Here, the FOR-NEXT is a quick way to execute some code for no more than
> two times...
> Again, I could have used a variable to store the result of the test, but
> I saved it...
I think that you use a structure FOR-NEXT that requires to you knowing
the amount of iterations to do. But, in this case you know that is
likely the number of iterations declared could be unnecesary. So,
conceptually, the correct loop would be one that allow control the
number of iterations.
There isn't a practical problem here. Just a conceptual consideration.
This doesn't matter if you understand what you do, like in you case.
But I think that's important for who is learning to programming. (I'm
sorry, I'm a teacher -and may be some day I have to teach
programming-). However, I don't want keep with older patterns of
thought. So, will I keep open my mind.
Now, image an hypothetical case in that you have to do several
conditional actions inside the loop. If you resolves it in that way,
the code become hard to understand.
Catch the joke:
FOR tries = 1 TO 2 ' to search again from the top
DO
IF Upper(Left(ME.item.Text, i)) = searchstring THEN
' found item
RETURN
ENDIF
IF ME.MoveBelow() THEN BREAK
IF (YOU DONT LIKE) THEN RETURN
IF (YOU WANT) THEN RETURN
IF (NOT ME ..). THEN BREAK
IF (YOU DONT...) THEN BREAK
IF (YOU WRITE IN C) THEN RETURN
...
LOOP
ME.MoveFirst
NEXT
Ok, I know you wouldn't write something like that. Just I want to
serve to show what I mean.
> I think that clearness and beatiful code is to prefer against speed, but
> only when speed is not an issue.
I agree.
> In the text-search example speed *is* an issue. Never tried to open a
> directory with some 30000 files in it, and perform a textual search?
Ok, I agree.
> I would do so:
>
> PRIVATE FUNCTION ScanTab(IdCaption AS String) AS Byte
> DIM a AS Byte = 0
>
> WHILE a< TabStrip1.Count
> if TabStrip1[a].Text = IdCaption then return a
> INC a
> WEND
> return -1
> END
> PRIVATE FUNCTION ScanTab(IdCaption AS String) AS Byte
> DIM a AS Byte
>
> for a = 0 to TabStrip1.Count-1
> if TabStrip1[a].Text = IdCaption then return a
> next
> return -1
> END
If you have to do tests (like unit tests) and you have routines with
multiple exit points, maybe you will have some coverage problems. What
do you think?
> No, the issue is different. Giving any language and any cpu, every
> operation has a cost. Comparing two times the same two strings is a cost
> which can be avoided. *If* the speed is not important, *and* the code is
> more clear, *then* one can even do it [compare two times the same data].
[compare two times the same data] I think that to say this Isn't fair,
because the logical test just after a loop often do a test "one 2
one", ie one data value against one test value. So, almost there's no
cost to access to one data item.
I would say that, "if" the speed is important, "and" code not become
unclear, you can do efforts to not add one test more (or to keep
worried about performance).
> ...
> Why should be ugly to modify the
> control variable of a loop? Perhaps because, historically, it was
> forbidden... so the teachers say the scholars it is ugly (or wrong), and
> the scholars, when turned teachers themselves, continue to say that it
> is ugly, and so on.
Yep, I think these things have influence.
> After citing "other languages", I came back to
> gambas saying "in other languages this is not stressed the same way
> (basic, for example)". I wanted to say that in basic, and hence in
> gambas too, it is possible to modify the value of the control variable.
> Who thinks this is ugly, simply has to abstain from it...
Except that often isn't a good thing for the students. Someone could
say that everybody can use the sentence GOTO, and if you are a good
programmer you will haven't problems.
I think that the subject here is identify practices that have
potential to bring problems.
>> FOR EACH really iterates through all items, so there's only way to
>> stop the loop when it's goal is achieved, is by the BREAK sentence
>> used in a conditonal sentence inside the loop. But it might think that
>> if it is necessary to do this, then the iterative structure FOR EACH
>> is not adequate.
>>
> Yes, I follow your mind. It's your style, mostly pure... I try to be
> more pure - but often I choose the quick way; so, break and continue are
> welcome for me.
I haven't objection with this, if who do this really knows what is
doing, ie if then the code is easily understandable, and if this not
brings errors.
> This is the kind of things I like to speak of - other people on this
> list have a different point of view about this. I beg for mercy in a
> pre-emptive, anticipative way.
Me too.
Regards.
--
Fabián Flores Vadell
www.speedbooksargentina.blogspot.com
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
