Re: Perl Best Practices book: is this one a best practice or a dodgy practice?

This is definitely not the best practice. One of the most important transformation of programming through the years is that: small tricks are no longer encouraged. Even the good tricks are not encouraged, because we want the programs to be easily understandable, not to say those ones that can cause various troubles.

The problem in this case is not really about whether the pogram is re-runnable, but about the fact that it corrupts your data. To make it more clear, let's talk more about re-runability

The best type of programs can be rerun from the breaking point without any extra manual action, or the minimum of manual action, such as to remove or fix the data that broke the program. Once you fix the bad data, you can rerun the program, and it will pick up from where it failed. None of the data that has been processed will be reprocessed, unless it is logically required so.
The okay type is that, the program does not know how to pick up from the broken point, so that you have to take manual actions to not only fix/remove the bad data, but also reverse what had been processed before it broke (much more manual actions than the first type). After all those manual execises, you can run the program again, but most likely it will start from the very beginning of the process, not the break point. If this program is time-consuming, you waste lots of time. This kind of program is called "not re-runnable".
The worst type is what we have seen in this case, the problem is much more than whether it is re-runnable - it corrupts your data.

Comment on Re: Perl Best Practices book: is this one a best practice or a dodgy practice?

Replies are listed 'Best First'.
Re^2: Perl Best Practices book: is this one a best practice or a dodgy practice? by TheDamian (Vicar) on Sep 03, 2005 at 04:56 UTC
The problem in this case is not really about whether the program is re-runnable, but about the fact that it corrupts your data. Neither of which is what the original recommendation is about. That recommendation, as it appears in "Perl Best Practices" is: In-situ Arguments Allow the same filename to be specified for both input and output. And that most definitely is a best practice. The issue raised here is that one of the two solutions suggested in the book is apparently more limited in applicability than I indicate in the text (a deficiency I have already mentioned that I'll be remedying as soon as I can). Now it may well be that "Perl Best Practices" would benefit from the addition of an extra guideline; one that suggests using a transactional approach to avoid corrupting data. But that's only peripherally related to this guideline. It should definitely be a separate suggestion, since the problem of data corruption is not unique to opening the same file twice.	[reply]
Re^3: Perl Best Practices book: is this one a best practice or a dodgy practice? by mikeraz (Friar) on Sep 09, 2005 at 14:38 UTC
My copy is at home, as is my co-worker's copy. Hopefully I'm not saying something fundamentally stupid here. Perhaps the solution to this entire muddle is to have as the first line of commentary after that best practice read: Allowing the same name ensures your program will operate correctly when users, inevitably, do specify the same filename. Be Prepared, as the teach Boy Scouts 1. 1 If you have trouble remembering the Scout's famous motto, seek out the Tom Lehrer recording and have that song play through your head while coding. Be Appropriate && Follow Your Curiosity	[reply]


"be consistent"
	PerlMonks