Yarn: البادئات مقابل اللواحق في تسمية الفئة

تم إنشاؤها على ٢٩ أكتوبر ٢٠١٨  ·  17تعليقات  ·  مصدر: FabricMC/yarn

"BiomeDesert" مقابل "DesertBiome" ، إلخ. أو "ترجمة المكونات" مقابل "TranslatableComponent".

الأول له مزايا عند فرز الأسماء في محرر وهو المفضل لدي ؛ هذا الأخير أكثر شيوعًا في تطوير Java ويفضل من قبل معظم الأشخاص الآخرين.

discussion

التعليق الأكثر فائدة

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

ال 17 كومينتر

من مناقشة خاصة مع asiekierka في ذلك اليوم:

22:34 <kasheek> I have a 'block' package with:
22:34 <kasheek> 'BedBlock'
22:34 <kasheek> 'CactusBlock'
22:34 <kasheek> 'MagmaBlock'
22:34 <kasheek> and I import them all into one of my classes. I can:
22:34 <kasheek> - look at the imports, in alphabetical order, without reading "Block" before each word
22:34 <kasheek> - search for ".BedBlock" and get results for BedBlock *and* BedBlockEntity *and* BedBlockEntityRenderer
22:34 <asie> that last one
22:34 <asie> that's a good argument

أود أن أزعم أن البحث في معظم Java IDEs الحديثة سيكون غامضًا بدرجة كافية بحيث تظهر النتيجة بغض النظر عن طلب BlockBed / BedBlock.

أعتقد أن Mojang يستخدم إما لاحقات (BedBlock) أو مجرد أسماء (Bed).

[قص!]

من المحتمل أن تكون هذه الفئات في نفس الحزمة ويتم تسميتها على النحو التالي:

RenderType
RepeaterBlock
RotatedPillarBlock
Rotation
SandBlock

مثال آخر ، والذي يُظهر أيضًا أن أسماء Mojang لا تحتوي على بادئات I للواجهات:

[قص!]

السابق له مزايا عند فرز الأسماء في محرر

هذا صحيح إذا تم تعيين كل شيء في حزمة واحدة كبيرة "حوض" (على سبيل المثال net.minecraft.src ) ، لكنه بديل سيء لتخطيط الحزم بشكل صحيح. وإذا تم وضع الفئات في حزم مثل blocks ، items ، entities ، تصبح البادئات زائدة عن الحاجة.

بينما جهودك جديرة بالثناء ، يرجى عدم نشر محتوى MCP هنا. الرجاء استخدام تعيينات Enigma أو تعيينات Tiny من pomf لتوضيح وجهة نظرك في المرة القادمة ، أو التلميح إليها دون نشر الأسماء مباشرةً.

البحث موضع تقدير ، مع ذلك! كنا على علم بالفعل بأن Mojang لا يستخدم البادئات I بفضل العميد ، لكن التلميح الآخر مثير جدًا للاهتمام. كنت أخطط للنظر في الترتيب الأبجدي بنفسي في مرحلة ما ، ولكن لا يلزم أيضًا افتراض أن "الأسماء الداخلية" لماين كرافت مثالية أو مناسبة لبيئة تطوير أكثر تعديلًا.

أنا شخصياً أحب أن يكون لديك البادئات ، لأن هذا يعني أن جميع العناصر يتم تجميعها معًا ، ويتم تجميع جميع المناطق الأحيائية معًا ، إلخ. بالطبع ، الحجة المضادة هي أن اللواحق تجعل كل شيء مشتركًا في شيء يتم تجميعه معًا ، مثل IronIngot ، IronSword ، IronBlock ، IronChestplate ، إلخ.

Boundarybreaker في الواقع ، إنها في حزم على أي حال. لذلك ، في .block ، تم تجميع الأشياء معًا بالفعل. لا يهم ما إذا كانت BlockBed و BlockChest أو BedBlock و ChestBlock.

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

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

أجد أنه يعمل بشكل أفضل عند البحث عن نوع من الكائنات في IDE الخاص بي ، وبصراحة يبدو أفضل بالنسبة لي.

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

أعتقد أن جميع التعديلات تستخدم البادئة لأنها تستخدم أسماء MCP وأسماء MCP في الغالب تستخدم البادئة لأنه منذ وقت طويل تم تفكيك جميع minecraft في حزمة واحدة net.minecraft.src . ومع ذلك ، بشكل خاص في الكود الجديد ، الميزات هناك الكثير من الأمثلة التي تستخدم مع اللواحق. على سبيل المثال ، تطبيقات ILightEngine ، ChunkTask ، SurfaceBuilder ، IWorldCarver ، IChunkGenSettings ، التكوين / القطع / فئات البنية للهياكل. يحتوي كود الوصفات وأجيال النهب على العديد من الفئات المشتقة التي لا تتضمن اسم الفئة الأساسية.

✓ يفكر في إنهاء اسم الفئات المشتقة باسم الفئة الأساسية.

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

من C # إرشادات التصميم

أعتقد أن استخدام البادئات يحبسك في هذا المخطط ولا يسمح بأي "حكم". ولكن ربما لا تكون ضرورية حقًا للتسلسلات الهرمية الواسعة للميراث ، مثل Block أو Item

لقد فكرت للتو ، انظر إلى تطبيقات JEI. لا توجد سوابق سابقة في واجهة برمجة التطبيقات ، ولذا فإن جميع فئات دعم JEI في مجتمع التعديل هي آلة + فئة / غلاف / إلخ.

لم يكن لدى MCP نقل اللاحقة بسبب التبعيات واسعة النطاق من التعديلات الموجودة. هذا ليس هو الحال في النسيج.

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

لقد فكرت للتو: البادئات! = الإملاء العكسي ، كما أنها تأتي في نكهات مختلفة

أمثلة من MCP: [snip!]

أعتقد أنك ستوافقين على أن التناقض في التسمية أمر سيء ، والأسماء مثل [snip!] مروعة.

ربما فات الأوان مع هذا ...

يرجى التوقف عن نشر أمثلة MCP على قنوات الاتصال pomf ، أو سأضطر إلى حظرك من مستودع GitHub.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

Runemoro picture Runemoro  ·  4تعليقات

Awakened-Redstone picture Awakened-Redstone  ·  4تعليقات

Runemoro picture Runemoro  ·  3تعليقات

copygirl picture copygirl  ·  6تعليقات

liach picture liach  ·  4تعليقات