🛡 سیاست تخصیص قطعی در #C: چرا کامپایلر از شما باهوش‌تر است؟
تا حالا براتون سوال شده چرا گاهی اوقات اگه به یه متغیر مقدار اولیه ندید، کامپایلر ازتون ایراد میگیره، ولی گاهی اوقات خودش بهش مقدار صفر یا null میده؟

این رفتار شانسی نیست! پشتش یه قانون مهم و امنیتی در #C به اسم "سیاست تخصیص قطعی" (Definite Assignment) خوابیده. این قانون میگه شما هرگز نمی‌تونید به حافظه‌ای که مقداردهی اولیه نشده، دسترسی داشته باشید.

1️⃣قانون برای متغیرهای محلی: خودت باید مقدار بدی!
وقتی یه متغیر داخل یک متد تعریف می‌کنی (Local Variable)، #C به تو اعتماد می‌کنه و وظیفه مقداردهی اولیه رو به عهده خودت میذاره. اگر قبل از اینکه مقداری بهش بدی، سعی کنی ازش استفاده کنی (بخونیش)، کامپایلر جلوت رو می‌گیره و خطای زمان کامپایل (Compile-time error) میده.

void MyMethod()
{
    int x;

    // ❌ خطای زمان کامپایل!
    // کامپایلر میگه: "تو به من نگفتی تو x چی بریزم!"
    Console.WriteLine(x); 
}

2️⃣قانون برای فیلدها و آرایه‌ها: همیشه مقدار دارند! ✨
اما برای اعضایی که طول عمر بیشتری دارن، مثل فیلدهای یک کلاس (چه static و چه instance) یا عناصر یک آرایه، داستان فرق می‌کنه.

اینجا NET runtime. برای جلوگیری از مشکلات، همیشه اون‌ها رو به صورت خودکار با مقدار پیش‌فرضِ نوع داده‌شون مقداردهی می‌کنه.

// آرایه‌ها همیشه با مقادیر پیش‌فرض پر میشن (برای int، صفره)
int[] numbers = new int[3];
Console.WriteLine(numbers[0]); // خروجی: 0


class Test
{
    // فیلدها هم همیشه مقدار پیش‌فرض میگیرن
    public static int X; 
}

// ...
Console.WriteLine(Test.X); // خروجی: 0

🤔 چرا این تفاوت وجود دارد؟
این یه تصمیم هوشمندانه برای امنیته. برای متغیرهای محلی، کامپایلر می‌تونه به سادگی و با قاطعیت تشخیص بده که شما فراموش کردید مقداردهی کنید و همونجا جلوتون رو بگیره. اما برای فیلدها و آرایه‌ها که چرخه حیاتشون پیچیده‌تره، مقداردهی خودکار توسط runtime، جلوی باگ‌های خطرناک ناشی از حافظه‌ی مقداردهی نشده رو می‌گیره.

پس این "ایراد گرفتن" کامپایلر، در واقع یه کمک بزرگه!
نظراتتون رو کامنت کنید! 👇
[C# Geeks Hangout]

🔖 هشتگ‌ها :
#CSharp
#Compiler
#DotNet #SoftwareEngineering