استخدام المسافة البيضاء العمودية

Question

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

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

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

Answer 1

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

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

Answer 2

أعتقد أن أحد أهم الأشياء هو تجميع خطوة منطقية معًا ، مثل:

foo.setBar(1);
foo.setBar2(2);
foo.writeToDatabase();

bar.setBar(1)
bar.setBaz(2);
bar.writeToDatabase();

وبهذه الطريقة ، يكون القراءة أسهل في القراءة ، وهو أكثر وصفية ، بالنسبة لي على أي حال.

Answer 3

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

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

Answer 4

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

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

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

في الفصول الدراسية ، أضع في بعض الأحيان مساحة بيضاء بين طرق/وظائف الأعضاء ، وأحيانًا لا. في C ++ ، وضعت مساحة بيضاء قبل الوصول إلى محددات الوصول.

وضعت مساحة بيضاء بين الفصول الدراسية ، (في بعض الأحيان ليس للفصول الداخلية المجهولة في Java) وبين الوظائف خارج الفئات.

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

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

Answer 5

من المعروف لعقود من الزمن أن قدرة المبرمج على فهم الكود محدودة بشكل عام من خلال مقدار ما يمكنه رؤيته في وقت واحد. (انظر على سبيل المثال Weinberg ، "Psychology of Computer Programming" ، وهي عبارة عن قديمة ولكن الغابة.) في الأيام الخوالي من قوائم الورق ، سيحصل المبرمجون على طاولات كبيرة وينشرون صفحات متعددة من القائمة. في الوقت الحاضر ، فإن العقارات على الشاشة أفضل إلى حد ما من أيام 24 × 80 ، لكنني ما زلت أميل إلى تقليل استخدام المسافة البيضاء العمودية ، لأن الكثير من الخطوط الفارغة تأخذ مساحة الشاشة التي يمكن أن تظهر لي الرمز الفعلي.

Answer 6

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

أكثر من خط فارغ واحد في وقت واحد يبدو خارج المكان قليلا ، على الرغم من.

Answer 7

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