تعریف، امضا و قرارداد خروجی

در الگوی TryParse، ورودی بررسی و نتیجه از طریق پارامتر out برگردانده می‌شود. مقدار بازگشتی bool نشان می‌دهد تبدیل به int موفق بوده است. در موفقیت result مقدار تبدیل‌شده را دارد و در شکست نباید به‌عنوان داده معتبر استفاده شود. این قرارداد برای مرزهای غیرقابل‌اعتماد، مانند فرم و فایل، خوانا است و مسیر شکست را به بخش عادی منطق برنامه تبدیل می‌کند.

امضاهای مهم

int.TryParse(string? value, out int result);
    int.TryParse(string? value, NumberStyles style, IFormatProvider? provider, out int result);
    int.TryParse(ReadOnlySpan<char> value, NumberStyles style, IFormatProvider? provider, out int result);

تحلیل فنی و طراحی صحیح

استفاده حرفه‌ای از int.TryParse() با تشخیص مرز اعتماد آغاز می‌شود. متنی که کاربر، فایل CSV، پارامتر URL یا سامانه بیرونی تولید کرده است می‌تواند خالی، ناسازگار یا مخرب باشد. TryParse یک سد نحوی فراهم می‌کند، اما طول ورودی، قواعد دامنه، مجوز دسترسی و ارتباط مقدار با سایر فیلدها همچنان باید کنترل شود.

در حوزه تعداد موجودی، شماره صفحه، سن و شناسه‌های کوچک باید میان «قابل تبدیل بودن» و «قابل پذیرش بودن» فرق گذاشت. ممکن است متن به‌درستی تبدیل شود اما مقدار خارج از بازه سیاست سازمان، شناسه ناشناخته یا تاریخ غیرمجاز باشد. این جداسازی پیام خطای دقیق‌تر، آزمون واحد ساده‌تر و تغییر قواعد کسب‌وکار بدون دستکاری Parser را ممکن می‌کند.

در API بهتر است خطای تبدیل به پاسخ ساخت‌یافته شامل نام فیلد و کد خطا تبدیل شود. در Import نیز ردیف‌های خراب را همراه شماره خط و دلیل رد در گزارش جدا نگه دارید. حذف خاموش خطاها ممکن است جمع گزارش یا تصمیم مدیریتی را تحریف کند؛ بنابراین شاخص کیفیت داده بخشی از خروجی فرایند است.

Culture باید از قرارداد واقعی داده بیاید. فایل ماشینی معمولاً با InvariantCulture و قالب ثابت امن‌تر است، درحالی‌که فرم محلی باید فرهنگ انتخاب‌شده کاربر را به کار گیرد. اتکا به CurrentCulture سرور می‌تواند پس از جابه‌جایی محیط، به‌روزرسانی کانتینر یا اجرای تست روی رایانه دیگر نتیجه را تغییر دهد.

از نظر امنیت، int.TryParse() تنها تبدیل را انجام می‌دهد و جای اعتبارسنجی مجوز، محدودیت طول، Allowlist یا کنترل وجود رکورد را نمی‌گیرد. برای تعداد موجودی، شماره صفحه، سن و شناسه‌های کوچک ورودی بسیار طولانی را پیش از پردازش محدود کنید، اطلاعات حساس را در لاگ ننویسید و پیام داخلی استثنا را مستقیماً به کاربر نشان ندهید.

از نظر نگهداری، بهتر است فراخوانی‌های تکراری در Parser یا Value Object دامنه‌ای متمرکز شوند. آن جزء می‌تواند Culture، بازه مجاز، پیام‌های فارسی و انگلیسی و سیاست null را یکسان کند. پراکندگی تبدیل در کنترلر، فرم و Repository معمولاً به رفتارهای متفاوت و رفع اشکال دشوار منجر می‌شود.

مثال‌های عملی گام‌به‌گام

ده مثال زیر از تبدیل پایه آغاز می‌شوند و به سناریوهای مجموعه‌داده، null، مرز، خطای Culture و کارایی می‌رسند. هر مثال برای int.TryParse() طراحی شده و نتیجه نمونه را بدون نیاز به اجرای اولیه نشان می‌دهد.

مثال شماره 1: تبدیل مقدار ثابت برای تعداد سفارش

در ساده‌ترین حالت، رشته‌ای که از نظر قالب و دامنه با نوع int سازگار است به متد داده می‌شود. بررسی مقدار بازگشتی قبل از استفاده از result باعث می‌شود مسیر موفق و ناموفق صریح باقی بماند.

using System;
    using Globalization;

    internal static class Program
    {
        private static void Main()
        {
            string input = "125000";
            bool success = int.TryParse(input, NumberStyles.Integer, CultureInfo.InvariantCulture, out int value);
            Console.WriteLine($"success={success}; value={value.ToString(CultureInfo.InvariantCulture)}");
        }
    }

این الگو برای دریافت تعداد سفارش از فرم یا فایل تنظیمات مناسب است. مقدار result فقط در شاخه موفقیت وارد منطق اصلی می‌شود و مقدار پیش‌فرض هرگز با داده واقعی اشتباه گرفته نمی‌شود.

مثال شماره 2: پردازش دسته‌ای داده‌های ورودی

در ورود اطلاعات واقعی معمولاً با مجموعه‌ای از رشته‌ها روبه‌رو هستیم. این مثال رکوردهای مناسب تعداد موجودی، شماره صفحه، سن و شناسه‌های کوچک را تفکیک می‌کند و به‌جای متوقف کردن کل عملیات، تعداد خطاها را برای گزارش کیفیت داده نگه می‌دارد.

using System;
    using Globalization;

    internal static class Program
    {
        private static void Main()
        {
            string[] rows = { "125000", "4500", "2147483648", "72" };
            int accepted = 0;
            int rejected = 0;

            foreach (string text in rows)
            {
                if (int.TryParse(text, NumberStyles.Integer, CultureInfo.InvariantCulture, out int value))
                {
                    accepted++;
                    Console.WriteLine($"accepted: {value.ToString(CultureInfo.InvariantCulture)}");
                }
                else
                {
                    rejected++;
                    Console.WriteLine($"rejected: {text}");
                }
            }

            Console.WriteLine($"accepted={accepted}; rejected={rejected}");
        }
    }

تفکیک رکورد معتبر و نامعتبر، پایه یک فرایند Import قابل پایش است. در پروژه سازمانی بهتر است متن ورودی، شماره ردیف و دلیل رد نیز در گزارش خطا ثبت شود، اما داده حساس نباید بدون پالایش وارد لاگ شود.

مثال شماره 3: ساخت Projection شبیه SELECT با LINQ

گاهی هدف، تبدیل هر ردیف به یک مقدار Nullable است تا ساختار و ترتیب داده حفظ شود. استفاده از مقدار null برای شکست تبدیل، با صفر واقعی تفاوت دارد و اجازه می‌دهد لایه گزارش‌گیری وضعیت داده ناقص را درست نمایش دهد.

using System;
    using Globalization;
    using Linq;

    internal static class Program
    {
        private static void Main()
        {
            string[] raw = { "125000", "2147483648", "4500" };

            int?[] converted = raw
                .Select(text => int.TryParse(text, NumberStyles.Integer, CultureInfo.InvariantCulture, out int value)
                    ? value
                    : (int?)null)
                .ToArray();

            string report = string.Join(
                " | ",
                converted.Select(value => value.HasValue
                    ? value.Value.ToString(CultureInfo.InvariantCulture)
                    : "نامعتبر")
            );

            Console.WriteLine(report);
        }
    }

این الگو در ViewModel، گزارش و تبدیل DTO کاربرد دارد. اگر null از نظر دامنه کسب‌وکار معنی مستقلی دارد، بهتر است یک Result صریح شامل مقدار، وضعیت و پیام خطا تعریف شود تا ابهام باقی نماند.

مثال شماره 4: فیلتر داده معتبر شبیه شرط WHERE

صحیح بودن قالب تنها شرط پذیرش نیست. در این نمونه ابتدا int.TryParse() اجرا می‌شود و سپس قانون کسب‌وکار غیرمنفی بودن برای تعداد سفارش اعمال می‌گردد؛ بنابراین اعتبار نحوی و معنایی از هم جدا هستند.

using System;
    using Globalization;
    using Linq;

    internal static class Program
    {
        private static void Main()
        {
            string[] raw = { "-1", "72", "4500", "2147483648" };

            string[] accepted = raw
                .Where(text =>
                    int.TryParse(text, NumberStyles.Integer, CultureInfo.InvariantCulture, out int value) &&
                    Convert.ToDecimal(value, CultureInfo.InvariantCulture) >= 0)
                .ToArray();

            Console.WriteLine(string.Join(", ", accepted));
        }
    }

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

مثال شماره 5: ترکیب تبدیل با محاسبه

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

using System;
    using Globalization;

    internal static class Program
    {
        private static void Main()
        {
            string input = "72";

            if (int.TryParse(input, NumberStyles.Integer, CultureInfo.InvariantCulture, out int value))
            {
                decimal normalized = Convert.ToDecimal(value, CultureInfo.InvariantCulture);
                decimal adjusted = normalized * 1.10m;
                Console.WriteLine(adjusted.ToString("0.####", CultureInfo.InvariantCulture));
            }
            else
            {
                Console.WriteLine("ورودی نامعتبر");
            }
        }
    }

نوع محاسبات بعدی باید با هدف سازگار باشد. برای شناسه یا شمارنده‌ای که ممکن است از حدود دو میلیارد عبور کند، long انتخاب ایمن‌تری است. تبدیل اولیه موفق، خطاهای گرد کردن یا انتخاب نوع نامناسب در مراحل بعدی را برطرف نمی‌کند.

مثال شماره 6: رفتار با null

ورودی null در مسیرهای فرم، JSON، پایگاه داده و تنظیمات رایج است. متد TryParse برای null استثنای قالب تولید نمی‌کند و false می‌دهد؛ بااین‌حال کد نباید مقدار پیش‌فرض result را به‌عنوان داده معتبر ذخیره کند.

using System;
    using Globalization;

    internal static class Program
    {
        private static void Main()
        {
            string? input = null;
            bool success = int.TryParse(input, NumberStyles.Integer, CultureInfo.InvariantCulture, out int value);

            Console.WriteLine($"success={success}");
            Console.WriteLine($"default-value={value.ToString(CultureInfo.InvariantCulture)}");
        }
    }

تصمیم نهایی درباره null وابسته به قرارداد فیلد است: ممکن است فیلد اختیاری باشد، یا نبودنش خطای اعتبارسنجی محسوب شود. این تصمیم را بیرون از TryParse و با پیام مناسب به کاربر پیاده کنید.

مثال شماره 7: کنترل مرز نوع و سرریز

محدوده int برابر از ‎-۲۱۴۷۴۸۳۶۴۸ تا ۲۱۴۷۴۸۳۶۴۷ است. آزمون مقادیر مرزی نشان می‌دهد TryParse علاوه بر قالب، قابل‌نمایش بودن مقدار در نوع مقصد را کنترل می‌کند و در سرریز قابل تشخیص false برمی‌گرداند.

using System;
    using Globalization;

    internal static class Program
    {
        private static void Main()
        {
            string[] boundaries = { "-2147483648", "2147483647", "2147483648" };

            foreach (string text in boundaries)
            {
                bool success = int.TryParse(text, NumberStyles.Integer, CultureInfo.InvariantCulture, out int value);
                string parsed = success
                    ? value.ToString(CultureInfo.InvariantCulture)
                    : "رد شد";
                Console.WriteLine($"{text} => {parsed}");
            }
        }
    }

برای شناسه یا شمارنده‌ای که ممکن است از حدود دو میلیارد عبور کند، long انتخاب ایمن‌تری است. برای float و double برخی رشته‌های بسیار بزرگ در نسخه‌های جدید .NET ممکن است به Infinity گرد شوند؛ اگر بی‌نهایت برای دامنه شما مجاز نیست، IsFinite را نیز کنترل کنید.

مثال شماره 8: سناریوی گزارش‌گیری سازمانی

گزارش‌های تعداد موجودی، شماره صفحه، سن و شناسه‌های کوچک باید در برابر یک ردیف خراب مقاوم باشند. نمونه حاضر فقط رکوردهای معتبر را وارد مجموع می‌کند و تعداد آن‌ها را جداگانه گزارش می‌دهد تا تصمیم‌گیرنده از کیفیت ورودی آگاه باشد.

using System;
    using Globalization;

    internal static class Program
    {
        private static void Main()
        {
            string[] source = { "125000", "4500", "bad", "72" };
            decimal total = 0m;
            int validCount = 0;

            foreach (string text in source)
            {
                if (int.TryParse(text, NumberStyles.Integer, CultureInfo.InvariantCulture, out int value))
                {
                    total += Convert.ToDecimal(value, CultureInfo.InvariantCulture);
                    validCount++;
                }
            }

            Console.WriteLine($"valid={validCount}; total={total.ToString(CultureInfo.InvariantCulture)}");
        }
    }

حذف خاموش رکورد نامعتبر می‌تواند گزارش را گمراه کند. بهتر است کنار عدد نهایی، تعداد رکورد ردشده و پیوند به گزارش خطا نمایش داده شود و برای آستانه خطا هشدار عملیاتی تعریف گردد.

مثال شماره 9: روش اشتباه و نسخه اصلاح‌شده برای Culture

یکی از رایج‌ترین خطاها تکیه بر Culture جاری ماشین است. این مثال نتیجه روش مبهم را با نسخه‌ای مقایسه می‌کند که هم سبک عدد و هم فرهنگ را صریح اعلام کرده است.

using System;
    using Globalization;

    internal static class Program
    {
        private static void Main()
        {
            string input = "1,250,000";

            bool withoutThousands = int.TryParse(
                input,
                NumberStyles.Integer,
                CultureInfo.InvariantCulture,
                out int first
            );

            bool withThousands = int.TryParse(
                input,
                NumberStyles.Integer | NumberStyles.AllowThousands,
                CultureInfo.InvariantCulture,
                out int second
            );

            Console.WriteLine($"default-style={withoutThousands}");
            Console.WriteLine($"explicit-style={withThousands}; value={second}");
        }
    }

سبک پیش‌فرض عدد صحیح جداکننده هزارگان را نمی‌پذیرد. با NumberStyles صریح می‌توان قرارداد ورودی را کنترل کرد، ولی نتیجه همچنان باید در محدوده نوع مقصد باشد.

مثال شماره 10: استفاده از ReadOnlySpan برای مسیر پرتکرار

در Parserهای فایل، پروتکل و خطوط بزرگ می‌توان بخشی از متن را بدون ساخت substring جداگانه به overload مبتنی بر ReadOnlySpan داد. این روش در حجم بالا تخصیص حافظه را کاهش می‌دهد، هرچند اندازه‌گیری واقعی با Benchmark ضروری است.

using System;
    using Globalization;

    internal static class Program
    {
        private static void Main()
        {
            ReadOnlySpan<char> token = "125000".AsSpan();

            bool success = int.TryParse(
                token,
                NumberStyles.Integer,
                CultureInfo.InvariantCulture,
                out int value
            );

            Console.WriteLine(success
                ? value.ToString(CultureInfo.InvariantCulture)
                : "نامعتبر");
        }
    }

بهینه‌سازی Span زمانی ارزشمند است که پروفایلر فشار تخصیص را نشان دهد. برای فرم معمولی، خوانایی و پیام اعتبارسنجی مهم‌تر است؛ اما در پردازش میلیون‌ها توکن، کاهش تخصیص می‌تواند اثر قابل اندازه‌گیری داشته باشد.

خطاهای رایج و راه اصلاح

• استفاده از result بدون بررسی مقدار بازگشتی؛ اصلاح: منطق مصرف مقدار را داخل شاخه موفقیت قرار دهید.
• یکی گرفتن مقدار پیش‌فرض با شکست؛ اصلاح: وضعیت تبدیل را همراه مقدار نگه دارید یا Result صریح بسازید.
• اتکا به فرهنگ سرور؛ اصلاح: Culture و Style را از قرارداد داده تعیین کنید.
• پذیرش هر مقدار قابل تبدیل؛ اصلاح: پس از تبدیل، بازه، Allowlist و قواعد ارتباطی دامنه را بررسی کنید.
• حذف خاموش رکورد خراب در Import؛ اصلاح: شمارش و گزارش خطا را در خروجی فرایند قرار دهید.
• نادیده گرفتن نکته اختصاصی نوع؛ اصلاح: برای شناسه یا شمارنده‌ای که ممکن است از حدود دو میلیارد عبور کند، long انتخاب ایمن‌تری است.

پیام خطا باید قابل اقدام باشد. به‌جای «ورودی نامعتبر است» می‌توان قالب مورد انتظار، محدوده مجاز و یک نمونه صحیح را ارائه کرد. بااین‌حال جزئیات داخلی، Stack Trace یا داده حساس نباید در پاسخ عمومی ظاهر شود.

کارایی، تخصیص حافظه و Best Practice

TryParse برای شکست قابل انتظار از الگوی Parse همراه try/catch مناسب‌تر است، زیرا استثنا برای کنترل جریان عادی طراحی نشده است. این حکم به معنی ممنوع بودن Parse نیست؛ اگر رشته یک ثابت داخلی معتبر است و خرابی آن باگ برنامه محسوب می‌شود، fail-fast با Parse می‌تواند انتخاب روشنی باشد.

overloadهای ReadOnlySpan در Parserهای پرتکرار امکان کار روی برشی از بافر را بدون ساخت substring می‌دهند. سود آن در فایل‌های بزرگ، پروتکل یا پردازش میلیون‌ها توکن بیشتر است. در فرم عادی، پیچیدگی اضافی ممکن است ارزش نداشته باشد؛ ابتدا CPU، Allocation و نرخ شکست را اندازه‌گیری کنید.

برای آزمون، حداقل حالت‌های معتبر، null، خالی، فاصله، Culture متفاوت، کمینه، بیشینه، خارج از محدوده و مقدار معتبر ولی غیرمجاز را پوشش دهید. تست‌ها باید Target Framework واقعی را اجرا کنند، زیرا برخی overloadها و رفتارهای گوشه‌ای میان نسخه‌های .NET تفاوت دارند.

سؤالات متداول

پرسش 1: int.TryParse() دقیقاً چه مسئله‌ای را حل می‌کند؟

int.TryParse() متن را با قرارداد نوع مقصد بررسی می‌کند و بدون تبدیل شکست قابل انتظار به استثنا، وضعیت موفقیت را برمی‌گرداند. این ویژگی در ورودی کاربر، فایل، API و تنظیمات ارزشمند است. حوزه رایج این مقاله تعداد موجودی، شماره صفحه، سن و شناسه‌های کوچک است، اما اعتبار نحوی فقط نخستین مرحله است و قواعد دامنه باید جدا اعمال شوند.

پرسش 2: در صورت شکست int.TryParse() چه اتفاقی برای result می‌افتد؟

متد false برمی‌گرداند و result مقدار پیش‌فرض نوع را خواهد داشت یا نباید معتبر فرض شود. الگوی درست این است که result فقط در شاخه true مصرف شود. تکیه بر صفر، false، تاریخ کمینه یا Guid.Empty می‌تواند داده نامعتبر را با یک مقدار واقعی اشتباه بگیرد و خطای خاموش ایجاد کند.

پرسش 3: Culture چه اثری بر int.TryParse() دارد؟

اثر Culture به نوع بستگی دارد. اعداد اعشاری، جداکننده هزارگان و تاریخ به فرهنگ حساس‌اند، درحالی‌که Guid و bool قرارداد محدودتری دارند. در مرزهای ماشینی CultureInfo.InvariantCulture و قالب مستند، و در رابط کاربر فرهنگ انتخاب‌شده کاربر مناسب است. فرهنگ سرور نباید به‌طور تصادفی نتیجه را تعیین کند.

پرسش 4: چگونه int.TryParse() را در نرم‌افزار تجاری استفاده کنیم؟

یک لایه اعتبارسنجی بسازید که متن خام، نتیجه تبدیل، کد خطا و پیام قابل فهم را برگرداند. سپس قانون کسب‌وکار مربوط به تعداد موجودی، شماره صفحه، سن و شناسه‌های کوچک را اعمال کنید. این جداسازی هم تست‌پذیری را بالا می‌برد و هم امکان گزارش کیفیت داده، مشاوره فنی و توسعه سفارشی جریان Import را فراهم می‌کند.

پرسش 5: آیا جایگزینی بهتر از int.TryParse() وجود دارد؟

پاسخ به قرارداد ورودی وابسته است. برای قالب ثابت TryParseExact، برای داده‌ای که خرابی آن باگ است Parse، و برای تبدیل‌های سفارشی یک Value Object یا Parser دامنه‌ای مناسب‌تر است. هدف انتخاب کوتاه‌ترین کد نیست؛ باید خطا، Culture، سازگاری نسخه و پیام کاربر به‌روشنی مدیریت شود.

پرسش 6: برای پیاده‌سازی سازمانی int.TryParse() چه خدماتی لازم می‌شود؟

در پروژه بزرگ معمولاً طراحی قرارداد داده، اعتبارسنجی چندلایه، تست مرزی، ثبت خطای امن، داشبورد کیفیت ورودی و پایش لازم است. تیم توسعه یا مشاور می‌تواند این اجزا را متناسب با معماری C# و .NET، حجم داده و الزامات امنیتی پیاده کند. خود متد کوچک است، اما فرایند قابل اعتماد پیرامون آن اهمیت اصلی را دارد.

پرسش 7: خطای رایج هنگام کار با int.TryParse() چیست؟

رایج‌ترین خطا استفاده از result بدون بررسی مقدار بازگشتی است. خطاهای دیگر شامل اتکا به Culture جاری، نادیده گرفتن مرز نوع، یکی گرفتن اعتبار نحوی و معنایی و حذف خاموش رکورد نامعتبر است. نکته اختصاصی این موضوع نیز چنین است: برای شناسه یا شمارنده‌ای که ممکن است از حدود دو میلیارد عبور کند، long انتخاب ایمن‌تری است.

پرسش 8: کارایی int.TryParse() در پردازش حجیم چگونه است؟

در شکست‌های قابل انتظار، TryParse معمولاً از کنترل جریان با exception مناسب‌تر است. overloadهای ReadOnlySpan می‌توانند تخصیص substring را کاهش دهند. بااین‌حال نتیجه به نسخه .NET، الگوی داده و مسیر اجرا وابسته است؛ پروفایلر و BenchmarkDotNet باید تصمیم را تأیید کنند و بهینه‌سازی زودهنگام نباید خوانایی را قربانی کند.

پرسش 9: بهترین روش طراحی با int.TryParse() چیست؟

قرارداد ورودی را مستند کنید، Culture و Style را در صورت نیاز صریح بدهید، result را فقط پس از true مصرف کنید، اعتبار دامنه را جدا بسنجید و خطا را با پیام قابل اقدام گزارش دهید. برای تعداد موجودی، شماره صفحه، سن و شناسه‌های کوچک آزمون‌های مرزی، null، مقدار نامعتبر، ورودی بسیار بزرگ و سناریوی واقعی کسب‌وکار را در مجموعه تست قرار دهید.

پرسش 10: int.TryParse() با کدام نسخه‌های C# و .NET سازگار است؟

overload پایه string در نسخه‌های قدیمی .NET نیز در دسترس است، اما overloadهای Span، UTF-8 و رابط‌های Generic Math در نسخه‌های جدیدتر افزوده شده‌اند. پروژه باید مستندات Target Framework خود را مبنا قرار دهد. اگر کتابخانه چندهدفه است، API سطح مشترک را انتخاب یا برای نسخه‌های جدید مسیر بهینه جدا تعریف کنید.

سؤالات مصاحبه C# و .NET

پرسش‌های زیر دانش قراردادی و معماری داوطلب را می‌سنجند، نه صرفاً حفظ کردن امضای متد.

1. تفاوت قرارداد خطای int.TryParse() با Parse را توضیح دهید و برای هر کدام یک سناریو نام ببرید.
2. چرا بررسی مقدار بازگشتی قبل از result ضروری است و مقدار پیش‌فرض چه خطری دارد؟
3. اثر Culture، Style یا قالب ورودی بر int.TryParse() را با یک مثال تشریح کنید.
4. اعتبار نحوی و اعتبار کسب‌وکار در موضوع تعداد موجودی، شماره صفحه، سن و شناسه‌های کوچک چگونه از هم جدا می‌شوند؟
5. چه زمانی overload مبتنی بر ReadOnlySpan ارزشمند است و چگونه سود آن را اندازه می‌گیرید؟

چک‌لیست نهایی

• نوع مقصد و محدوده آن با دامنه واقعی داده سازگار است.
• Culture، Style یا قالب ثابت در مرز سیستم مشخص شده است.
• result فقط در مسیر موفقیت مصرف می‌شود.
• اعتبار نحوی از قواعد کسب‌وکار جداست.
• null، مقدار خالی، مرز و ورودی خراب تست شده‌اند.
• خطاها قابل پایش‌اند و داده حساس در لاگ قرار نمی‌گیرد.
• بهینه‌سازی Span تنها پس از اندازه‌گیری انجام شده است.

جمع‌بندی

int.TryParse() ابزار کوچکی برای ساخت مرز ورودی قابل اعتماد است. ارزش واقعی آن زمانی دیده می‌شود که قرارداد فرهنگ، محدوده، گزارش خطا و اعتبار دامنه پیرامونش درست طراحی شود. در تعداد موجودی، شماره صفحه، سن و شناسه‌های کوچک همین رویکرد از داده خاموش اشتباه، استثناهای پرتکرار و اختلاف رفتار محیط‌ها جلوگیری می‌کند.

برای مرور سایر نوع‌ها و انتخاب API مناسب، راهنمای جامع همه متدهای TryParse در C# و .NET را مطالعه کنید.