محوّل حالة الأحرف

كلّ لغة برمجة ومنظومة كتابة طوّرت اصطلاحاً خاصّاً: JavaScript وJava وC# يستخدمون camelCase لأسماء المتغيّرات وPascalCase لأسماء الفئات؛ Python وRuby يستخدمون snake_case لأسماء المتغيّرات والدوال؛ URLs وعناوين الملفّات تستخدم kebab-case لأنّ المسافات والشُرَط السفليّة تُسبّب مشاكل في الترميز؛ الثوابت في كلّ اللغات تستخدم CONSTANT_CASE. التحويل اليدويّ بين هذه الصيغ مُمِلّ ومُعرَّض لأخطاء صغيرة لكنّها مكلفة (حرف كبير في موضع صغير يكسر استيراد ملفّ).

الأداة تحلّ المشكلة بعرض النصّ المُدخَل في 11 صيغة في وقت واحد. تنسخ الصيغة التي تحتاجها بنقرة، تلصقها في الكود، وتنتهي العمليّة. كلّ الصيغ تُولَّد من نفس الكلمات المستخرَجة، فلا اختلاف في الكلمات بين الصيغ، فقط في الفواصل والحالة.

قيمة الأداة الحقيقيّة ليست التحويل اليوميّ، بل توفير الوقت في حالات الترحيل (migration): استيراد بيانات من ملفّ CSV بصيغة Title Case إلى قاعدة بيانات تستخدم snake_case، أو تحويل اسم ميزة من Notion (بصيغة طبيعيّة) إلى مفتاح i18n بصيغة kebab-case.

صيغ لغويّة (للنصّ العامّ):

UPPER: كلّ الأحرف كبيرة. HELLO WORLD. للعناوين البارزة، التنبيهات، رؤوس الجداول.

lower: كلّ الأحرف صغيرة. hello world. للنصّ العاديّ المُطبَّع.

Title Case: أوّل حرف من كلّ كلمة كبير. Hello World. لعناوين المقالات، أسماء الكتب، رؤوس الأعمدة.

Sentence case: أوّل حرف من الجملة كبير فقط. Hello world. للنصّ الجاري، رسائل المستخدم، التنبيهات الودّيّة.

صيغ برمجيّة (لأسماء المُعرِّفات):

camelCase: أوّل كلمة صغيرة، باقي الكلمات تبدأ بحرف كبير. helloWorld. JavaScript، Java، C#، Swift — للمتغيّرات والدوال.

PascalCase: كلّ كلمة تبدأ بحرف كبير. HelloWorld. أسماء الفئات (classes) والأنواع (types) في معظم اللغات.

snake_case: كلّ الكلمات صغيرة مفصولة بشرطة سفليّة. hello_world. Python، Ruby، Rust، أعمدة قواعد البيانات.

kebab-case: كلّ الكلمات صغيرة مفصولة بشرطة. hello-world. URLs، أسماء ملفّات CSS، خصائص HTML، مفاتيح i18n.

CONSTANT_CASE: كلّ الكلمات كبيرة مفصولة بشرطة سفليّة. HELLO_WORLD. ثوابت في كلّ اللغات تقريباً، متغيّرات البيئة.

dot.case: كلّ الكلمات صغيرة مفصولة بنقطة. hello.world. مسارات YAML، مفاتيح i18n الهرميّة، خصائص JavaScript المتداخلة.

path/case: كلّ الكلمات صغيرة مفصولة بشرطة مائلة. hello/world. مسارات نظام الملفّات، مسارات URL.

الأداة تستخدم ثلاث قواعد متتابعة، تُطبَّق بالترتيب:

القاعدة 1 — الفواصل الصريحة: أيّ مسافة، شرطة سفليّة _، شرطة -، نقطة .، أو شرطة مائلة / تُعدّ فاصل كلمات. هذه أبسط قاعدة وتغطّي معظم المُدخَلات.

القاعدة 2 — الانتقال من حرف صغير إلى كبير: helloWorld → hello / World. هذه القاعدة هي ما يجعل تحويل camelCase إلى snake_case ممكناً دون فواصل صريحة.

القاعدة 3 — الانتقال من حرف إلى رقم أو العكس: foo2bar → foo / 2bar وv3API → v / 3 / API. مفيد لأسماء إصدارات وأكواد إنتاج.

قاعدة خاصّة للاختصارات (Acronym handling): HTTPServer تُقسَم إلى HTTP / Server لا HTTPSer / ver. الأداة تكتشف الأحرف الكبيرة المتتابعة وتعاملها ككتلة واحدة حتّى يأتي حرف صغير. هذا يحفظ الاختصارات المتعارف عليها في الكود (XMLParser، URLValidator، APIClient).

هناك حالات حدّيّة: ماذا عن iOS؟ الأداة تتعامل معها ككلمة واحدة محفوظة (موجودة في قائمة استثناءات صغيرة). نفس المعاملة لـ iPad، iPhone، eBay، jQuery.

مُدخَل: arabicReadabilityScore

UPPER: ARABIC READABILITY SCORE

snake_case: arabic_readability_score

kebab-case: arabic-readability-score

CONSTANT_CASE: ARABIC_READABILITY_SCORE

dot.case: arabic.readability.score

مُدخَل: HTTPSConnection.openStream

الكلمات المستخرَجة: HTTPS / Connection / open / Stream

PascalCase: HttpsConnectionOpenStream (الاختصار يصبح Https)

kebab-case: https-connection-open-stream

العربيّة بلا «حالة» — لا يوجد فرق بين «أحمد» الكبيرة و«أحمد» الصغيرة، فالحروف العربيّة شكل واحد بصرف النظر عن موقعها. الحروف العربيّة تمرّ كما هي عبر كلّ التحويلات دون تعديل في الحالة، لكنّها تتأثّر بالفواصل: لو أدخلت «اسم المتغيّر» ستحصل على «اسم_المتغيّر» في snake_case.

هذه الأداة مخصّصة بالدرجة الأولى للنصّ اللاتينيّ في أسماء المتغيّرات، الـslugs، والثوابت. لو احتجت تحويل نصّ عربيّ خالص إلى slug مناسب لـURL، استخدم أداة منفصلة تُجري نقلاً صوتياً (transliteration) قبل التحويل.

الأرقام في بداية الاسم: 2024Report ينتج عنه 2024_report في snake_case، لكنّ هذا قد لا يكون اسماً صالحاً للمتغيّر في بعض اللغات (JavaScript لا يقبل بداية بالأرقام). تحقّق من اللغة المستهدفة قبل النسخ.

الاختصارات في النهاية: parseHTML يتحوّل إلى parse_html في snake_case — تحويل صحيح. لكنّ بعض المطوّرين يفضّلون parse_HTML. الأداة تعتمد المعيار الشائع.

كلمات محجوزة: الأداة لا تتحقّق إذا كان الاسم محجوزاً في لغة برمجة (class، function، return). راجع قائمة الكلمات المحجوزة قبل استخدام النتيجة.

التحويل ليس قابلاً للعكس دائماً: iOSApp → i_o_s_app ثمّ العودة إلى camelCase تُنتج iOSApp لكن مع بعض المُدخَلات قد تحدث خسارة دقيقة في الاختصارات.

الاستخدام النموذجيّ: تستلم اسم ميزة من فريق المنتج بصياغة طبيعيّة («تتبّع الوقت اليوميّ»). تكتبه بالإنجليزيّة («daily time tracking»). تلصقه في الأداة وتنسخ:

PascalCase لاسم المكوّن: DailyTimeTracking.

camelCase لاسم الـhook: useDailyTimeTracking.

kebab-case لاسم الملفّ: daily-time-tracking.tsx.

snake_case لاسم العمود في قاعدة البيانات: daily_time_tracking.

CONSTANT_CASE لمفتاح ميزة: FEATURE_DAILY_TIME_TRACKING.

كلّ ذلك بنقرة على كلّ صيغة دون الحاجة لإعادة الكتابة.

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

JavaScript/TypeScript: camelCase للمتغيّرات والدوال، PascalCase للفئات والأنواع والمكوّنات، CONSTANT_CASE للثوابت العالميّة، kebab-case لأسماء الملفّات في معظم الأطر الحديثة (مع استثناء React الذي يفضّل PascalCase لملفّات المكوّنات).

Python: snake_case للمتغيّرات والدوال، PascalCase للفئات، UPPER_SNAKE_CASE للثوابت، snake_case لأسماء الملفّات. PEP 8 هو المرجع الرسميّ.

Ruby: snake_case للمتغيّرات والدوال، PascalCase للفئات والوحدات (modules)، SCREAMING_SNAKE_CASE للثوابت، snake_case.rb للملفّات.

Go: camelCase للقابليّة الخاصّة (unexported)، PascalCase للقابليّة العامّة (exported). هذا تمييز نحويّ في اللغة، لا اصطلاح اختياريّ.

Rust: snake_case للمتغيّرات والدوال والوحدات والملفّات، PascalCase للأنواع والصفات (traits)، SCREAMING_SNAKE_CASE للثوابت والمتغيّرات الساكنة.

Java/Kotlin: camelCase للمتغيّرات والدوال، PascalCase للفئات، CONSTANT_CASE للثوابت، com.example.package (نقطة منفصلة بأحرف صغيرة) لأسماء الحزم.

CSS: kebab-case لخصائص CSS ومتغيّراتها (--my-color)، BEM (block__element--modifier) للأسماء المركّبة.

HTML/URL: kebab-case دائماً (my-page.html، /blog/article-name). الأحرف الكبيرة في URL تعمل تقنياً لكنّها تكسر بعض أنظمة التخزين المؤقّت.

معظم قواعد البيانات الإنتاجيّة تستخدم snake_case: users، order_items، created_at. الأسباب تاريخيّة وعمليّة: أسماء جداول وأعمدة من السبعينات بنيت على SQL غير الحسّاس للحالة، فإضافة الشرطة السفليّة كانت الطريقة الوحيدة لفصل الكلمات.

التحويل بين اصطلاح قاعدة البيانات (snake_case) واصطلاح لغة التطبيق (غالباً camelCase) يحدث عادة في طبقة الـ ORM. مكتبات مثل TypeORM أو Prisma تطبّق التحويل تلقائياً، فتعرف باسم الحقل بالـ camelCase في الكود وتتحوّل إلى snake_case عند الكتابة لقاعدة البيانات.

الإكثار من الاختصارات في أسماء الأعمدة (usr_nm بدل user_name) خطأ شائع في البيانات القديمة. لا توفّر شيئاً يذكر من حيث التخزين، وتجعل الكود أصعب قراءة وإلحاقاً بفرق جدد. القاعدة: استخدم الكلمات الكاملة إلّا في حالات نادرة (id، url).

أنظمة التشغيل: Linux وmacOS حسّاسة للحالة (File.tsx ≠ file.tsx). Windows غير حسّاس. لتفادي الكوارث (تعمل على ماك ثمّ تفشل على خادم Linux)، استخدم kebab-case أو snake_case بأحرف صغيرة دائماً.

أطر العمل: Next.js يستخدم kebab-case لمسارات app router ولكن يقبل PascalCase لأسماء المكوّنات. Vue يفضّل PascalCase لملفّات المكوّنات. Django يستخدم snake_case لأسماء التطبيقات.

المُعرِّفات في URLs: kebab-case هو الخيار الأمثل بإجماع. example.com/my-product أوضح من example.com/MyProduct أو example.com/my_product. محرّكات البحث تعامل الشُرَط كفواصل كلمات، بينما الشُرَط السفليّة تعتبر جزءاً من نفس الكلمة.

مكتبات الترجمة (i18next، react-intl، vue-i18n) تتطلّب مفاتيح فريدة لكلّ نصّ. الاصطلاح الأشهر هو dot.case الهرميّ:

auth.login.title، auth.login.email_label، auth.login.password_label، auth.login.submit_button.

الهيكل الهرميّ يجعل الترتيب منطقياً ويسهّل العثور على المفتاح. البديل الأقصر هو snake_case (auth_login_title) لكنّه يفقد التراتبيّة. اختر اصطلاحاً واحداً والتزم به في المشروع كاملاً.

للمشاريع الكبيرة، أنشئ ملفّاً لكلّ ميزة بدلاً من ملفّ ضخم واحد: locales/ar/auth.json، locales/ar/dashboard.json. هذا يقلّل تعارضات git ويسرّع تحميل ملفّ الترجمة المطلوب فقط.

الاختصارات والكلمات الخاصّة تكسر القواعد العامّة للحالة. أمثلة شهيرة: iOS، iPhone، eBay، jQuery، npm، YouTube، WordPress. هذه أسماء علم رسميّة بحالات محدّدة من شركاتها الأصليّة. تحويلها التلقائيّ إلى iOS → Ios أو npm → Npm خطأ يكشف ضعف الأداة.

أداتنا تحتفظ بقاموس داخليّ من 200+ اسم علم تقنيّ يُحافَظ على حالته كما هي. لو وجدت اسماً مفقوداً (مثل علامة تجاريّة محلّيّة)، يمكنك إضافته إلى قائمة الاستثناءات قبل التحويل. هذه الميزة ضروريّة لو كنت تنشر محتوى تقنيّاً يحوي أسماء شركات وأدوات بكثرة.

حالة طرفيّة أخرى: الاختصارات بنقاط (U.S.A.، e.g.، i.e.). تحويلها إلى حالة العنوان قد ينتج U.s.a. وهو خاطئ. القاعدة: لو كانت الكلمة كلّها أحرف كبيرة بنقاط، اتركها كما هي. أداتنا تكشف هذا النمط تلقائيّاً وتطبّقه.

الحالات المختلطة مثل McDonald، O'Brien، van der Berg أيضاً تحتاج معاملة خاصّة. أسماء الأشخاص لا تتّبع قاعدة «الحرف الأوّل كبير» دائماً. لو كنت تعالج قاعدة بيانات أسماء، فعّل خيار «احفظ حالة الكلمات المُختلطة» الذي يكشف الأنماط مثل aBa و a'a ويتجنّب تحويلها.

في فرق التطوير الكبيرة، تطبيق اسم اتّفاقيّة (naming convention) موحّدة يدويّاً غير عمليّ. الحلّ هو دمج التحقّق في أدوات linter. ESLint يوفّر قاعدة @typescript-eslint/naming-convention التي تُجبر استخدام camelCase للمتغيّرات، PascalCase للأصناف، UPPER_SNAKE_CASE للثوابت. القاعدة تعمل على كلّ ملفّ في pull request.

للغة Python، أداة pylint تفحص الالتزام بـPEP 8: snake_case للدوالّ والمتغيّرات، PascalCase للأصناف، UPPER_SNAKE_CASE للثوابت. تشغيل pylint في CI يضمن أنّ كلّ كود يدخل المستودع يتّبع الاتّفاقيّة.

للحالات الانتقاليّة (تحويل مستودع كامل من snake_case إلى camelCase)، استخدم أداتنا على عيّنة، تحقّق من النتيجة، ثمّ طبّق التحويل عبر سكربت refactor آليّ مثل jscodeshift أو ast-grep. لا تستبدل يدويّاً ولا تستبدل بنصّ ساذج لأنّ ذلك يخاطر بتغيير كلمات داخل تعليقات أو سلاسل نصّيّة.

وثّق قرار الاتّفاقيّة في ملفّ STYLE.md في المستودع. الإصدار الأوّل من المشروع قد يتساهل، لكنّ مع نموّ الفريق، الاختلافات الصغيرة في التسمية تتحوّل إلى ديون تقنيّة. اتّفقوا مبكّراً وفرضوا القاعدة آليّاً.

إعادة تسمية كاملة لمستودع موجود تأخذ تخطيطاً. الخطوات: (1) اِبدأ بفرع git منفصل، (2) طبّق التحويل آليّاً على دفعة واحدة، (3) شغّل كلّ الاختبارات، (4) صحّح الأخطاء الناتجة عن تحويل سلاسل نصّيّة أو تعليقات بالخطأ، (5) ادمج بـsquash merge لتبقى تاريخ مفرد للتحويل.

لا تخلط إعادة التسمية مع تغييرات أخرى في نفس الـpull request. لو فعلت، يصبح مراجعة الـdiff صعبة جدّاً والمراجع يفقد القدرة على كشف الأخطاء. اِفصل دائماً: PR للتسمية، PR للمنطق، PR للأداء.

للمشاريع التي تتعامل مع API خارجيّة أو قاعدة بيانات، لا تغيّر التسمية في طبقة الاتّصال. JSON من خادم خارجيّ قد يكون snake_case بينما الكود الداخليّ camelCase. الحلّ هو طبقة تحويل (adapter) عند الحدود، تحافظ على الاتّفاقيّتين مفصولتين.

قاعدة البيانات: PostgreSQL و MySQL يقبلان أيّ تسمية، لكنّ الأعراف هي snake_case للأعمدة والجداول. لو غيّرت اسم عمود بعد الإنتاج، استخدم migration منفصلة مع إعادة تسمية حقيقيّة لا حذف وإنشاء (لتجنّب فقدان البيانات).

هل تتأثّر الحروف العربيّة بتحويل الحالة؟ لا، العربيّة ليست لها حالات (لا أحرف كبيرة وصغيرة). الأداة تتعامل مع الحروف العربيّة كما هي، وتحوّل الحالة فقط على الأحرف اللاتينيّة المُدرَجة في النصّ.

هل يحافظ التحويل على الأرقام والرموز؟ نعم، الأرقام (عربيّة وهنديّة)، علامات الترقيم، والرموز تبقى كما هي. التحويل يطبَّق فقط على الأحرف اللاتينيّة.

كيف تتعامل الأداة مع Unicode الموسَّع؟ الأداة تستخدم String.prototype.toLowerCase() و toUpperCase() القياسيّتَين في JavaScript، وهما يطبّقان قواعد Unicode الكاملة. هذا يعني أنّ أحرف اللغات الأخرى (تركيّة، ألمانيّة، يونانيّة) تُعامَل بشكل صحيح.

هل توجد حالة تركيّة خاصّة؟ نعم، التركيّة تميّز بين i و ı (دون نقطة). تحويل İSTANBUL إلى أحرف صغيرة في التركيّة يعطي i̇stanbul لا istanbul. لو كنت تعالج نصوصاً تركيّة، فعّل وضع «حسّاس للغة» في الأداة.

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

تصميم API جيّد يتطلّب اتّساقاً صارماً في التسمية. REST يعتمد على مسارات URL بصيغة kebab-case (/api/user-profiles/123/order-history)، لكنّ حقول الـJSON في الردّ تتبع اتّفاقيّة مختلفة حسب لغة الخادم. Node.js الشائع يستخدم camelCase (userProfile، orderHistory)، Python/Django يستخدم snake_case (user_profile، order_history)، Java/Spring يستخدم camelCase (userProfile).

عند بناء API لجمهور خارجيّ متعدّد اللغات، اِختر اتّفاقيّة واحدة ووثّقها في OpenAPI spec. الأكثر شيوعاً عالمياً هو camelCase لأنّ JavaScript هو لغة المستهلكين الأكثر شيوعاً. لو كان جمهورك الرئيسيّ Python أو Ruby، snake_case خيار شرعيّ. الأسوأ هو الخلط داخل نفس الـAPI.

GraphQL يفرض اتّفاقيّاته الخاصّة: أسماء الأنواع (types) بـPascalCase (User، OrderItem)، أسماء الحقول والوسائط بـcamelCase (firstName، orderId)، الـenums بـUPPER_SNAKE_CASE (USER_ROLE_ADMIN). هذا ليس مجرّد اصطلاح بل جزء من المواصفة، ومخالفته تُسبّب تحذيرات في معظم أدوات التحقّق.

للـwebhooks والأحداث، الاتّفاقيّة الأكثر انتشاراً هي dot.case هرمياً (user.created، order.payment.failed). هذا يجعل التصنيف والفلترة أسهل. Stripe وShopify وGitHub كلّها تتّبع هذا النمط.

في مستودعات الـmonorepo التي تحوي عشرات الحزم (packages) المرتبطة، الاتّساق في التسمية يصبح ضرورة وجوديّة. Nx، Turborepo، وLerna كلّها تشجّع تسمية الحزم بـkebab-case (@my-org/user-auth، @my-org/api-client). الاسم يصبح جزءاً من المسار في node_modules، ويظهر في package.json لكلّ مشروع يستخدم الحزمة.

التحدّي الشائع: حزمة اسمها user-auth تصدّر دالّة useAuth. الاسم يتحوّل بين كائن (الحزمة كملفّ) ومُعرّف (الدالّة في الكود). الأداة مفيدة هنا لتوليد كلا الاسمين من نفس الكلمات الأصليّة دون أخطاء يدويّة.

للمستودعات التي تستخدم code generation (مثل GraphQL Code Generator أو OpenAPI Generator)، تأكّد من إعدادات التحويل في ملفّ التكوين. graphql-codegen.yml يحدّد كيف تتحوّل أسماء الحقول من السكيما إلى أسماء TypeScript: عادةً تحويل تلقائيّ من camelCase في السكيما إلى PascalCase لأنواع الـTypeScript.

وثّق الاتّفاقيّات في ملفّ NAMING.md في جذر المستودع. يحوي: اتّفاقيّة أسماء الحزم، اتّفاقيّة أسماء الملفّات، اتّفاقيّة أسماء المتغيّرات والدوالّ، أمثلة لكلّ نوع، وقواعد الاستثناء (مثل أسماء العلامات التجاريّة). الفرق الجديدة تقرأ الوثيقة في يومها الأوّل، ويتشارك الجميع نفس الفهم.

متغيّرات البيئة (environment variables) لها اتّفاقيّة ثابتة عبر كلّ اللغات والأنظمة: UPPER_SNAKE_CASE بدون استثناء. DATABASE_URL، API_KEY، NODE_ENV، STRIPE_SECRET_KEY. هذا ليس تفضيلاً بل معيار POSIX التاريخيّ الذي تتبعه كلّ أنظمة Unix، الحاويات (Docker)، وأنظمة CI/CD.

لتنظيم عدد كبير من المتغيّرات، استخدم بادئة (prefix) تحدّد الخدمة: STRIPE_*، AWS_*، SENDGRID_*. هذا يجعل ملفّ .env أسهل قراءة، ويسمح بفلترة الأسرار حسب الخدمة في أنظمة إدارة الأسرار (secrets manager).

لتمييز البيئات (تطوير، تجريبة، إنتاج)، لا تستخدم بوادئ مثل DEV_API_KEY، STAGING_API_KEY. استخدم ملفّات .env منفصلة لكلّ بيئة (.env.development، .env.production) بأسماء متطابقة. هذا يحفظ الكود نظيفاً دون شروط if env === production منتشرة في كلّ مكان.

للأسرار الحسّاسة جدّاً، لا تستخدم ملفّات .env في الإنتاج. استخدم أنظمة مخصّصة مثل AWS Secrets Manager، HashiCorp Vault، أو Doppler. هذه الأنظمة تدعم تدوير المفاتيح الدوريّ (key rotation) وتسجّل كلّ عمليّة وصول، وهي متطلّبات «صلبة» في أيّ تدقيق أمنيّ.