Jdbi: حدد موضع قوس Allman vs K&R وحافظ على ثباتك

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

كان الاصطلاح حالة ثعبان للمتغيرات المحلية :-)

إنه ليس شائعًا جدًا في Java ، ولكن fwiw ، لقد نشأت وأحبها وما زلت أفعلها بدافع العادة حتى أتوقف عن نفسي!

هيه. لقد فعلنا دائمًا أسلوب Ning في JDBI ، فلماذا التغيير الآن؟

إنه أسلوب "allman" للفئات والطرق و K&R لبيانات التحكم على الحساب الذي يمكن قراءته بشكل أفضل في مواقفهم الخاصة. أيضا ، هو كذلك

if (...) {
...
}
else {
...
}

و لا

if (...) {
...
} else {
...
}

على الحساب الذي يسمح لك الأول بتحديد كتلة else الكاملة بدون حركة المؤشر إلى اليسار واليمين والأخيرة لا (مرحبًا ، اللمحات العالقة في vi :-)).

مهما فعلنا ، أشعر أن الوقت قد حان لبدء المكوّن الإضافي checkstyle في التحقق من صحة التنسيق أثناء الإنشاءات.

آه بالطبع ، قضية ركوب الدراجات تجذب معظم التعليقات ؛)

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

أقترح التبديل إلى أسلوب K&R الذي يسهل تطبيقه باستخدام أسلوب checkstyle وعادة ما يتم تعيينه على أنه الإعداد الافتراضي لغالبية Java IDEs.

أنا شخصياً أحب مظهر أسلوب قوس أولمان.

ومع ذلك ، أود أن أزعم أنه يجب علينا التبديل إلى K&R لأنه ما تستخدمه الغالبية العظمى من مطوري Java. تقوم أقواس Allman فقط بإضافة العمل إلى العلاقات العامة. على سبيل المثال https://github.com/jdbi/jdbi/pull/474#discussion_r77747433

في الواقع ، لا أمانع في المضي قدمًا ، واعتماد دليل أسلوب جافا من Google :

• إنه موثق جيدًا ويتم تقديم التبرير لكل قاعدة تقريبًا.
• إنه مدعوم بنمط checkstyle .
• هناك ملحق Maven يقوم بتنسيق الكود الحالي إلى هذا النمط.
• تحتفظ Google بتعريفات تنسيق الكود لكل من Eclipse و IntelliJ

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

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

هل لدينا أي بيانات لدعم تأكيد "مبرمجي جافا مثل K&R"؟ لقد وجدت هذا: http://sideeffect.kr/popularconvention/#java
والذي يبدو أنه يشير إلى أن K&R تحظى بشعبية مضاعفة مثل Allman ، وأن 5٪ من المبرمجين مجانين حرفيًا ؛)

سيؤدي هذا أيضًا إلى حدوث ألم في الدمج من master إلى jdbi3 أثناء محاولة نقل الميزات.
أعتقد أنني أميل نحو "الأقواس ذات النمط K&R ، Google Java Style مشجع للغاية ولكن ليس مطلوبًا بنسبة 100٪ ، فقط اجعل الكود قابلاً للقراءة" - ويمكننا تمكين أي مجموعة فرعية من أدوات الداما نجدها مفيدة أكثر من كونها مزعجة.

سأدرج أيضًا في السجل لأنني لا أهتم كثيرًا بهذا الأمر في كلتا الحالتين. أحب الكود المقروء أكثر من النقاش حول قواعد النمط :)

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

نحن نستخدم مشتقًا من أسلوب Ning (أعتقد أن هذا هو أسلوب martint ) في Airlift و Presto وهو قريب جدًا مما يستخدمه Jdbi الآن. قواعد Checkstyle الخاصة بنا جيدة بما يكفي الآن لأن قمل التنسيق أصبح نادرًا نسبيًا في مراجعة الكود.

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

IntelliJ: https://github.com/airlift/codestyle
Checkstyle: https://github.com/prestodb/presto/blob/master/src/checkstyle/checks.xml

بعد النظر في منسق كود google والإعداد المسبق لنمط كود google في checkstyle - ربما تكون هذه مشكلة أكثر مما تستحق.

@ jdbi / Contributors أنا جيد لإغلاق هذا إذا وافق باقي الفريق.

كل ألوان الدراجات مهمة: P