>> I don't agree the criteria for saving one variable or one expresion if >> it is not justified. >> > Well, perhaps my daily work with little CPUs (some have 32 bytes of > ram!) drives me to professional bias, but why use a variable if can be > avoided? There is more than one reason for this (reported without an > order). One: variables have to be declared at the beginning of a block; > when I write code, if I want to use a variable I must go back to the > start of the code and add the declaration, leaving the old "road of my > mind". Then I must go back to the relevant part and concentrate again on > the code.
I don't see the problem here. When you think about create a variable (or any other memory structure), you never let to think about your algorithm. In fact, if the language require previous variable declaration is a good thing because forces to think about on resources you will use and how you will do that. I think that the choices about memory structures is one of the critical parts when you write an algorithm. So, when you think about variables far away of divert attention, actually you are deepening your understanding about the problem and your algorithmic solution. > Two: saving a state to later break a loop is less > straightforward than doing it "in place". If the logic of an algorithm > is "concentrated" in a single point, instead of being spread around, it > is easier to revise - at least for me. > > Three: I think that fast > algorithms are always better than slow ones. I think that if the speed is a requeriment, that's right. But if not, just is right if is to easy to do. So, not always a faster algorithm is better. Let me quote to Donald Knuth when he said "premature optimization is the root of all evil (or at least most of it) in programming". > It is the duty of a good > programmer to write good code: and good code is fast and easy to read. I believe that a good code is one that is simple, and to achieve this goal at least must (sure I forget something): - Uses the correct structures of memory and control - Have high cohesion and low coupling - Be correctly modularized - Uses good names - Be written in order that it is easy to understand it > Perhaps, if I was a teacher, I would say different things. But teachers > sometimes are a little distant from the reality; and scholars will face > it later - when they will be programmers. The industry insists in that the most important things are compliance of requirements and easy maintenance. > That said, using a variable is a cost (even more for interpreted > languages like gambas). Well - we must understand each other. By no mean > I want to say that using variables is awful - is a technique with pros > and cons. Easy, I understand you. > if (i<TabStrip.count) and (tabstrip[i].caption blahblahblah) THEN > blahblahblah > > This is a logical mislead, because it puts together two unrelated > concepts: the test on the relevant thing (we look for caption), and a > "good precaution" which has little to do with the algorithm. In fact, I > would rewrite it as > > if i<tabstrip.count then if tabstrip[i].caption... > > There is no difference in the final (machine) code, but the second > statement looks to me more explanatory. I agree. > And, to be sincere, there is > more. The ambiguity of the first statement is well stressed in other > languages (sorry, they exist), where sometimes there is no warranty > about the order of evaluation of expressions. For whatever reason, a > compiler could evaluate tabstrip[i].caption *before* tabstrip.count. > And, of course, the compiler is right - the AND operation is commutative > (the two terms can be swapped), like addition and multiplication. Back > to gambas - I don't know if the documentation says anything about > short-circuit and things like that. May be we can assume it as a > standard, that modern languages always do short-circuit, but the concept > remains. I agree. > function movefile(src, dst as string) as boolean > result = false > if not exists(src) then return > if not open_and_read(src) then return > close(src) > if not open_and_write(dst) then return > close(dst) > result = true > end > > Now comes personal taste. The second routine, for you, is a joke. Oh, no. The joke was: IF (YouWriteInC) THEN RETURN. Maybe, we not share the same humor sense. > For > me, it looks simpler, shorter, and faster. The only problem I see are > those repeated "not" and "return". They are ugly to see, but very clear > in saying "if this operation fails, then stop". The code coverage should > be simpler to do, but I am not really sure. When I have to write many logical tests, I separates them in a new function. That allow me keep the code short and self explanatory. I do this in a extremist way especially when I want to anybody can understand my code. I know this is even more expensive than using a variable. I don't care, I never seen a penalization over performance for that, and if I have to do some optimization, I would do later. >> I think that the subject here is identify practices that have >> potential to bring problems. >> > GOTOs were the only mean to control the program flow, once upon a time. > When some genius broke the rules and invented structural programming, > GOTOs were rewarded as evil, and we are still in the long wave of this > thought. > But Pascal (and C, - sorry - the most important language of all times, > until now), still retained GOTOs. Strange... may be that they are, after > all, not so evil? Clearly, this was done to maintain backward compatibility (the root of the rest of evils). > We don't want spaghetti outside our food, but there is > a way in between - ok for a GOTO, when you have a reason for that. > Practices that have potential to bring problems are not simple things > like "using GOTO", or "using object oriented programming". The issue is > far more complicated. Going on, I would say that, in certain cases, it > *is* an error to not use GOTOs. In some situations, it is an error to > use objects. And so on. Nothing is perfect, and nothing is totally bad. I understand. Maybe, you express that with too much relativism. > Well. I really enjoyed to discuss with you. Because I feel that we both > have slightly changed our mind - we have had an improvement. Even If we > didn't change our thought, it seems to me that we, at least, had > understand each other. Not a bad thing. This was a productive discussion to me. I learned new things. 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
