Переменную называют мной недопустимый? [закрытый]

мое чувство состоит в том, что понятие использования одной буквы хорошо для "простых" циклов, однако, я учился использовать двойные буквы A давным-давно, и это работало отлично.

я спросил , подобным вопросом на прошлой неделе и следующее является часть мой собственный ответ :

// 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;
    }                             ●        }
}                                 ●    }

я делал его этот путь в течение по крайней мере 10 лет.

примечание, что много людей прокомментировало, что любое/и из вышеупомянутого "ужасно"...

Использование я, j, k для ЦЕЛОЧИСЛЕННЫХ счетчиков цикла возвращаюсь к первым годам ФОРТРАНА.
Лично у меня нет проблемы с ними, пока они - ЦЕЛОЧИСЛЕННЫЕ количества.
, Но затем я рос на ФОРТРАНЕ!

Это зависит. Если Вы выполняете итерации по некоторому определенному набору данных затем, я думаю, что имеет больше смысла использовать описательное имя. (например, filecounter как предложенный Dan).

Однако, если Вы выполняете произвольный цикл затем i, приемлемо. Как один коллега описал, это мне - i является конвенция, которая означает, что "эта переменная только когда-либо изменяется for конструкция цикла. Если это не верно, не используйте i"

Я должен указать, что я и j - также математическая нотация для матричных индексов. И обычно, Вы - цикличное выполнение по массиву. Таким образом, это имеет смысл.

Пока Вы используете его временно в простом цикле, и очевидно, что Вы делаете, уверенный. Тем не менее нет ли никакое другое короткое слово, которое можно использовать вместо этого?

i широко известен как итератор цикла, таким образом, Вы, на самом деле более вероятно, смутите программистов обслуживания при использовании его за пределами цикла, но если Вы используете что-то более описательное (как filecounter), он делает код более хорошим.

Помогает, называете ли Вы его чем-то, что описывает то, что это - цикличное выполнение через. Но я обычно просто использую i.

Если "что-то более семантическое" является "итератором" затем нет никакой причины не использовать i; это - хорошо понятая идиома.

я думаю, что я абсолютно приемлем в ситуациях для цикла. я всегда находил, что это довольно стандартно и никогда действительно столкнуто проблемы интерпретации, когда я используюсь в этом экземпляре. циклы foreach становятся немного более хитрыми, и я думаю, действительно зависит от Вашей ситуации. я крайне редко использую i в foreach, только в для циклов, поскольку я нахожу, что я являюсь слишком неописательным в этих случаях. для foreach я пытаюсь использовать сокращение циклично выполняемого типа объекта. например:

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

так или иначе, просто мои 0,02$.

Каково значение использования i вместо более определенного имени переменной? Сохранить 1 секунду или 10 секунд или возможно, возможно, даже 30 секунд размышления и ввода?

, Какова стоимость использования i? Возможно, ничто. Возможно, код так прост, что использование я в порядке. Но возможно, возможно, использование я буду вынуждать разработчиков, которые приходят к этому коду в будущем для размышления на мгновение, "что я имею в виду здесь?" Они должны будут думать: "действительно ли это - индекс, количество, смещение, флаг?" Они должны будут думать: "действительно ли это изменение безопасно, это корректно, я буду выключен 1?"

Используя i экономит время и интеллектуальное усилие, когда написание кода, но может закончить тем, что стоило более интеллектуального усилия в будущем или возможно даже привести к непреднамеренному введению дефектов из-за недоразумения кода.

Вообще говоря, большая часть разработки программного обеспечения является обслуживанием и расширением, таким образом, потраченное чтение количества времени Вашего кода значительно превысит потраченную запись количества времени его.

очень легко разработать привычку к использованию понятных имен везде, и после того как у Вас есть та привычка, требуется только несколько секунд больше для написания кода с понятными именами, но затем у Вас есть код, который легче прочитать, легче понять и более очевидно исправить.

Пока Вы или используете i для подсчета циклов или части индекса, который идет от 0 (или 1 в зависимости от МН) к n, затем я сказал бы, что в порядке.

Иначе его, вероятно, легкий назвать i что-то значимое это его больше, чем просто индекс.

я определенно приемлем. Не уверенный, какое выравнивание я должен сделать - но я действительно использую все это времени, и другие очень уважаемые программисты делают также.

Социальная проверка, я предполагаю :)

Да, на самом деле это предпочтено, так как любой программист, читающий Ваш код, поймет, что это - просто итератор.

я так распространен, что это приемлемо, даже для людей, которые любят описательные имена переменной.

то, Что абсолютно недопустимо (и грех в моей книге) использует i, j, или k в любом другом контексте, чем как целочисленный индекс в цикле...., например,

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

}

я в порядке, но что-то вроде этого не:

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

Очень характерный для программистов для непреднамеренного свопинга меня и j в коде, особенно если у них есть плохое зрение или их тема Windows, "хот-дог". Это всегда - "запах кода" для меня - довольно редко, когда это не становится завинченным.

i приемлемо, наверняка. Однако я изучил огромную сумму один семестр от учителя C++, которого я имел, кто отказался от кода, который не имел описательного имени для каждой переменной. Простое действие именования всего описательно вынудило меня думать тяжелее о своем коде, и я записал лучшие программы после того курса, не от изучения C++, а от обучения назвать все. Код, Завершенный , имеет некоторые хорошие слова по этой той же теме.

Я склонен использовать i, j, k для очень локализованных циклов (только существуют в течение короткого периода с точки зрения количества исходных строк). Для переменных, которые существуют по большей исходной области, я склонен использовать более подробные имена, таким образом, я вижу то, для чего они, не ища назад в коде.

Между прочим, я думаю, что соглашение о присвоении имен для них прибыло из раннего языка Фортрана, где я был первой целочисленной переменной (-H, были плавания)?

Вот другой пример чего-то, что это отлично хорошо:

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

средства "i" "счетчик цикла" программисту. Нет ничего неправильно с ним.

Я использую i для коротких циклов.

причина это в порядке, то, что я нахожу это совершенно неправдоподобным, что кто-то видел объявление типа итератора с инициализатором, и затем три строки позже утверждают, что не ясно, что представляет переменная. Они просто притворяются, потому что они решили, что "значимые имена переменной" должны означать "длинные имена переменной".

причина я на самом деле делаю это, то, что я нахожу, что использование чего-то несвязанного с определенной задачей под рукой, и что я только когда-либо использовал бы в небольшом объеме, сохраняет меня волнующийся, что я мог бы использовать имя, которое это вводит в заблуждение, или неоднозначное, или однажды будет полезно для чего-то еще в большем объеме. Причиной это - "i", а не "q" или "количество", является просто конвенция, одолженная от математики.

я не использую i если:

• тело цикла не является небольшим, или
• , итератор делает что-либо кроме усовершенствования (или отступление) от запуска диапазона к концу цикла:

я должен не обязательно войти в инкременты 1, пока инкремент последователен и ясен, и конечно мог бы остановиться до конца повторяющегося, но если он когда-нибудь изменяет направление или не изменяется повторением цикла (включая дьявольское использование iterator.insertAfter () во вперед цикле), я пытаюсь не забыть использовать что-то другое. Это сигнализирует, что "это не просто тривиальная переменная цикла, следовательно это не может быть тривиальным циклом".