المتغيرات المحددة وتعيينها في نفس الوقت

Question

تقدم عرض نمط الترميز الذي التحق به مؤخرا في Office إلى أن المتغيرات يجب ألا يتم تعيين المتغيرات (إلى قيمة افتراضية) عند تحديدها. بدلا من ذلك، يجب تعيين قيمة افتراضية قبل استخدامها مباشرة. لذلك، شيء مثل

int a = 0;

يجب أن تكون عبوس.

من الواضح، مثال على "int" مبسطة ولكن نفسها التالية لأنواع أخرى مثل المؤشرات وما إلى ذلك.

علاوة على ذلك، ذكر أيضا أن المترجمين المتوافقين C99 يرمون الآن تحذيرا في القضية المذكورة أعلاه.

النهج أعلاه يبدو مفيدا بالنسبة لي فقط للهياكل، أي أنك مذكرها فقط قبل الاستخدام. سيكون هذا فعالا إذا تم استخدام الهيكل (أو شغل) فقط في ساق الخطأ.

للحصول على جميع الحالات الأخرى، أجد تحديد وتعيين قيمة افتراضية تمرين حكيم حيث واجهت الكثير من الأخطاء بسبب مؤشرات التهيئة غير المنظمة أثناء كتابة التعليمات البرمجية والحفاظ عليها. علاوة على ذلك، أعتقد أن C ++ عبر المنشئين يدعون أيضا إلى نفس النهج أي تحديد وتعيينه.

أنا أتساءل لماذا (إذا) C99 قياسي لا يحب تحديد وتعيينه. هو أي ميزة كبيرة في القيام بماذا دعا عرض نمط الترميز؟

Answer 1

عادة ما أوصي بتهيئة المتغيرات عند تحديدها إذا كانت القيمة التي يجب أن يكون لها معروفة، وترك المتغيرات غير مهيأة إذا كانت القيمة ليست كذلك. في كلتا الحالتين، ضعها على قرب استخدامها كقواعد التركيب تسمح.

بدلا من ذلك، يجب تعيين قيمة افتراضية قبل استخدامها مباشرة.

عادة يجب أن لا تستخدم قيمة افتراضية على الإطلاق. في C99، يمكنك مزج التعليمات البرمجية والإعلانات، لذلك لا توجد نقطة تحدد المتغير قبل تعيين قيمة إليه. إذا كنت تعرف القيمة التي من المفترض أن تأخذها، فلا توجد نقطة في وجود قيمة افتراضية.

علاوة على ذلك، ذكر أيضا أن المترجمين المتوافقين C99 يرمون الآن تحذيرا في القضية المذكورة أعلاه.

ليس لأنك تظهر - أنت لا تحصل على تحذير من وجود int x = 0;. وبعد أشك بشدة في أن شخصا ما حصل على هذا مختلطا. التحويل البرمجيات تحذر إذا كنت تستخدم متغير دون تعيين قيمة لذلك، وإذا كان لديك:

... some code ...

int x;

if ( a )
    x = 1;
else if ( b )
    x = 2;
// oops, forgot the last case else x = 3;

return x * y;

ثم سوف تحصل على تحذير من أن x قد يتم استخدامه دون الوفاء به، على الأقل مع دول مجلس التعاون الخليجي.

لن تحصل على تحذير إذا قمت بتعيين قيمة ل x قبل if, ، لكنه غير ذي صلة ما إذا كان يتم إجراء المهمة كبرنامج أو كبيان منفصل.

ما لم يكن لديك سبب معين لتعيين القيمة مرتين لاثنين من الفروع، لا توجد نقطة تعيين القيمة الافتراضية إلى X أولا، لأنه يتوقف عن التحويل البرمجي الذي تحذر من أنك غطيتك كل فرع.

Answer 2

هناك لا هذا الشرط (أو حتى المبدأ التوجيهي الذي أدركه) في C99، ولا يحذرك التحويل البرمجي عن ذلك. انها ببساطة مسألة أسلوب.

فيما يتعلق بأسلوب الترميز، أعتقد أنك أخذت أشياء حرفيا أيضا. على سبيل المثال، بيانك صحيح في الحالة التالية ...

int i = 0;

for (; i < n; i++)
        do_something(i);

... أو حتى في ...

int i = 1;

[some code follows here]

while (i < a)
        do_something(i);

... ولكن هناك حالات أخرى، في ذهني، يتم التعامل معها بشكل أفضل مع "إعلان وتعيين" مبكرا. النظر في الهياكل التي تم بناؤها على المكدس أو بنيات OOP المختلفة، كما في:

struct foo {
        int bar;

        void *private;
};

int my_callback(struct foo *foo)
{
        struct my_struct *my_struct = foo->private;

        [do something with my_struct]

        return 0;
}

أو ترغب في (C99 بنية التهيئة):

void do_something(int a, int b, int c)
{
        struct foo foo = {
                .a        = a,
                .b        = b + 1,
                .c        = c / 2,
        };

        write_foo(&foo);
}

Answer 3

أنا نوع من التفق مع النصيحة، على الرغم من أنني لست متأكدا تماما من المعيار يقول أي شيء عن ذلك، وأشك كثيرا في حد كبير حول تحذيرات المحول البرمجي صحيحا.

الشيء هو، يمكن للمجمعون الحديثين والكشف عن استخدام المتغيرات غير المنصوص عليها. إذا قمت بتعيين المتغيرات الخاصة بك إلى القيم الافتراضية عند التهوية، فقد تفقد هذا الكشف. والقيم الافتراضية يمكن أن تسبب البق أيضا؛ بالتأكيد في حالة مثالك، int a = 0;. وبعد من يقول ذلك 0 هي قيمة مناسبة ل a?

في التسعينيات، كانت النصيحة مخطئة. في الوقت الحاضر، إنه صحيح.

Answer 4

أجد أنه من المفيد للغاية تعيين بعض البيانات الافتراضية مسبقا للمتغيرات بحيث لا يجب عليك القيام به (أكبر عدد ممكن) في التعليمات البرمجية.

Answer 5

لقد رأيت الكثير من الأخطاء بسبب المؤشرات غير المهيمين التي دافعت دائما عن إعلان كل متغير مع null_ptr وكل بدائية بعض القيمة غير الصالحة / الافتراضية.

نظرا لأنني أعمل على RTOS والأداء العالي ولكن أنظمة الموارد المنخفضة، فمن الممكن أن المترجمين نستخدمهم لا يلتقطوا استخدام غير تهيئة. على الرغم من أنني أشك في أن التحويل البرمجيات الحديثة يمكن الاعتماد عليها أيضا بنسبة 100٪.

في مشاريع كبيرة حيث يتم استخدام الماكرو على نطاق واسع، فقد رأيت سيناريوهات نادرة حيث فشلت حتى kloclwork / purify في العثور على استخدام غير تهيئة.

لذلك أقول عصا معها طالما كنت تستخدم C / C + C ++.

اللغات الحديثة مثل .NET يمكن أن تضمن لتهيئة varibles، أو إعطاء خطأ مترجم للاستخدام المتغير غير المهيمن. الرابط التالي يقوم بتحليل الأداء والتحقق من صحة أن هناك أداء 10-20٪ الذي يضربه .NET. التحليل بالتفصيل تماما ويتم شرحه جيدا.

http://www.codeProject.com/kb/dotnet/dontinitializevariables.aspx.