عند مراجعة رمز C/C ، غالبًا ما نجد متغيرات لا تستخدم أبدًا. مثل هذه المتغيرات غير المستخدمة تحدث لعدة أسباب. في هذا المنشور ، نلقي نظرة على بعض الأسباب الأكثر شيوعًا لماذا تحدث المتغيرات غير المستخدمة في رمز C/C. نراجع كيفية تحذير المترجم من المتغيرات غير المستخدمة ، وكيفية قمع التحذيرات لمتغيرات محددة غير مستخدمة.

لماذا المتغيرات غير مستخدمة

هناك العديد من الأسباب التي تجعل المتغيرات غير المستخدمة في قاعدة رمز. وتشمل هذه:

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

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

3. في المستقبل: قد لا تحدث متغيرات غير مستخدمة فقط كإرث من الكود السابق ولكن أيضًا كإرث من الكود المستقبلي. قد تعلن المتغيرات تحسبا للكود الذي لم يتم كتابته بعد.

4. التجميع الشرطي: قد تظل المتغيرات غير مستخدمة اعتمادًا على المرحلة المسبقة. المثال القياسي هو متغير يتم تعريفه فقط لأغراض التصحيح. قد يحتوي الكود الخاص بك على شيء من النموذج
   

const auto value = compute_some_value();
const auto value_for_comparison_only = compute_same_value_differently();
assert( value == value_for_comparison_only );

إذا قمت بالتجميع باستخدام -dndebug ، فقد يحذرك برنامج التحويل البرمجي من أن value_for_comparison_only لا يستخدم أبدًا: في الواقع ، تم استبدال بيان التأكيد بـ ... لا شيء.

كيفية اكتشاف المتغيرات غير المستخدمة

يمكن أن تؤثر المترجمين وإعدادات مستوى التحذير المختلفة على ما إذا كان يتم الإبلاغ عن متغير غير مستخدم أثناء عملية التجميع.

على سبيل المثال ، يعرض GCC و Clang العلم المتغير -الذي يؤدي إلى تحذيرات حول المتغيرات غير المستخدمة. العلم ضمني بالفعل من خلال خيار التحذير -wall ، ويمكن إيقاف تشغيله عبر -غير متغير.

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

كيفية عدم اكتشاف المتغيرات غير المستخدمة: السمات

بينما يجب أن نتجمع دائمًا مع العديد من التحذيرات التي تم تمكينها على أنها ممكنة ، هناك ظروف نريد أن نوقفها بشكل انتقائي تحذيرات حول متغيرات معينة غير مستخدمة. طريقة شائعة للقيام بذلك هي فريق من أجل الفراغ:

Object unused_object;
(void)unused_object;

The Turm to Void Countts كاستخدام (Pro Forma) للمتغير ، لذلك لن يتم تحذير.

بينما يزيل هذا التحذيرات التي تفيد بأن unused_object غير مستخدم ، تمامًا كما هو مقصود ، هناك طرق لتحسين هذا. نود أن نحصل على دلالات صريحة أن هذا الفراغ يدل على كائن غير مستخدم. هناك طريقة شائعة من خلال تحديد الماكرو:

#define UNUSED(x) (void)(x);
// ...
Object unused_object;
UNUSED(unused_object);

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

تجاوز وحدات الماكرو ، لدينا سمات متغيرة: إما موطنها للغة C أو امتداد اللغة المقدمة من قبل المترجمين C/C. على سبيل المثال ، يسمح Clang و GCC بالسمات المتغيرة __attribute __ ((غير مستخدمة)). C 17 يدعم السمة [[ربما_ unused]]:

Object unused_object2 __attribute__((unused)) = x;  // should be placed after declaration
[[maybe_unused]] Object unused_object1 = x;         // must be placed before declaration

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

تاريخياً ، ظهرت سمات GCC أولاً ، كونها ملحقات لغة خاصة بالمترجمة في C و C. من C 17 فصاعدًا ، تعد السمات جزءًا من معيار اللغة. ومع ذلك ، لا يختلف الإملاء فحسب ، بل إن الإضافات المعيارية والمعيارية لا توافق على مكان وضع السمة.

ستجد السمة [[leding_unused]] معظم تطبيقاتها مع التجميع الشرطي. على سبيل المثال ، إنها سمة طبيعية لمتغيرات التصحيح فقط. لأسباب جمالية بحتة ، أنا شخصياً أفضل تحديد ماكرو #define ربما _Unused [[ربما _unused]].

ميزة __attribute __ ((غير مستخدمة)) هي أنه سيحذرك فعليًا إذا تم استخدام المتغير في الكود. إنه ليس ربما غير مستخدم ولكن بالتأكيد لم يتم استخدامه على الإطلاق ، وسيؤدي استخدام المتغير الآن إلى تحذير.

الحفاظ على أشياء عديمة الفائدة

على ما يبدو ، المتغيرات غير المستخدمة متكررة ومهمة بما يكفي لتبرير امتدادات لغتها الخاصة.

بالمقارنة ، هل يعلق المتغير غير المستخدم استراتيجية جيدة؟ ليس دائما! هناك أسباب تجعلك تحتفظ بمتغير غير مستخدم خلال رمز التطوير ومرحلة التصحيح. لنفترض أن المتغير تم استخدامه في إصدار سابق من الكود ، ربما لم تقرر حتى الآن ما إذا كان ينبغي تعليق الرمز القديم أو إعادة دمجه ؛ المعنى: أنت لا تعرف ما إذا كنت قد تحتاج إلى المتغير غير المستخدم مرة أخرى.

قد يكون من المفيد لأغراض تصحيح الأخطاء الاحتفاظ برمز مثل:

auto unused_variable __attribute__((unused)) = complicated_calculation( arg1, arg2, arg3 );

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

آمل أن يكون هذا النشر حول المتغيرات غير المستخدمة مفيدًا لك.