تحذيرات البرمجيات C / C ++: هل تقوم بتنظيف كل التعليمات البرمجية لإزالتها أو تركها؟

Question

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

لا أفهم لماذا يتركهم الناس وليس لديهم مجموعات نظيفة تمامًا بدون تحذيرات. هل فاتني شيء؟ هل هناك أي سبب وجيه لتركهم فقط؟ أي قصص رعب للمشاركة؟

Answer 1

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

إنها واحدة من علامات "الرائحة" التي سأبحث عنها إذا اضطررت إلى العمل على رمز شخص آخر.

إذا لم تكن الأخطاء الحقيقية أو القضايا المستقبلية المحتملة ، فستكون علامة على الانحدار

Answer 2

نظف ، حتى لو لم يشيروا إلى مشكلة حقيقية. خلاف ذلك ، إذا تحذير ذلك يفعل أشر إلى ظهور مشكلة حقيقية ، فلن ترى ذلك من خلال كل الضوضاء.

Answer 3

في عملي ، يتم تشغيل إعداد البرمجيات لعلاج التحذيرات مع تشغيل الأخطاء. لذلك ، لا تحذيرات ، أو لن يتم تجميعها :)

Answer 4

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

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

إذا وجدت تحذيرًا تشك في أنه آمن لتجاهله ، فقم ببعض الأبحاث للتحقق من نظريتك. عندها فقط تعطيله وفقط بأقصى حد ممكن. معظم المترجمين لديهم #pragma التوجيهات التي يمكنها تعطيل/تمكين التحذيرات لجزء من الملف فقط. إليك مثال مرئي C ++:

typedef struct _X * X; // from external header, not 64-bit portable

#pragma warning( push )
#pragma warning( disable: 4312 ) // 64-bit portability warning
X x = reinterpret_cast< X >( 0xDDDDDDDD ); // we know X not 64-bit portable
#pragma warning( pop )

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

بدلاً من ذلك ، يمكنك عادةً تعطيل تحذير معين لملف واحد أو لجميع الملفات. IMHO هذا أمر خطير ويجب أن يكون الملاذ الأخير فقط.

Answer 5

تنظيفها اذا كان ممكنا. على قاعدة كود متعددة المنصات/متعددة المجمعات (لقد عملت على واحدة تم تجميعها على 7 OSS مختلفة مع 6 مجمعات مختلفة) وهذا غير ممكن دائمًا. لقد رأيت الحالات التي يكون فيها المترجم فقط خاطئ - ظلم - يظلم (hp-ux acc على itanium ، أنا أنظر إليك) ، لكن هذا أمر نادر الحدوث. كما يلاحظ الآخرون ، يمكنك تعطيل التحذير في مثل هذا الموقف.

في كثير من الأحيان ، قد يصبح التحذير في هذا الإصدار من برنامج التحويل البرمجي خطأً في الإصدار التالي (يجب أن يكون أي شخص يتم ترقيته من GCC 3.x إلى 4.x على دراية بذلك) ، لذا قم بتنظيفه الآن.

سوف ينبعث بعض المترجمين تحذيرات مفيدة حقًا ستصبح مشكلات في ظل ظروف معينة-يمكن أن يحذرك Visual C ++ 2005 و 2008 من قضايا 64 بت ، وهي فائدة كبيرة في الوقت الحاضر. إذا كان لديك أي خطط للترحيل إلى 64 بت ، فإن مجرد تنظيف هذه الأنواع من التحذيرات سيقلل بشكل كبير من وقت المنفذ.

Answer 6

هناك بعض الحالات التي سأترك فيها تحذيرات في التعليمات البرمجية ، أو حيث لا يمكن تنظيفها (على الرغم من أنني أزيل الحالات التي أستطيع). فمثلا:

• إذا كان لديك شيء تعمل عليه ، وأنت تعلم أنه يحتاج إلى مزيد من العمل/الاهتمام ، تاركًا تحذيرًا في مكانه للإشارة إلى أن هذا يمكن أن يكون مناسبًا
• إذا كنت تقوم بتجميع C ++ مع /CLR ، فهناك العديد من التحذيرات حول الأشياء التي تتسبب في إنشاء التعليمات البرمجية الأصلية ؛ قد يكون من المرهق قمع كل هذه التحذيرات عندما لا يمكن تغيير قاعدة الشفرات الوظيفية
• تنظيف التحذيرات عندما لا تفهم ما يفعله الإصلاح. لقد فعلت ذلك عدة مرات مع تحذير PC-Lint ، وانتهى به الأمر في تقديم الأخطاء. إذا كنت لا تعرف ما هو التأثير الدقيق للتغيير (على سبيل المثال: C style casts للقضاء على التحذيرات) ، لا تفعل ذلك. معرفة التحذير ، أو اترك الكود وحده هو نصيحتي.

على أي حال ، هذه هي الحالات من أعلى رأسي حيث قد يكون ترك التحذيرات مناسبة.

Answer 7

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

المشكلة في تنظيفها جميعًا ، هي أن الأمر يستغرق وقتًا قد يكون لديك أو لا تملكه. لكن نعم ، يجب عليك تنظيف أكبر عدد ممكن.

Answer 8

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

Answer 9

قم دائمًا بتنظيف تحذيراتك. إذا كان لديك حالة محددة حيث تعرف أن التحذير على ما يرام ، فقم بقمعه لتلك الحالة فقط.

في حين أن بعض التحذيرات يمكن أن تكون حميدة ، فإن معظمهم يدلون على مشكلة حقيقية في الكود.

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

Answer 10

واحدة من خصائص المبرمج الجيد حقًا هو أن الكود السيئ يمنحهم معدة غريبة.

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

Answer 11

أقوم دائمًا بتمكين جميع التحذيرات ، ثم ضبط مشروعي على التوقف عن البناء إذا كانت هناك أي تحذيرات.

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

هناك طرق لإزالة تحذير (على سبيل المثال #Pragma argsused).

دع المترجم يقوم بالعمل.

Answer 12

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

Answer 13

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

Answer 14

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

Answer 15

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

Answer 16

قم دائمًا بتنظيف جميع التحذيرات أو قمعها صراحة إذا لزم الأمر. يجب أن تكون الإعدادات الافتراضية للتحذيرات أعلى ممكنة عند التجميع (المستوى 4 على VS على سبيل المثال).

Answer 17

مديري الذي أنشأ بعض الرمز الذي أحافظ عليه الآن. إنه يستخدم أعلام البرمجيات لإخفاء تحذيراته من الحرمان.

عندما يكون لدي وقت أذهب إليه وأقوم بتنظيف ما بوسعي.

Answer 18

أحاول تجميع التعليمات البرمجية بمستوى عالٍ من التحذيرات وتنظيفها جميعًا ، باستثناء التحذيرات "الموقعة / غير الموقعة" ، والتي أنا متأكد من أنه يجب علي إصلاحها ولكن لا يمكن إزعاجها أبدًا.

الإصدار القصير: في G ++ أستخدم "-wextra -wno-sign-compare" والتخلص من جميع الرسائل.