[نقاش] استخدام تصميم(indent style) موّحد لشيفرة المشروع، أم ترك كل مبرمج بحرية؟

السلام عليكم ورحمة الله وبركاته،

بالطبع لا نتحدث عن تسمية الواجهة البرمجية الخارجية للمشروع أو عن نمط تصميم الشيفرة؛ مبرمج يسمي الوظائف getName وآخر get_name ستبدو الشيفرة كالمعكرونة كما في لغة PHP قبل أن يحاولواْ إصلاح الأمور، بالنسبة لشيفرة المشروع الأمر مفيد أن تتوحد طريقة الكتابة في كل المشروع، لكن إلى أي حد هو -حقًا- مهم؟! إن كنت ستكتب مشروعًا جديدًا هل تهتم بكتابة تصميم الشيفرة للمساهمين؟. كمطور ويب الأمر مزعج جدًا لي أن أغير طريقة كتابتي كلما أكتب في مشروع، إن كنت أكتب بهذه الطريقة:

var name = "chrome",
    version = 42;

setTimeout(() => {
    if (version > 40) {
        console.log(`name: ${name}`);
        console.log(`version: ${version}`);
    }
}, 1000);

إن أردتُ المشاركة في تطوير NodeJS يجب أن أغيرها إلى:

var name = 'chrome';
var version = 42;

setTimeout(function logAfterSecond() {
  if (version > 40) {
    console.log(`name: ${name}`);
    console.log(`version: ${version}`);
  }
}, 1000);

وهذا إلى JQuery!:

var name = "chrome",
    version = 42;

setTimeout( function() {
    if ( version > 40 ) {
        console.log("name:" + name);
        console.log("version:" + version);
    }
}, 1000 );

وكلما استخدمتُ مميزات أكثر ستختلف الشيفرة أكبر.

يرجى الدخول لحسابك أو تسجيل حساب لتستطيع إضافة تعليق
حساب جديد دخول

التعليقات

  • توحيد طريقة الكتابة أمر لابد منه في المشروعات ذات المُشاركة الجماعية، حتى على الصعيد الفردي ستكون لها فائدة على المدى البعيد.
يوسف سيد أضف ردا

وما هي اللفائدة غير أن "الـStyle" سيكون واحد؟!؛ لاحظ أننا نتحدث عن الشيفرة الداخلية للمشروع.

ahmedsaoud31 أضف ردا
  • توحيد التصميم يُساعد في فهم أسرع للأكواد ومُعالجتها والبناء بها ضمن نفس المشروع، التعود على تصميم وهيكلة واحده تُعطي إنتاجية عالية مع مرور الوقت للتعود على هذه الهيكلة.

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

يوسف سيد أضف ردا

التعود على تصميم وهيكلة واحده تُعطي إنتاجية عالية مع مرور الوقت للتعود على هذه الهيكلة.

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

عندما تقرأ برمجية وتجد كل جذء بها كُتب بنمط مُعين سيكون الأمر غاية في التشتيت ولكن توحيد النمط يجعل قراءة الكود أكثر فهماً وتنظيماً

هذا مفهوم نوعًا ما، رغم أنه ليس بذلك الأهمية التي نراها في دليل المساهمة للمشاريع، أو عندما يعلق أحدهم على الـPR الذي أرسلته كأنك ارتكبتَ جريمة!

ahmedsaoud31 أضف ردا
  • نعم ربما الأمر مربك في باديء الأمر ولكن أراه ضرورة للعمل الجماعي.

  • العين تميز أي اخلاف عن نمط مُعتاد وإن كانت إزاحة أو قوس في غير موضعه.

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

يوسف سيد أضف ردا

حسنًا هذا واضح ومفهوم، لكن عندما يأتي صاحب المشروع ويخترع أو يأتي بتصميم غير شائع في اللغة مثلًا تصميم شيفرة Jquery لا يطالبني بأن أستخدم تصميمه، لما لا يستخدمون JavaScript Standard Style ويرحمون المبرمج.

  • أصحاب المشروع في البداية هم لهم الحق في وضع قواعد المُشاركة فيه، فإن أردنا المُشاركة شاركنا بقواعدهم وإلا علينا أن نجد مشروع يناسبنا كما هو الحال في قواعد المُشاركة هنا على سبيل المثال.

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

Abdul0010 أضف ردا

كمبرمج يجب عليك اتباع code standards حتي ان جاء بعدك مبرمج اخر لاصلاح شي معين او تغييره لا يضيع في الكود او اذا رجعت لمشروع عملت عليه منذ سنين تعرف اين تبحث

مثلا ل php اتبع psr ولكن لا تستطيع ارغام كل مبرمج علي هذا ّ!

كمبرمج يجب عليك اتباع code standards حتي ان جاء بعدك مبرمج اخر لاصلاح شي معين او تغييره لا يضيع في الكود او اذا رجعت لمشروع عملت عليه منذ سنين تعرف اين تبحث

هذا نفهمه في التسميات، لكن ما شأن المساحة التي سأضيفها، أو الـTab الذي سأستخدمه بفهم الشيفرة لغيري؟!

مثلا ل php اتبع psr ولكن لا تستطيع ارغام كل مبرمج علي هذا ّ!

يارجل PHP نفسها لا تتبع تصميم معيّن :)

ههههه صحيح اصبت php لا تتبع اي تصميم معين ولكن كمبرمج بمكانك جعل الكود مثل المكرونه او تنظيمه واتباع SOLID Principles

ممايجعل الكود انظف و اسهل للفهم و الاصلاح من قبل الاخرين

sami-abdo أضف ردا

لكن إلى أي حد هو -حقًا- مهم؟!

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

إن كنت ستكتب مشروعًا جديدًا هل تهتم بكتابة تصميم الشيفرة للمساهمين؟.

نعم ، سأكتب قواعد عامة لذلك ، و سأحاول أن أجعل ألية لتأكيد أن الرموز البرمجية المضافة تتبع القواعد ، مثل إستخدام psr linter في php و eslint بالنسبة لـ JavaScript ، طبعاً مع المستودعات الخاصة بـ Git مع أدوات مثل Travic Ci أصبح الامر أكثر سهولة ^_^


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

  • و الغلب هذه الادوات إما على سطر الاوامر أو عبر محرر الرموز البرمجية

يوسف سيد أضف ردا

فقط كنت أتحدث عن بطء وصعوبة التغيير من طريقة كنت أستخدمها مثلًا JavaScript Standard Style إلى airbnb كمثال، وليس عن الطرق التلقائية في معرفتها سواءً قبل عمل Marge للـPR إلى المستودع، أو من المحرر عند المبرمج، في كلتا الحالتين سأحتاج إلى تصحيح مستمر أثناء الكتابة.

نعم الامر متعب قليلاً ، كمثال أنا أستخدم إضافة لمحرر atom بحيث يصحح بصورة تلقائية عند الحفظ لملف js كل المشاكل المتربطة بأسلوب الكتابة مثل :

  • الفراغات

  • إنهاء الجملة بـ فاصلة منقوطة

و هلم جره


أنت تستخدم golang صحيح ؟ و كما أذكر بصورة صحيحة أنهم لديهم طريقة لكتابة و ترتيب أسلوب الرموز المكتوبة باللغة أيضاً

يوسف سيد أضف ردا

التصحيح التلقائي لا يفلح في كل الأمور، بالنسبة لـGo أراحواْ الكل بعمل تصميم قياسي لا تستطيع الخروج عنه، يأتي مع مجمع اللغة أداة للتصحيح، وهنالك أخطاء تمنع التجميع مثلًا إن عرفت متغير ولم تستخدمه، إن اِستدعيت حزمة ولم تستخدمها، وأيضًا صانع التوثيقات الذي يأتي افتراضيًا يفرض بعض الأمور في كتابة حتى الـComments على الشيفرة كأن تبدأ باسم الدالة وهكذا، تكاد تجد كل الشيفرات المكتوبة بـGo بتصميم مطابق، أستخدم أكثر من خمس إضافات لـAtom لما يخص Go؛ البناء وتشغيل الـUnit Testing -التي للمناسبة افتراضية مع اللغة- ..

نعم صحيح لا يفلح في كل شئ ، ولكن يخفف عبئ الصيانة اليدوية لأمر مثل الفراغات مثلاً