صيانة التعليق

Question

ما هي الأساليب التي تستخدمها عند تعديل التعليمات البرمجية الموجودة خاص؟

وعلى سبيل المثال: لنفترض أنك تعديل قاعدة عمل داخل الأسلوب. هل بمناسبة القسم تعديلها مع تعليقات خاصة؟

وأي الترميز / التعليق معايير استخدام الرمز عند تعديل؟

Answer 1

هل تعني شيئا مثل:

foo();  // changed by SecretWiz, 20090131

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

svn blame

Answer 2

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

Answer 3

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

Answer 4

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

// modified by A.B. on 11/23/99 to fix issue #123456

ولقد رأيت مثل هذه التعليقات في مصدر برنامج دينا وأنها تجعل أي إحساس سنوات أسفل الخط. الذين هيك هو A.B.، وما هو قضية # 123456؟ إذا كان رمز لا يزال هنا، هل هذا يعني أن شخصا ما يخطط على المتداول هذه التغييرات مرة أخرى في المستقبل؟

وهذه التعليقات ليس لها قيمة وتؤدي إلا إلى فوضى التعليمات البرمجية.

Answer 5

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

ومنها مثلا. GiveRebateIfValidCoupon();

Answer 6

و"أي الترميز / التعليق المعايير التي تستخدمها عند تعديل مدونة؟"

نعم. جعل فرعية جديدة. ترك القانون القديم وحده إلا في حالة نادرة أن لم يختبر بشكل صحيح وكان مخطئا في الواقع.

والتغييرات في متطلبات يعني إضافة فرعية واختبارات جديدة للتعامل مع قواعد العمل الجديدة.

Answer 7

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

وبخلاف ذلك، ونحن نعتمد على التحكم بالمصادر.

Answer 8

والرمز يجب أن تتوافق أي معايير الترميز لديك أو مؤسستك.

وهكذا، لا، لا ينبغي أن يكون هناك أي تعليقات خاصة أن تم تعديل قانون - جميع أو على الأقل معظمها، وتعديل قانون عاجلا أو آجلا.

إذا كان هناك رمز أنك ورثت التي لا تتوافق مع معايير التعليق، ثم بكل الوسائل إضافة تعليقات كما كنت <لأ href = "http://en.wikipedia.org/wiki/Code_refactoring" يختلط = "نوفولو noreferrer "> ريفاكتور التعليمات البرمجية. إذا كان رمز هو حقا القديمة وغير الشرعيين، وبطبيعة الحال هذا يعني مضيفا الوثائق.

وانه لامر جيد لفهم التعليمات البرمجية قبل تعديله (من دون وسيلة).

Answer 9

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

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

Answer 10

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

ولقد استخدمت للحفاظ على كود إهمال القديم في مشاريعي، ولكن مع مرور الوقت وهو المشروع الذي كان ينبغي أن يكون فقط بضعة آلاف من خطوط انتهى به الأمر إلى أكثر من 10،000 ويصعب السيطرة عليها.