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

• UPPERCASE: تحول كل الأحرف إلى كبيرة (HELLO WORLD).
• lowercase: تحول كل الأحرف إلى صغيرة (hello world).
• Title Case: تكبر الحرف الأول من كل كلمة (Hello World).
• Sentence case: تكبر الحرف الأول فقط من النص بأكمله (Hello world).
• camelCase: تجمع الكلمات بدون فاصل، مع تصغير أحرف الكلمة الأولى وتكبير الحرف الأول من الكلمات التالية (helloWorld).
• PascalCase: تشبه camelCase ولكنها تكبر الحرف الأول من الكلمة الأولى أيضاً (HelloWorld).
• snake_case: تجعل جميع الأحرف صغيرة وتجمع بين الكلمات بشرطة سفلية (hello_world).
• kebab-case: تجعل جميع الأحرف صغيرة وتجمع بين الكلمات بشرطة (hello-world).
• CONSTANT_CASE: تحول جميع الأحرف إلى كبيرة وتجمع بين الكلمات بشرطة سفلية (HELLO_WORLD).
• dot.case: تجعل جميع الأحرف صغيرة وتجمع بين الكلمات بنقاط (hello.world).
• Alternating case: تبدل بين الأحرف الكبيرة والصغيرة حرفاً بحرف (hElLo WoRlD).

تتضمن كل صيغة قاعدة للفصل وقاعدة لتكبير الأحرف، ويقوم محولنا بمعالجة جميع التجميعات الممكنة بين صيغ المدخلات والمخرجات.

تجمع كلا الصيغتين الكلمات بدون فاصل. والفرق بينهما يكمن في الحرف الأول — حيث تجعله صيغة camelCase صغيراً (myVariableName)، بينما تجعله صيغة PascalCase كبيراً (MyClassName).

العرف المتبع في اللغات الحديثة:

• تُستخدم camelCase للمتغيرات وأسماء الدوال وأسماء الأساليب (methods)؛
• تُستخدم PascalCase لأسماء الفئات (classes) وأسماء الأنواع (types) والواجهات (interfaces) والتعدادات (enums) ومكونات React/Vue/Svelte.

• مثال JavaScript: const userAccount = getCurrentUser() — هنا userAccount و getCurrentUser بصيغة camelCase؛ بينما class UserAccount {} — تكون UserAccount بصيغة PascalCase.
• لغة Java: int totalAmount و void calculateTotal() (أساليب وحقول بصيغة camelCase)، بينما class Calculator (فئات بصيغة PascalCase).
• لغة C#: أكثر تفصيلاً — الخصائص والأساليب العامة (public) تكون بصيغة PascalCase (مثل UserName و GetUserById)، بينما تستخدم الحقول الخاصة (private) صيغة camelCase (غالباً مع البادئة _).
• تتبع TypeScript قواعد JavaScript بالإضافة إلى استخدام PascalCase للأنواع والواجهات.
• يجب أن تكون مكونات React بصيغة PascalCase لتعمل بشكل صحيح — حيث تُعتبر أسماء الوسوم ذات الأحرف الصغيرة عناصر HTML عادية.

تُعد snake_case الصيغة الشائعة والسائدة في لغات البرمجة الديناميكية ولغات النصوص البرمجية (Scripting).

• قواعد PEP 8 في Python تفرض استخدام snake_case لأسماء الدوال والمتغيرات والأساليب والوحدات (modules) والحزم: مثل def calculate_total(user_id) و total_amount = 0 و import data_processor. وتكون الثوابت بصيغة CAPS_WITH_UNDERSCORES (مثل MAX_RETRY = 5)، بينما تكون الفئات بصيغة PascalCase (مثل class UserAccount).
• تستخدم لغة Ruby صيغة snake_case في كل مكان — للأساليب والمتغيرات وأسماء الملفات — مع كتابة الثوابت بصيغة PascalCase أو CONSTANT_CASE.
• SQL: التسمية القياسية للجداول والأعمدة هي snake_case (مثل user_accounts و created_at و last_login_date) — حيث تحافظ المعرفات المقتبسة على حالة الأحرف ولكنها قد تسبب مشاكل عبر قواعد البيانات المختلفة.
• JSON: تعيد واجهات برمجة التطبيقات المنشأة بواسطة Python و Ruby أسماء حقول بصيغة snake_case عادةً (مثل Stripe API و Twitter API و Django REST Framework).

عند التحويل بين الخلفية (Backend) بـ Python والواجهة الأمامية (Frontend) بـ JavaScript، اختر إحدى الصيغتين وقم بالتحويل عند حدود واجهة برمجة التطبيقات (مثل axios interceptor أو مولدات أسماء الأسماء المستعارة في Pydantic).

صيغة kebab-case مطلوبة في ثلاثة مواضع:

• (1) أسماء فئات CSS — مثل .primary-button و .nav-link-active. لا يمكن لمعرفات JavaScript أن تحتوي على شرطات، لذا تم اختيار الشرطات في CSS خصيصاً لتجنب أي التباس مع معرفات JavaScript.
• (2) معرفات الروابط (URL slugs) — مثل /blog/how-to-calculate-mortgage. توصي Google بوضوح باستخدام الشرطات بدلاً من الشرطات السفلية للفصل بين الكلمات: حيث تُعامل الشرطات كفواصل بين الكلمات، بينما تُعامل الشرطات السفلية كروابط اتصال، لذلك يتم أرشفة 'best-running-shoes' كـ ثلاث مصطلحات منفصلة بينما تُؤرشف 'best_running_shoes' كمصطلح واحد.
• (3) أسماء سِمات HTML — خاصة سِمات data-* وأسماء العناصر المخصصة في Web Components. تتطلب مواصفات Web Components أن تحتوي أسماء العناصر المخصصة على شرطة (مثل my-component وليس myComponent) لتمييزها عن عناصر HTML القياسية.

تستخدم الخصائص المخصصة في CSS (المتغيرات) أيضاً صيغة kebab-case: مثل --primary-color و --max-width. وعندما تقوم أطر عمل CSS-in-JS بتحويل أسماء الخصائص، فإنها تحول JavaScript بصيغة camelCase إلى CSS بصيغة kebab-case تلقائياً.

تشير صيغة CONSTANT_CASE (وتسمى أيضاً SCREAMING_SNAKE_CASE أو UPPER_SNAKE_CASE) إلى أن 'هذه القيمة لا تتغير أبداً' عبر جميع لغات البرمجة الرئيسية.

حالات الاستخدام:

• (1) الثوابت على مستوى اللغة — مثل const PI = 3.14159 في JavaScript، و public static final int MAX = 100 في Java، و ABSOLUTE_PATH = '/etc' في Python، و const MaxRetries = 5 في Go (رغم أن Go تستخدم غالباً MixedCase للثوابت المصدرة).
• (2) قيم التعداد (Enum) — مثل enum Status { PENDING, IN_PROGRESS, COMPLETED } في TypeScript، و public enum Status { PENDING, IN_PROGRESS } في Java، وأعضاء StrEnum في Python.
• (3) متغيرات البيئة — مثل DATABASE_URL و NODE_ENV و AWS_ACCESS_KEY_ID عبر جميع أنظمة التشغيل وأطر العمل.
• (4) ماكرو C/C++ — مثل #define BUFFER_SIZE 1024 و #define MAX_RETRY 5.
• (5) أقسام البيئة في ملفات Docker compose YAML، و ConfigMaps في Kubernetes، وأسرار GitHub Actions، ولوحات تحكم Vercel/Netlify.

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

تكبّر صيغة Title Case الحرف الأول من كل كلمة؛ بينما تكبّر صيغة Sentence case الحرف الأول فقط من العبارة بأكملها بالإضافة إلى أسماء الأعلام.

تختلف أدلة الأسلوب المختلفة في تحديد الكلمات التي يجب تكبير أحرفها في Title Case.

• دليل AP و APA: يتم تكبير الكلمات المكونة من 4 أحرف أو أكثر، ولا يتم تكبير حروف الجر القصيرة (in, on, at, of, by, to, for)، ولا أدوات التعريف والتنكير (a, an, the)، ولا حروف العطف (and, but, or, nor) — إلا إذا كانت هي الكلمة الأولى أو الأخيرة.
• دليل شيكاغو للأسلوب (Chicago): يتم تكبير جميع الكلمات باستثناء أدوات التعريف والتنكير، وحروف العطف، وحروف الجر بغض النظر عن طولها.
• نيويورك تايمز: تكبير الكلمات المكونة من 5 أحرف أو أكثر.

تفضل أدلة الأسلوب التقني الحديثة (Google, Apple, Microsoft Manual of Style) استخدام Sentence case لتسميات واجهة المستخدم، والنصوص الأساسية، وحتى العناوين — حيث تبدو أقل إزعاجاً وأكثر طبيعية في القراءة.

تظهر اختبارات تحسين محركات البحث (CoSchedule, Backlinko) أن العناوين بصيغة Title Case تحصل على نسبة أنقر أعلى (CTR) بنسبة 14-20% في نتائج البحث، لذا يفضل استخدام Title Case لعناوين المقالات بغض النظر عن نمط النص الذي تفضله.

لكل لغة قواعد تسمية محددة إما في دليل أسلوب رسمي أو عبر توافق مجتمع البرمجة.

• JavaScript/TypeScript: استخدام camelCase للمتغيرات والدوال، و PascalCase للفئات/الأنواع/المكونات، و CONSTANT_CASE للثوابت. وفقاً لأدلة أسلوب Airbnb و Google و Standard.
• Python: استخدام snake_case للمتغيرات/الدوال/الأساليب/الوحدات، و PascalCase للفئات، و CAPS_WITH_UNDERSCORES للثوابت. معتمد بواسطة قواعد PEP 8.
• Java: استخدام camelCase للمتغيرات/الأساليب، و PascalCase للفئات/الواجهات، و CAPS_WITH_UNDERSCORES للثوابت. وفقاً لـ Google Java Style Guide.
• Go: استخدام MixedCaps لكل من العناصر المصدرة (تبدأ بحرف كبير) وغير المصدرة (تبدأ بحرف صغير) — وفرض ذلك يتم عبر gofmt.
• Rust: استخدام snake_case للدوال/المتغيرات/الوحدات، و PascalCase للأنواع/السمات (traits)، و SCREAMING_SNAKE_CASE للثوابت. وفقاً لدليل أسلوب Rust الرسمي.
• C#: استخدام PascalCase لكل شيء عام (public) (الأساليب، الخصائص، الفئات)، و camelCase للمعاملات والحقول الخاصة (غالباً مع البادئة _).
• Ruby: استخدام snake_case في كل مكان، باستثناء الفئات/الوحدات (PascalCase) والثوابت (PascalCase أو CAPS_WITH_UNDERSCORES).

احرص دائماً على الالتزام باتفاقيات الكود المحيط بدلاً من فرض أسلوبك المفضل.

يجب أن تكون المعرّفات القابلة للقراءة في الروابط (URL slugs) بأحرف صغيرة ونمط kebab-case لأربعة أسباب.

• (1) فصل الكلمات في Google: تُعامل الشرطات الموصولة (-) كفواصل بين الكلمات في الروابط، بينما تُعامل الشرطات السفلية (_) كروابط بينها. يظهر الرابط /best-running-shoes في نتائج البحث لراغبي البحث عن 'best' و'running' و'shoes' بشكل مستقل؛ بينما يُعامل /best_running_shoes كمصطلح واحد مركب.
• (2) الحساسية لحالة الأحرف: قد تتعامل خوادم Apache وnginx وغيرها مع /About و/about كروابط مختلفة بشكل افتراضي — مما يعرضك لخطر عقوبة المحتوى المكرر. استخدم الأحرف الصغيرة دائمًا.
• (3) الموثوقية عند الكتابة اليدوية: تتسبب الأحرف الكبيرة في أخطاء إملائية؛ بينما يسهل مشاركة الروابط ذات الأحرف الصغيرة شفهيًا أو كتابتها مطبوعة.
• (4) التوافق مع المعايير: ينص RFC 3986 على أن المسارات حساسة لحالة الأحرف، ولكن العرف السائد عمليًا على الويب هو استخدام الأحرف الصغيرة.

أفضل الممارسات: إزالة الحركات والتشكيل (café ← cafe)، وتحويل الأحرف غير اللاتينية (non-ASCII)، وحذف أدوات التعريف (the/a/an) للاختصار، واستهداف معرّفات بطول 60-70 حرفًا للحصول على أفضل عرض SEO في صفحات نتائج البحث (SERPs).

تجنب: وضع التواريخ في المعرّفات (سجّل التواريخ في البيانات الوصفية للنشر)، ومعرّفات الجلسات (session IDs)، ومعلمات الاستعلام (query parameters) المدمجة في المعرّفات.

تُعد المختصرات الجزء الأكثر تعقيدًا في قواعد تسمية البرمجة نظرًا لوجود نهجين متنافسين.

• النهج (أ) (الحفاظ على حالة المختصرات): HTTPRequest وHTMLParser وUserID وJSONResponse وURLBuilder. استخدمت هذا النهج برمجيات C وC++ وJava القديمة في التسعينيات والألفينيات. وهو يسهل التعرف على المختصرات بلمحة سريعة.
• النهج (ب) (معاملتها ككلمات): HttpRequest وHtmlParser وUserId وJsonResponse وUrlBuilder. تفضل هذا النهج كل من Microsoft .NET ودليل Google للغة Java ولغات TypeScript وJavaScript الحديثة. وهو يجعل قراءة الأسماء التي تحتوي على عدة مختصرات أسهل، مثل HtmlHttpClient مقارنة بـ HTMLHTTPClient.

• قاعدة Microsoft: تظل المختصرات المكونة من حرفين بأحرف كبيرة (IOStream وIPAddress)، بينما تُكتب المختصرات المكونة من ثلاثة أحرف أو أكثر بنمط Pascal (مثل HtmlParser وليس HTMLParser).
• دليل Google لـ Java: تُعامل المختصرات دائمًا ككلمات (HtmlParser وليس HTMLParser، حتى للمختصرات المكونة من 3 أحرف مثل HTML).

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

تختلف قواعد حساسية حالة الأحرف باختلاف السياق.

• الروابط (URLs): حساسة لحالة الأحرف من الناحية التقنية (RFC 3986)، لكن معظم خوادم الويب تتعامل مع المسارات بدون حساسية لحالة الأحرف افتراضيًا — استخدم الأحرف الصغيرة دائمًا للأمان ودعم SEO.
• HTML: أسماء العلامات (tags) والسمات (attributes) غير حساسة لحالة الأحرف (DIV = div = Div)، لكن قيم السمات حساسة لحالة الأحرف (يجب أن تتطابق أسماء الفئات class ورُموز المعرّفات ID تمامًا عند الإشارة إليها من CSS/JS).
• JSON: حساس تمامًا لحالة الأحرف — يُعد {"userName": ...} و{"username": ...} حقلين مختلفين.
• SQL: يعتمد ذلك على قاعدة البيانات — نظام MySQL على Windows غير حساس لحالة الأحرف في أسماء الجداول، بينما MySQL على Linux حساس؛ يقوم PostgreSQL بتحويل المعرّفات غير المقتبسة إلى أحرف صغيرة ويحافظ على المقتبسة؛ نظام SQLite غير حساس لحالة الأحرف افتراضيًا.
• أنظمة الملفات: نظام Windows NTFS ونظام macOS APFS (الافتراضي) غير حساسين لحالة الأحرف مع الحفاظ على صياغتها؛ بينما نظام Linux ext4 ونظام macOS APFS (خيار حساسية الأحرف) حساسان لحالة الأحرف.

قد يتسبب استخدام Git على أنظمة ملفات غير حساسة لحالة الأحرف في مشاكل غير ظاهرة عندما يقوم المساهمون على أنظمة حساسة بسحب التغييرات. أفضل الممارسات: فرض نمط حالة واحد لكل نظام عبر قواعد الفحص (lint rules) أو إعدادات بيئة التطوير (IDE) أو تكوين git (core.ignorecase).

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

لإعادة التسمية الجماعية داخل ملف أو مشروع، استخدم الأداة الأكثر أمانًا المتاحة.

• إعادة تسمية عبر أدوات بيئة التطوير (IDE) (F2 في VS Code، وShift-F6 في JetBrains، وCmd-R-R في Xcode): الخيار الأكثر أمانًا — يُحدث جميع الإشارات بما في ذلك الاستيرادات (imports) والتعليقات (اختياريًا) والنصوص الديناميكية (في كثير من الأحيان).
• البحث والاستبدال على مستوى المشروع باستخدام التعابير النمطية (regex): أسرع ولكنه ينطوي على مخاطر — تحقق يدويًا من كل استبدال وقم بتشغيل الاختبارات بعد ذلك.
• سطر الأوامر: استخدام ripgrep مع --pcre2 بالإضافة إلى معالجة sed لإعادة التسمية المنهجية عبر العديد من الملفات.
• الأدوات القائمة على شجرة البنية النحوية (AST): مكتبة jscodeshift لـ JavaScript/TypeScript، وlibcst لـ Python، وOpenRewrite لـ Java — الخيار الأكثر أمانًا للتغييرات المعقدة التي تشمل آلاف الملفات مع فهم السياق الدلالي.

لتحويل استجابة JSON API كاملة من snake_case إلى camelCase، استخدم مكتبة تحويل عند حدود API (مثل camelCase-keys لـ Node، وhumps لـ JS، ومولدات الأسماء المستعارة في Pydantic لـ Python). لا تقم أبداً بإجراء إعادة تسمية جماعية على شجرة عمل غير نظيفة في git — أنشئ فرعًا، وأعد الهيكلة، واختبر، ثم ادمج التغييرات.

تفشل عمليات تحويل حالة الأحرف البسيطة في العديد من الحالات الخاصة.

• (1) المختصرات — تم شرحها أعلاه، وتتطلب اختيارًا صريحًا للنمط المتبع.
• (2) الأرقام في المعرّفات — هل ينبغي تحويل '2024Q4Revenue' إلى '2024_q4_revenue' أم '2024_q_4_revenue'؟ تقسم معظم أدوات التحويل الانتقالات بين الحروف والأرقام ولكن ليس الأرقام بالحروف؛ بينما يحافظ المحول الخاص بنا على مجموعات الأرقام.
• (3) تعيين حالة الأحرف في Unicode — يتحول حرف ß الألماني الصغير إلى 'ss' بالأحرف الصغيرة ولكن إلى ẞ (رسميًا عام 2017) أو 'SS' (النمط القديم) بالأحرف الكبيرة. ولحرف i التركي المنقوط/غير المنقوط قواعد خاصة باللغة. كما أن حرف سيجما اليوناني في نهاية الكلمة (ς) مقارنة بالوسط (σ) لا يحتفظ بشكله بعد عمليات التحويل المتبادلة.
• (4) أسماء العلامات التجارية التي تحتوي على أحرف كبيرة داخلية — مثل iPhone وeBay وYouTube — يجب الحفاظ عليها كما هي دون تحويل. أضف أسماء العلامات التجارية إلى قائمة استثناءات حالة الأحرف في المحرر لديك.
• (5) المختصرات اللفظية (Acronyms) مقابل المختصرات الحرفية (Initialisms) — تُعد NASA مختصرًا لفظيًا (يُنطق ككلمة)، بينما FBI مختصر حرفي (يُنطق كأحرف منفصلة) — تعاملها أدلة الأسلوب بطريقة مماثلة ولكنها تُقرأ بشكل مختلف.
• (6) النصوص مختلطة اللغات — لا يوجد سلوك محدد عند تحويل أحرف CJK (الصينية واليابانية والكورية) المختلطة مع الأحرف اللاتينية؛ وتمرر معظم الأدوات أحرف CJK كما هي بدون تغيير.

يتعامل المحول الخاص بنا مع معيار Unicode القياسي للنصوص اللاتينية والسيريلية ويقوم بتمرير أحرف CJK؛ أما بالنسبة للأنظمة متعددة اللغات المخصصة للإنتاج، فاستخدم المكتبات القائمة على ICU (مثل icu4j وPyICU) لعمليات تحويل حالة الأحرف المدركة للغة.