ما هو شعورك تجاه طي الكود؟[مغلق]
https://stackoverflow.com/questions/5916
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
بالنسبة لأولئك الذين يعملون في بيئة Visual Studio، ما هو شعورك تجاه تغليف أي من التعليمات البرمجية الخاصة بك في #مناطق؟(أو إذا كان أي IDE آخر لديه شيء مماثل ...)
المحلول
9 من أصل 10 مرات، طي الكود يعني أنك فشلت في استخدام مبدأ شركة نفط الجنوب لما يستحق.
أشعر بنفس الشيء تقريبًا تجاه الفصول الجزئية.إذا كان لديك جزء من التعليمات البرمجية تعتقد أنه كبير جدًا، فأنت بحاجة إلى تقطيعه إلى أجزاء يمكن التحكم فيها (وقابلة لإعادة الاستخدام)، وليس إخفائها أو تقسيمها.
سوف يعضك في المرة القادمة التي يحتاج فيها شخص ما إلى تغييره، ولن يتمكن من رؤية المنطق المخفي في وحش مكون من 250 سطرًا من الطريقة.
كلما استطعت، اسحب بعض التعليمات البرمجية من الفئة الرئيسية إلى فئة المساعدة أو فئة المصنع.
foreach (var item in Items)
{
//.. 100 lines of validation and data logic..
}
ليست قابلة للقراءة كما
foreach (var item in Items)
{
if (ValidatorClass.Validate(item))
RepositoryClass.Update(item);
}
بلدي 0.02 دولار على أي حال.
نصائح أخرى
تم الحديث عن هذا على رعب الترميز.
اعتقادي الشخصي هو أنها مفيدة، ولكن مثل أي شيء زائد يمكن أن يكون أكثر من اللازم.
أستخدمه لترتيب كتل التعليمات البرمجية الخاصة بي إلى:
التعدادات
تصريحات
البنائين
طُرق
معالجات الأحداث
ملكيات
في بعض الأحيان قد تجد نفسك تعمل ضمن فريق حيث يتم تشجيع #المناطق أو إلزامها.إذا كنت مثلي ولا يمكنك تحمل العبث بالكود المطوي، فيمكنك إيقاف تشغيل المخطط التفصيلي لـ C#:
- خيارات -> محرر النصوص -> C# -> علامة التبويب المتقدمة
- قم بإلغاء تحديد "الدخول إلى وضع المخطط التفصيلي عند فتح الملفات"
أستخدم #Region لإخفاء التعليمات البرمجية القبيحة وغير المفيدة التي تم إنشاؤها تلقائيًا، والتي تنتمي حقًا إلى الجزء الذي تم إنشاؤه تلقائيًا من الفصل الجزئي.ولكن، عند العمل مع المشاريع القديمة أو المشاريع التي تمت ترقيتها، لا تتمتع دائمًا بهذا الرفاهية.
أما بالنسبة لأنواع الطي الأخرى، فأنا أقوم بطي الوظائف طوال الوقت.إذا قمت بتسمية الوظيفة جيدًا، فلن تضطر أبدًا إلى النظر إلى الداخل إلا إذا كنت تختبر شيئًا ما أو (تعيد) كتابته.
بينما أفهم المشكلة التي يواجهها جيف وآخرون.آل.لدينا مع المناطق، ما أنا لا فهم هو سبب الضرب كنترول+م,كنترول+ل من الصعب جدًا التعامل مع توسيع جميع المناطق في الملف.
أنا أستعمل زميل النص (Mac فقط) الذي يحتوي على Code Folding وأجده مفيدًا حقًا لوظائف الطي، وأنا أعرف ما تفعله وظيفة "getGet" الخاصة بي، ولست بحاجة إلى أن تشغل 10 أسطر من مساحة الشاشة القيمة جدًا.
لا أستخدمها أبدًا لإخفاء حلقة for، إذا كانت عبارة أو ما شابه ذلك ما لم أظهر الكود لشخص آخر حيث سأخفي الكود الذي رأوه لتجنب إظهار نفس الكود مرتين.
أفضّل الفصول الجزئية بدلاً من المناطق.
الاستخدام المكثف للمناطق من قبل الآخرين يعطيني أيضًا انطباعًا بأن شخصًا ما، في مكان ما، ينتهك مبدأ المسؤولية الفردية ويحاول القيام بأشياء كثيرة جدًا باستخدام كائن واحد.
@توم
يتم توفير فئات جزئية حتى تتمكن من فصل التعليمات البرمجية التي تم إنشاؤها تلقائيًا للأداة عن أي تخصيصات قد تحتاج إلى إجرائها بعد أن يقوم مولد التعليمات البرمجية بجزء منه.وهذا يعني أن التعليمات البرمجية الخاصة بك تظل سليمة بعد إعادة تشغيل برنامج إنشاء التعليمات البرمجية ولا يتم استبدالها.هذا أمر جيد.
أنا لست من محبي الفصول الجزئية - أحاول تطوير فصولي بحيث يكون لكل فصل مشكلة واحدة واضحة جدًا يكون مسؤولاً عنها.ولتحقيق هذه الغاية، لا أعتقد أنه ينبغي تقسيم شيء ذي مسؤولية واضحة عبر ملفات متعددة.لهذا السبب لا أحب الفصول الجزئية.
ومع ذلك، فأنا على الحياد بشأن المناطق.في أغلب الأحيان، لا أستخدمها؛ومع ذلك، فأنا أعمل يوميًا باستخدام تعليمات برمجية تتضمن مناطق - فبعض الأشخاص يثقلون عليها (طي الأساليب الخاصة في منطقة ثم طي كل طريقة في منطقتها الخاصة)، وبعض الأشخاص يثقلون عليها (طي التعدادات، طي الصفات، الخ).قاعدتي العامة، اعتبارًا من الآن، هي أنني لا أضع التعليمات البرمجية إلا في المناطق إذا (أ) من المحتمل أن تظل البيانات ثابتة أو لن يتم لمسها كثيرًا (مثل التعدادات)، أو (ب) إذا كانت هناك طرق يتم تنفيذها بدافع الضرورة بسبب تطبيق طريقة فرعية أو مجردة، ولكن مرة أخرى، لن يتم التطرق إليها كثيرًا.
لا يجب أبدًا استخدام المناطق داخل الأساليب.يمكن استخدامها لتجميع الأساليب ولكن يجب التعامل مع هذا بحذر شديد حتى لا يصاب قارئ الكود بالجنون.ليس هناك فائدة من أساليب الطي بواسطة معدّلاتها.لكن في بعض الأحيان قد يؤدي الطي إلى زيادة سهولة القراءة.على سبيل المثال.قد يكون من المفيد تجميع بعض الأساليب التي تستخدمها للتغلب على بعض المشكلات عند استخدام مكتبة خارجية ولن ترغب في زيارتها كثيرًا.ولكن يجب على المبرمج دائمًا البحث عن حلول مثل تغليف المكتبة بالفئات المناسبة في هذا المثال بالذات.عندما يفشل كل شيء آخر، استخدم الطي لتحسين إمكانية القراءة.
هذه مجرد واحدة من تلك المناقشات السخيفة التي لا تؤدي إلى أي مكان.إذا كنت تحب المناطق، استخدمها.إذا لم تقم بذلك، قم بتكوين المحرر الخاص بك لإيقاف تشغيلها.هناك، الجميع سعداء.
سيكون طي المنطقة أمرًا جيدًا إذا لم أضطر إلى الحفاظ على مجموعات المناطق يدويًا بناءً على ميزات الكود الخاص بي والتي تعتبر جوهرية في اللغة.على سبيل المثال، المترجم يعرف بالفعل أنه منشئ.يعرف نموذج التعليمات البرمجية الخاص بـ IDE بالفعل أنه مُنشئ.ولكن إذا كنت أرغب في رؤية عرض للكود حيث يتم تجميع المنشئات معًا، لسبب ما، يجب أن أكرر حقيقة أن هذه الأشياء هي منشئات، من خلال تجميعها معًا فعليًا ثم وضع مجموعة حولها.الأمر نفسه ينطبق على أي طريقة أخرى لتقسيم فئة/بنية/واجهة.ماذا لو غيرت رأيي وأردت رؤية العناصر العامة/المحمية/الخاصة مقسمة إلى مجموعات أولاً، ثم تجميعها حسب نوع العضو؟
يعد استخدام المناطق لتمييز الممتلكات العامة (على سبيل المثال) أمرًا سيئًا مثل إدخال تعليق زائد لا يضيف شيئًا إلى ما يمكن تمييزه بالفعل من الكود نفسه.
على أي حال، لتجنب الاضطرار إلى استخدام المناطق لهذا الغرض، قمت بكتابة وظيفة إضافية مجانية ومفتوحة المصدر لبرنامج Visual Studio 2008 IDE تسمى Ora.فهو يوفر عرضًا مجمعًا تلقائيًا، مما يجعل الحفاظ على التجميع الفعلي أو استخدام المناطق أقل أهمية بكثير. قد تجد أنه من المفيد.
أجد بشكل عام أنه عند التعامل مع تعليمات برمجية مثل الأحداث في C# حيث يوجد حوالي 10 أسطر من التعليمات البرمجية التي هي في الواقع مجرد جزء من إعلان الحدث (فئة EventArgs إعلان المفوض وإعلان الحدث) وضع منطقة حولهم ثم طيهم من الطريق يجعلها أكثر قابلية للقراءة قليلا.
أعتقد أنها أداة مفيدة، عندما تستخدم بشكل صحيح.في كثير من الحالات، أشعر أن الأساليب والتعدادات وغيرها من الأشياء التي غالبًا ما يتم طيها يجب أن تكون صناديق سوداء صغيرة.ما لم يكن عليك النظر إليها لسبب ما، فإن محتوياتها لا تهم ويجب أن تكون مخفية قدر الإمكان.ومع ذلك، لا أقوم أبدًا بطي الأساليب الخاصة أو التعليقات أو الفئات الداخلية.الأساليب والتعدادات هي الأشياء الوحيدة التي أطويها حقًا.
أسلوبي مشابه لبعض الطرق الأخرى هنا، باستخدام المناطق لتنظيم كتل التعليمات البرمجية في المنشئات والخصائص والأحداث وما إلى ذلك.
هناك مجموعة ممتازة من وحدات ماكرو VS.NET بواسطة Roland Weigelt متاحة من خلال مدخل مدونته، دعم أفضل للوحة المفاتيح للمنطقة # ...#endregion.لقد كنت أستخدمها منذ سنوات، وأرسم خريطة ctrl+.لطي المنطقة الحالية وctrl++ لتوسيعها.اكتشف أنها تعمل بشكل أفضل بكثير من وظيفة VS.NET الافتراضية التي تطوي/تكشف كل شيء.
أنا شخصياً أستخدم #المناطق طوال الوقت.أجد أنه يساعدني على إبقاء أشياء مثل الخصائص والإعلانات وما إلى ذلك منفصلة عن بعضها البعض.
ربما تكون هذه إجابة جيدة أيضًا!
يحرر:دانغ، بات سبقني إلى هذا!
أنا شخصياً أفضّل #المناطق، لكن زميلي القديم في العمل لا يتحمل إخفاء الأشياء.لقد فهمت وجهة نظره عندما عملت على صفحة تحتوي على 7 #مناطق، تم إنشاء 3 منها على الأقل تلقائيًا ولها نفس الاسم، ولكن بشكل عام أعتقد أنها طريقة مفيدة لتقسيم الأشياء والحفاظ على كل شيء أقل غير مرتب.
ليس لدي مشكلة حقًا في استخدام #region لتنظيم التعليمات البرمجية.شخصيًا، سأقوم عادةً بإعداد مناطق مختلفة لأشياء مثل الخصائص ومعالجات الأحداث والطرق العامة/الخاصة.
يقوم Eclipse بتنفيذ بعض من هذا في Java (أو PHP مع المكونات الإضافية) من تلقاء نفسه.يسمح لك بطي الوظائف وما شابه.أنا أميل إلى ذلك.إذا كنت أعرف وظيفة ما ولا أعمل عليها، فلن أحتاج إلى النظر إليها.
يحتوي Emacs على وضع ثانوي قابل للطي، لكنني أقوم بتشغيله من حين لآخر فقط.في الغالب عندما أعمل على بعض الأشياء الوحشية الموروثة من فيزيائي آخر من الواضح أنه كان لديه تعليمات أقل أو اهتم بشكل أقل بممارسات الترميز الخاصة به.
استخدام المناطق (أو رمز قابل للطي بطريقة أخرى) يجب لا علاقة لها بروائح الكود (أو بإخفائها) أو بأي فكرة أخرى لإخفاء الكود الذي لا تريد أن يراه الناس "بسهولة".
إن المناطق وطي التعليمات البرمجية يدور حول توفير طريقة لتجميع أقسام التعليمات البرمجية التي يمكن طيها/طيها/إخفائها بسهولة لتقليل مقدار "الضوضاء" الدخيلة حول ما تعمل عليه حاليًا.إذا قمت بإعداد الأشياء بشكل صحيح (بمعنى تسمية مناطقك بشيء مفيد، مثل اسم الطريقة المضمنة)، فيمكنك طي كل شيء باستثناء الوظيفة التي تقوم بتحريرها حاليًا والاستمرار في الحفاظ على مستوى معين من السياق دون الحاجة إلى رؤية الآخر فعليًا خطوط الكود.
ربما يجب أن يكون هناك بعض الإرشادات الخاصة بأفضل الممارسات حول هذه الأفكار، ولكنني أستخدم المناطق على نطاق واسع لتوفير بنية قياسية لملفات التعليمات البرمجية الخاصة بي (أقوم بتجميع الأحداث، والحقول على مستوى الفصل، والخصائص/الأساليب الخاصة، والخصائص/الأساليب العامة).تحتوي كل طريقة أو خاصية أيضًا على منطقة، حيث يكون اسم المنطقة هو اسم الطريقة/الخاصية.إذا كان لدي مجموعة من الأساليب المحملة بشكل زائد، فإن اسم المنطقة هو التوقيع الكامل ومن ثم يتم تغليف المجموعة بأكملها في منطقة تمثل مجرد اسم الوظيفة.
أنا شخصياً أكره المناطق.الكود الوحيد الذي يجب أن يكون في المناطق في رأيي هو الكود الذي تم إنشاؤه.عندما أفتح ملفًا، أبدأ دائمًا بالضغط على Ctrl+M+O.هذا يطوي إلى مستوى الطريقة.عندما يكون لديك مناطق فإنك لا ترى سوى أسماء المناطق.
قبل تسجيل الدخول، أقوم بتجميع الأساليب/الحقول بشكل منطقي بحيث تبدو جيدة بعد Ctrl+M+O.إذا كنت بحاجة إلى مناطق، فيجب عليك وضع الكثير من الخطوط في صفك.أجد أيضًا أن هذا شائع جدًا.
المنطقة ThisLooksLikeWellOrganized CodeBecauseIUseRegions
// إجمالي القمامة، لا يوجد هيكل هنا
المنطقة الداخلية
التعدادات
ملكيات
.ctors
طُرق
معالجات الأحداث
هذا كل ما أستخدمه من أجل المناطق.لم يكن لدي أي فكرة أنه يمكنك استخدامها داخل الأساليب.
تبدو فكرة رهيبة :)
ال رعب الترميز المقال الفعلي جعلني أفكر في هذا أيضًا.
بشكل عام، في الفصول الكبيرة، سأضع منطقة حول متغيرات الأعضاء، والثوابت، والخصائص لتقليل كمية النص التي يجب علي التمرير خلالها وترك كل شيء آخر خارج المنطقة.في النماذج، سأقوم عمومًا بتجميع الأشياء في "متغيرات الأعضاء، والثوابت، والخصائص"، ووظائف النموذج، ومعالجات الأحداث.مرة أخرى، هذا أكثر من ذلك، لذا لا أضطر إلى التمرير عبر الكثير من النص عندما أرغب فقط في مراجعة بعض معالجات الأحداث.
