هل هناك سبب وجيه لفرض الحد الأقصى للعرض وهو 80 حرفًا في ملف التعليمات البرمجية، في هذا اليوم وهذا العصر؟[مغلق]

https://stackoverflow.com/questions/110928

02-07-2019
|

سؤال

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

أنا لا أقول أنه لا ينبغي أن يكون هناك حد؛أنا فقط أقول، 80 حرفًا صغير جدًا.

المحلول

أعتقد أن ممارسة الاحتفاظ بالكود إلى 80 (أو 79) عمودًا تم إنشاؤها في الأصل لدعم الأشخاص في تحرير التعليمات البرمجية على محطات غبية مكونة من 80 عمودًا أو على المطبوعات المكونة من 80 عمودًا.لقد اختفت هذه المتطلبات في الغالب الآن، ولكن لا تزال هناك أسباب وجيهة للاحتفاظ بقاعدة الـ 80 عمودًا:

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

أعتقد أن النقطة الأخيرة هي الأهم.على الرغم من زيادة حجم شاشات العرض ودقتها في السنوات القليلة الماضية، عيون لم تفعل ذلك.

نصائح أخرى

أصل تنسيق النص المكون من 80 عمودًا أقدم من المحطات الطرفية المكونة من 80 عمودًا - يعود تاريخ بطاقة IBM المثقوبة إلى 1928!هذا يذكرنا ب (مشكوك بأمر) قصة مفادها أن مقياس السكك الحديدية الأمريكية تم تحديده من خلال عرض عجلات العربات في بريطانيا الرومانية.

أحيانًا أجده مقيدًا بعض الشيء، لكن من المنطقي أن يكون كذلك بعض الحد القياسي، لذلك 80 عمودًا.

وهنا نفس الموضوع الذي تناولته سلاش دوت.

وإليك بيان فورتران للمدرسة القديمة:

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

يجب عليك أن تفعل ذلك فقط من أجل كل من ليس لديه شاشة عريضة مقاس 22 بوصة.أنا شخصياً أعمل على شاشة مقاس 17 بوصة بنسبة عرض إلى ارتفاع 4:3، وأجدها واسعة بدرجة كافية.ومع ذلك، لدي أيضًا 3 من تلك الشاشات، لذلك لا يزال لدي الكثير من مساحة الشاشة القابلة للاستخدام.

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

طباعة خط أحادي المسافة بالأحجام الافتراضية هي (على ورق A4) 80 عمودًا في 66 سطرًا.

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

أنا أزعم أن ما يلي أكثر قابلية للقراءة مما كان يمكن أن يكون لو قمت بتقسيمه على عدة أسطر:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

تحديث: تم اقتراح في التعليقات أن هذه ستكون طريقة أكثر إيجازًا للقيام بما ورد أعلاه:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY;

على الرغم من أنه يناسب الآن 80 عمودًا، أعتقد أن وجهة نظري لا تزال قائمة وقد اخترت مثالًا سيئًا.لا يزال يوضح أن وضع عبارات متعددة على السطر يمكن أن يحسن إمكانية القراءة.

أستخدم ميزة الشاشات الأكبر حجمًا للحصول على أجزاء متعددة من التعليمات البرمجية بجوار بعضها البعض.

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

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

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

الشيء الوحيد الذي أفرضه على البقاء ضمن 80 حرفًا هو تعليقي.

شخصيًا...أكرس كل طاقتي العقلية (القليل منها) للبرمجة بشكل صحيح، إنه لأمر مؤلم أن أضطر إلى العودة وتقسيم كل شيء عند الحد الأقصى البالغ 80 حرفًا بينما يمكنني قضاء وقتي في الوظيفة التالية .نعم، أفترض أن Resharper يمكن أن يفعل ذلك من أجلي، ولكن بعد ذلك يخيفني قليلاً أن منتجًا تابعًا لجهة خارجية يتخذ قرارات بشأن تخطيط الكود الخاص بي ويغيره ("من فضلك لا تقسم الكود الخاص بي إلى سطرين HAL.هال؟").

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

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

لدي شاشتان مقاس 20 بوصة مقاس 1600 × 1200 وألتزم بـ 80 عمودًا لأنها تتيح لي عرض نوافذ متعددة لمحرر النصوص جنبًا إلى جنب.باستخدام الخط "6x13" (trad.xterm) 80 عمودًا تشغل 480 بكسل بالإضافة إلى حدود شريط التمرير والنافذة.وهذا يسمح لأحد أن يكون لديه ثلاث نوافذ من هذا النوع على شاشة 1600x1200.على نظام التشغيل Windows، لن يقوم خط Lucida Console بهذا الأمر تمامًا (الحد الأدنى للحجم القابل للاستخدام هو 7 بكسل عرضًا) ولكن الشاشة مقاس 1280 × 1024 ستعرض عمودين وشاشة مقاس 1920 × 1200 مثل اتش بي ال بي 2465 سيتم عرض 3.سيترك أيضًا مساحة صغيرة على الجانب للمستكشف المتنوع والخصائص والنوافذ الأخرى من Visual Studio.

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

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

لاحظ أنه يمكنك الحصول على إصدارات Windows من الخطوط "6x13". هنا.

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

هذا هو الوقت الذي يكون فيه الحصول على "أقصى عرض" مفيدًا.

أنت لست الشخص الوحيد الذي سيحافظ على الكود الخاص بك.

قد يكون لدى الشخص التالي شاشة مقاس 17 بوصة أو قد يحتاج إلى خطوط كبيرة لقراءة النص.يجب أن يكون الحد الأقصى في مكان ما وأن يكون 80 حرفًا هو التقليد نظرًا لقيود الشاشة السابقة.هل يمكنك التفكير في أي معيار جديد (120) ولماذا يعد استخدام هذا المعيار فكرة جيدة بخلاف "هذا ما يناسب شاشتي بخط Xpt؟"

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

لكن خذ الوقت الكافي للتفكير أولاً "هل هذا الرمز سيئ جدًا لدرجة أنه لا يمكن أن يعيش في حدود 80 حرفًا؟"

في معيار ترميز Linux، لا يحافظون على الحد الأقصى لعدد الأحرف وهو 80 حرفًا فحسب، بل يستخدمون أيضًا مسافة بادئة تبلغ 8 مسافات.

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

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

وأتساءل عما إذا كان هذا قد يسبب المزيد من المشاكل في هذا اليوم وهذا العصر.تذكر أنه في لغة C (وربما لغات أخرى) توجد قواعد تحدد المدة التي يمكن أن يصل إليها اسم الوظيفة.لذلك، غالبًا ما ترى أسماء يصعب فهمها في كود C.والشيء الجيد هو أنهم لا يستخدمون مساحة كبيرة.لكن في كل مرة أنظر فيها إلى تعليمات برمجية في بعض اللغات مثل C# أو Java، غالبًا ما تكون أسماء الطرق طويلة جدًا، مما يجعل من المستحيل تقريبًا الاحتفاظ بالكود الخاص بك بطول 80 حرفًا.لا أعتقد أن 80 حرفًا صالحة اليوم، إلا إذا كنت بحاجة إلى أن تكون قادرًا على طباعة الرمز، وما إلى ذلك.

كما قال الآخرون، أعتقد أنه الأفضل لـ (1) الطباعة و(2) عرض ملفات متعددة جنبًا إلى جنب عموديًا.

أحب أن أقتصر عرضي على 100 حرف أو نحو ذلك للسماح لمحرري SxS على شاشة عريضة.لا أعتقد أن هناك أي سبب وجيه للحد الأقصى البالغ 80 حرفًا بعد الآن.

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

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

استخدم الخطوط المتناسبة.

أنا جادة.يمكنني عادةً الحصول على ما يعادل 100-120 حرفًا في السطر دون التضحية بسهولة القراءة أو إمكانية الطباعة.في الواقع، من الأسهل القراءة باستخدام خط جيد (على سبيل المثال، Verdana) وتلوين تركيب الجملة.يبدو الأمر غريبًا بعض الشيء لبضعة أيام، لكنك تعتاد عليه بسرعة.

يقول الناس أن الأسطر الطويلة من التعليمات البرمجية تميل إلى أن تكون معقدة.فكر في فئة Java بسيطة:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

يبلغ طول هذا 94 حرفًا واسم الفئة قصير جدًا (وفقًا لمعايير GWT).سيكون من الصعب قراءتها في سطرين، كما أنها سهلة القراءة في سطر واحد.ولكوني عمليًا بشأن هذا الأمر وبالتالي السماح بـ "التوافق مع الإصدارات السابقة"، أود أن أقول إن 100 حرف هو العرض الصحيح.

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

سبب عدم البقاء في الثمانين هو أنني أفضل ذلك

تفضل الأسماء الأطول ذات المعنى للمعرفات
لا تهتم بـ typedefs للبنيات والتعدادات في C (فهي سيئة، فهي تخفي معلومات مفيدة!اسأل Peter van der Linden في "Deep C Secrets" إذا كنت لا تصدق ذلك)، لذا فإن الكود يحتوي على المزيد struct FOO func(struct BAR *aWhatever, ...) من رمز المتعصبين typedef.

وبموجب هذه القواعد، يتسبب 80 حرفًا/سطرًا فقط في التفاف الخطوط القبيحة أكثر مما تراه عيني مقبولًا (غالبًا في النماذج الأولية وتعريفات الوظائف).

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

أنا في المقام الأول مبرمج بايثون، لذلك ينتج عن ذلك مجموعتين من القيود:

لا تكتب سطورًا طويلة من التعليمات البرمجية
لا تضع مسافة بادئة أكثر من اللازم

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

من السهل في بايثون كتابة تعليمات برمجية موجزة نسبيًا (انظر codegolf) على حساب سهولة القراءة، ولكن من الأسهل كتابة تعليمات برمجية مطولة على حساب سهولة القراءة.الأساليب المساعدة ليست شيئًا سيئًا، ولا تعتبر الفئات المساعدة أمرًا سيئًا.يمكن أن يكون التجريد المفرط مشكلة، لكن هذا يمثل تحديًا آخر للبرمجة.

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

هناك بالفعل الكثير من الإجابات الجيدة على هذا، ولكن تجدر الإشارة إلى أنه في IDE الخاص بك قد يكون لديك قائمة بالملفات على اليسار، وقائمة من الوظائف على اليمين (أو أي تكوين آخر).

الكود الخاص بك هو مجرد جزء واحد من البيئة.

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

يتم تنفيذه في جيديت
_{(مصدر: jedit.org)} الذي يقدم التفاف الكلمات

و لكنها غاب بمرارة في الكسوف من وقت طويل !(منذ عام 2003 في الواقع)، ويرجع ذلك أساسا إلى أ التفاف الكلمات لمحرر النصوص يتضمن:

معلومات الخط الملتف مخصصة لعارض النص، والتنقل في التعليمات البرمجية، والمساطر الرأسية.
معلومات الخط غير المغلفة مطلوبة لوظائف مثل خط goto وعمود مسطرة ترقيم الأسطر وتمييز السطر الحالي وحفظ الملف.

أنا في الواقع أتبع قاعدة مماثلة للتعليمات البرمجية الخاصة بي ولكن فقط بسبب طباعة التعليمات البرمجية على صفحة A4 - 80 عمودًا هي العرض المناسب لحجم الخط المطلوب.

ولكن هذا هو التفضيل الشخصي وربما ليس ما كنت تبحث عنه (بما أنك تريد أن تسير الذخيرة في الاتجاه الآخر).

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

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

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

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

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

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

(قد يكون هذا قليلًا من الوقت الإضافي، ولكن في Eclipse يوجد خيار يقوم بتنسيق الكود عند حفظه (وفقًا لأي قواعد تريدها).قد يكون هذا أمرًا غريبًا بعض الشيء في البداية، ولكن بعد فترة تبدأ في قبول أن التنسيق لم يعد بين يديك كما هو الحال مع الكود الذي تم إنشاؤه.)

لو كان لدينا واحدة منها هؤلاء, ، لن نجري هذه المناقشة!؛-)

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

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

أما بالنسبة للطباعة، فعادةً ما أجد أن 100 سطر من الأحرف سيفي بالغرض جداً تناسب بشكل مريح على صفحة مطبوعة.

أحاول أن أبقي خطوطي أقل من 80 عمودًا.السبب الأقوى هو أنني غالبًا ما أجد نفسي أستخدمه grep و less لتصفح الكود الخاص بي عند العمل في سطر الأوامر.أنا حقًا لا أحب الطريقة التي تقوم بها المحطات الطرفية بكسر خطوط المصدر الطويلة (فهي بعد كل شيء ليست مخصصة لهذه المهمة).سبب آخر هو أنني أجد أنه يبدو أفضل إذا كان كل شيء يتناسب مع السطر ولم يكسره المحرر.على سبيل المثال، يتم محاذاة معلمات استدعاءات الوظائف الطويلة بشكل جيد أسفل بعضها البعض والأشياء المشابهة.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow