سؤال

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

هل كانت مفيدة؟

المحلول

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

for(int i = 0; i < 10; i++)
{
    // i is well known here to be the index
    objectCollection[i].SomeProperty = someValue;
}

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

for(int currentRow = 0; currentRow < numRows; currentRow++)
{
    for(int currentCol = 0; currentCol < numCols; currentCol++)
    {
        someTable[currentRow][currentCol] = someValue;
    }
} 

نصائح أخرى

"أنا" وسائل "حلقة مضادة" للمبرمج.لا حرج في ذلك.

إليك مثال آخر لشيء لا بأس به تمامًا:

foreach (Product p in ProductList)
{
    // Do something with p
}

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

بالمناسبة، أعتقد أن اصطلاح التسمية لهذه جاء من لغة فورتران المبكرة حيث كنت أول متغير صحيح (A - H كانت عوامات)؟

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

أنا جيد، ولكن شيء من هذا القبيل ليس كذلك:

for (int i = 0; i < 10; i++)
{
    for (int j = 0; j < 10; j++)
    {
        string s = datarow[i][j].ToString(); // or worse
    }
}

من الشائع جدًا أن يقوم المبرمجون بتبديل حرفي i وj في التعليمات البرمجية عن غير قصد، خاصة إذا كان لديهم بصر ضعيف أو كان موضوع Windows الخاص بهم هو "hotdog".هذه دائمًا "رائحة الكود" بالنسبة لي - إنه أمر نادر نوعًا ما عندما لا يتم إفساد هذا الأمر.

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

ما هو غير مقبول على الإطلاق (وخطيئة في كتابي) هو استخدام i أو j أو k في أي سياق آخر غير فهرس عدد صحيح في حلقة....على سبيل المثال

foreach(Input i in inputs)
{
    Process(i);

}

أنا بالتأكيد مقبول.لست متأكدًا من نوع التبرير الذي أحتاج إلى تقديمه - ولكني أستخدمه طوال الوقت، كما يفعل المبرمجون الآخرون المحترمون جدًا.

التحقق الاجتماعي ، على ما أعتقد :)

نعم، إنه في الواقع مفضل لأن أي مبرمج يقرأ الكود الخاص بك سوف يفهم أنه مجرد مكرر.

ما هي قيمة استخدام i بدلاً من اسم متغير أكثر تحديدًا؟لتوفير ثانية واحدة أو 10 ثوانٍ أو ربما حتى 30 ثانية من التفكير والكتابة؟

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

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

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

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

أستخدم i للحلقات القصيرة.

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

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

لا أستخدم i إذا:

  • جسم الحلقة ليس صغيرًا، أو
  • يقوم المُكرِّر بأي شيء آخر غير التقدم (أو التراجع) من بداية النطاق إلى نهاية الحلقة:

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

إذا كان "الشيء الأكثر دلالة" هو "المكرر" فلا يوجد سبب لعدم استخدامه i؛إنها لغة مفهومة جيدًا.

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

foreach(DataRow dr in datatable.Rows)
{
    //do stuff to/with datarow dr here
}

على أي حال، فقط 0.02 دولار.

من المفيد أن تسميه شيئًا يصف ما يتم تكراره من خلاله.لكنني عادةً ما أستخدم i.

طالما أنك تستخدم i لحساب الحلقات، أو جزءًا من فهرس ينتقل من 0 (أو 1 اعتمادًا على PL) إلى n، فأنا بخير.

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

يجب أن أشير إلى أن i وj هما أيضًا تدوين رياضي لمؤشرات المصفوفة.وعادةً ما تقوم بالتكرار فوق مصفوفة.لذلك فمن المنطقي.

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

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

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

ومع ذلك، إذا كنت تقوم بتنفيذ حلقة تعسفية بعد ذلك i مقبولة.كما وصفها لي أحد زملاء العمل - i عبارة عن اصطلاح يعني "لا يتم تعديل هذا المتغير إلا بواسطة for بناء حلقة.إذا لم يكن هذا صحيحًا، فلا تستخدمه i"

يعود استخدام i وj وk لعدادات حلقة INTEGER إلى الأيام الأولى لـ FORTRAN.
أنا شخصياً ليس لدي مشكلة معهم طالما أنهم عدد صحيح.
ولكن بعد ذلك نشأت في فورتران!

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

سألت أ سؤال مماثل الأسبوع الماضي وما يلي هو جزء من إجابتي الخاصة:

// recommended style              ●    // "typical" single-letter style
                                  ●
for (ii=0; ii<10; ++ii) {         ●    for (i=0; i<10; ++i) {
    for (jj=0; jj<10; ++jj) {     ●        for (j=0; j<10; ++j) {
        mm[ii][jj] = ii * jj;     ●             m[i][j] = i * j;
    }                             ●        }
}                                 ●    }
في حالة عدم وضوح الفائدة على الفور:البحث في الكود عن أي حرف واحد سيجد أشياء كثيرة ليست كذلك عن ماذا تبحث.الرسالة i يحدث كثيرًا في التعليمات البرمجية حيث لا يكون هو المتغير الذي تبحث عنه.

لقد كنت أفعل ذلك بهذه الطريقة لمدة 10 سنوات على الأقل.

لاحظ أن الكثير من الأشخاص علقوا بأن أيًا من/كلا الأمرين أعلاه "قبيحان"...

سأذهب ضد التيار وأقول لا.

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

لاستخدام مثال من إجابة سابقة:

for(int i = 0; i < 10; i++)
{
    // i is well known here to be the index
    objectCollection[i].SomeProperty = someValue;
}

هل من الصعب جدًا استخدام اسم ذي معنى مثل هذا؟

for(int objectCollectionIndex = 0; objectCollectionIndex  < 10; objectCollectionIndex ++)
{
    objectCollection[objectCollectionIndex].SomeProperty = someValue;
}

تم منح اسم المتغير (المقترض) objectCollection بشكل سيء جدًا أيضًا.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top