|Problems? Is your data what you think it is?|
> While "Because we say so and we know Perl and you don't
> and you'll thank us all one day and we won't help you if
> you don't help yourself by doing it etc" is an accurate
> if gramatically awful response it does not explain how
> it helps. Giving short examples makes it obvious but
> adds length.
First off, in regard to length, I'm going to add my voice to those who say that strict should be in a separate document from warnings and diagnostics. That would help with the length problem, and some people such as myself who understand warnings perfectly are a big hazy on the value of strict. Splitting the thing up would make it easier to read only the needed document.
Second, I want to disagree with your assessment that the short examples make the value obvious, specifically in the case of strict. I don't have the level of experience of some people here, but I'm not exactly a complete Perl newbie either, and the value of strict (especially strict vars) is not evident to me. Further, I was under the impression from the Camel (2nd ed) that there is no consensus among the authors as to whether use strict is really useful, let alone important, and that it was kept optional precisely because some experienced people don't like it. What I still want to understand is the reasoning behind people who consider it so important, but neither the example nor the explanation helps. If anything, the example makes matters worse because any newbie can see that problem would have been caught by warnings, without any need for strict. You need an example of something warnings would not have caught, that strict does prevent, that's clearly an error but could at least potentially be hard to spot.
I want to understand what people see in strict, but this node as it currently stands isn't doing that for me.
In reply to Re: Re: Use strict warnings and diagnostics or die