هل يجب عليك استخدام المعرفات الدولية في Java/C#؟

Question

تسمح C# وJava تقريبًا بأي حرف في أسماء الفئات وأسماء الطرق والمتغيرات المحلية وما إلى ذلك.هل يعد استخدام أحرف غير ASCII ممارسة سيئة، واختبار حدود المحررين وأدوات التحليل الضعيفة وجعل القراءة صعبة على بعض الناس، أم أن الغطرسة الأمريكية هي الحجة الوحيدة ضدها؟

Answer 1

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

إن ما تسميه "الغطرسة الأمريكية" ليس ما إذا كان برنامجك يستخدم أسماء المتغيرات الدولية أم لا، بل هو عندما يعتقد برنامجك أن "Währung" و"Wahrung" هما نفس الكلمات.

Answer 2

أود أن أقول أن الأمر يعتمد كليًا على من يعمل على قاعدة التعليمات البرمجية.

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

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

Answer 3

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

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

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

Answer 4

اعتدت أن أعمل في فريق تطوير كان سعيدًا بمسح مؤخراتهم بأي اصطلاحات تسمية (وبالنسبة لأي ترميز آخر).صدق أو لا تصدق، كان الاضطرار إلى التعامل مع ä's و ö's في الكود عاملاً مساهمًا في استقالتي.على الرغم من أنني فنلندي، إلا أنني أفضل كتابة التعليمات البرمجية باستخدام إعدادات لوحة المفاتيح الأمريكية لأن الأقواس المتعرجة والمربعة تمثل صعوبة في الكتابة باستخدام لوحة المفاتيح الفنلندية (جرب alt الأيمن و7 و0 للتجاعيد).

لذلك أقول التمسك بأحرف ascii.

Answer 5

هنا مثال من حيث استخدمت معرفات غير ASCII، لأنني وجدت أنها أكثر قابلية للقراءة من استبدال الحروف اليونانية بأسمائها الإنجليزية.على الرغم من عدم وجود θ أو φ على لوحة المفاتيح (اعتمدت على النسخ واللصق).

لكن هذه كلها متغيرات محلية.سأبقي المعرفات غير ASCII خارج الواجهات العامة.

Answer 6

هذا يعتمد:

• هل يتوافق فريقك مع أي معايير حالية تتطلب استخدام ASCII؟
• هل سيتم إعادة استخدام الكود الخاص بك أو قراءته من قبل شخص لا يتحدث لغتك الأم؟
• هل تتصور سيناريو حيث ستحتاج إلى طلب المساعدة عبر الإنترنت، وبالتالي لن تتمكن من نسخ ولصق نموذج التعليمات البرمجية الخاص بك كما هو؟
• هل أنت متأكد من أن مجموعتك الكاملة من الأدوات تدعم تشفير التعليمات البرمجية؟

إذا أجبت بـ "نعم" على أي مما سبق، فابق على ASCII فقط.إذا لم يكن الأمر كذلك، المضي قدما على مسؤوليتك الخاصة.

Answer 7

إذا تجاوزت المتطلبات الأخرى لديك بعد ذلك رمز إضافي (IMHO أكثر أهمية) - ما مدى صعوبة كتابة الرمز.

على لوحة المفاتيح العادية، الطريقة الوحيدة التي أعرفها لكتابة الحرف ç هي الضغط باستمرار على alt، والضغط على 0227 على لوحة المفاتيح الرقمية، أو النسخ واللصق.

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

Answer 8

جزء من المشكلة هو أن لغة Java/C# ومكتباتها تعتمد على كلمات إنجليزية مثل if و toString().أنا شخصياً لا أرغب في التبديل بين اللغة غير الإنجليزية واللغة الإنجليزية أثناء قراءة التعليمات البرمجية.

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

Answer 9

سألتزم بأحرف ASCII لأنه إذا كان أي شخص في فريق التطوير الخاص بك يستخدم SDK يدعم ASCII فقط أو كنت تريد جعل التعليمات البرمجية الخاصة بك مفتوحة المصدر، فقد تنشأ الكثير من المشكلات.أنا شخصياً لن أفعل ذلك حتى لو كنت لا تخطط لجلب أي شخص لا يتحدث اللغة إلى المشروع، لأنك تدير مشروعاً تجارياً ويبدو لي أن من يدير مشروعاً تجارياً يريد أن يتوسع عمله وهو ما يعني في هذا اليوم وهذا العصر تجاوز الحدود الوطنية.رأيي هو أن اللغة الإنجليزية هي لغة العالم، وحتى إذا قمت بتسمية المتغيرات الخاصة بك بلغة مختلفة، فليس هناك فائدة تذكر من استخدام أي أحرف غير ASCII في برمجتك.اترك الأمر للغة للتعامل معها إذا كنت تتعامل مع بيانات UTF8:يتمتع برنامج iPhone الخاص بي (الذي يتضمن الكثير من بيانات المستخدم التي تنتقل بين الهاتف والخادم) بدعم كامل لـ UTF8، ولكن لا يحتوي على UTF8 في كود المصدر.يبدو الأمر وكأنه يفتح مثل هذه العلبة الكبيرة من الديدان دون أي فائدة تقريبًا.

Answer 10

هناك خطر آخر لاستخدام أحرف غير ASCII، على الرغم من أنه من المحتمل أن يكون ذلك مؤلمًا فقط في الحالات الغامضة.الحروف المسموح بها هي مُعرف من حيث الأساليب Character.isJavaIdentifierStart(int) و Character.isJavaIdentifierPart(int), ، والتي تم تعريفها من حيث Unicode.ومع ذلك، يعتمد الإصدار الدقيق من Unicode المستخدم على إصدار نظام Java الأساسي، كما هو محدد في الوثائق الخاصة بـ java.lang.Character.

نظرًا لأن خصائص الأحرف تتغير قليلاً من إصدار Unicode إلى الإصدار التالي، فمن الممكن (ولكن من المحتمل جدًا) أن يكون لديك معرفات صالحة في إصدار واحد من Java، ولكن ليس في الإصدار التالي.

Answer 11

كما أشرنا سابقًا، ما لم تتطابق أسماء الطرق في الغالب مع اللغة، فمن الغريب بعض الشيء تبديل اللغات باستمرار أثناء القراءة.

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

ä/æ -> ae, ö/ø -> oe, å -> aa, ü -> ue

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