ऐसे कुछ (काफी दुर्लभ) मामले हैं जिनमें जोखिम है:
एक चर का पुन: उपयोग करना जिसका पुन: उपयोग करने का इरादा नहीं है (उदाहरण 1 देखें),
या दूसरे के बजाय एक चर का उपयोग करना, शब्दार्थ के करीब (उदाहरण 2 देखें)।
उदाहरण 1:
var data = this.InitializeData();
if (this.IsConsistent(data, this.state))
{
this.ETL.Process(data); // Alters original data in a way it couldn't be used any longer.
}
// ...
foreach (var flow in data.Flows)
{
// This shouldn't happen: given that ETL possibly altered the contents of `data`, it is
// not longer reliable to use `data.Flows`.
}
उदाहरण 2:
var userSettingsFile = SettingsFiles.LoadForUser();
var appSettingsFile = SettingsFiles.LoadForApp();
if (someCondition)
{
userSettingsFile.Destroy();
}
userSettingsFile.ParseAndApply(); // There is a mistake here: `userSettingsFile` was maybe
// destroyed. It's `appSettingsFile` which should have
// been used instead.
इस जोखिम को एक गुंजाइश शुरू करके कम किया जा सकता है:
उदाहरण 1:
// There is no `foreach`, `if` or anything like this before `{`.
{
var data = this.InitializeData();
if (this.IsConsistent(data, this.state))
{
this.ETL.Process(data);
}
}
// ...
// A few lines later, we can't use `data.Flows`, because it doesn't exist in this scope.
उदाहरण 2:
{
var userSettingsFile = SettingsFiles.LoadForUser();
if (someCondition)
{
userSettingsFile.Destroy();
}
}
{
var appSettingsFile = SettingsFiles.LoadForApp();
// `userSettingsFile` is out of scope. There is no risk to use it instead of
// `appSettingsFile`.
}
क्या यह गलत लगता है? क्या आप इस तरह के वाक्य रचना से बचेंगे? क्या शुरुआती लोगों द्वारा समझना मुश्किल है?
7
क्या आप तर्क दे सकते हैं कि प्रत्येक स्वतंत्र "स्कोप ब्लॉक" के बजाय इसकी अपनी विधि या कार्य होना चाहिए?
—
डैन पिचेलमैन
मैं कहूंगा कि "अक्सर" उतना अच्छा नहीं है जितना कि इसे लागू किया जा सकता है (लेकिन शायद "डिज़ाइन" समस्या नहीं है)। कभी-कभी डिजाइन द्वारा, यह अपरिहार्य है (उदाहरण के लिए अपवाद / संसाधन स्कूपिंग)।
—
जस्टिन सीसी