> I suppose it's up to the programmer.
It is, provided the programmer is remembering that the audience is not him/herself buty the many other programmers who will have to read and maintain the code over the years to follow. So if the programmer genuinely believes that one form is clearer then its fine, or if there is a real need to optimise. > Personally, I find something like this: > > variable += something > > a lot easier to read than Fine if the something is a constant (or at least fixed at the time of assignment) but if its really: variable += something() and something() might return a NULL or non numeric value then you have a much harder bug to find than if you split it. > For me, it's just another variable I have to worry about > allocating/deallocating/seeing if it's used anywhere > else/accidentally using when I shouldn't. If its not a pointer you don;t need to worry about allocation. As for usage, yes that's an issue but a well chosen name helps prevent misuse (unless you have psychopathically destructive programmers!). Unless you are programming a microcontroller the amount of memory taken up by an int or long in C is hardly ever an issue. > ...James asked about memory management Yes, but specifically about dynamic memory(pointers) not static. > ...depending on the program you're using and the size > of your inputs, it actually can make a difference. Absolutely, and as I said, you can optimise C to the point of obscurity but you should only do so once you have proved that there really is a need and after trying other techniques like redesigning your data structures and algorithms. Fine tuning code should be the last resort not the first. And often it's better to drop into assembler for the critical section. Clear assembler is much easier to maintain than obscure C. Alan G.
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
