Не знаю, у меня есть для себя правило, что переменная в один символ имеет право на жизнь, если это счётчик цикла, или промежуточная переменная с использованием её от объявления не далее чем в пределах одного экрана, т.е. в пределах 20-25 строк кода. Никогда не считал это зазорным.
Счётчик-то можно, это конвенция. Но промежуточные я всегда называл tmp или tmp(название переменной).
Ещё один случай, с которым я встречался - это математический код. Математики постоянно называют переменные 1 буквой, так что приходится называть их так же и в коде, чтобы они не расходились с работой-первоисточником.
Как только таких переменных несколько, то это начинает напрягать. Никогда не понимал, почему не написать нормальное имя переменной? Экономия символов? Экономия времени? Экономия места на экране?
Как только нужда во временных переменных становится больше 3-5, естественно, они становятся в именовании длинее одного символа.
Но если мне нужны 2-3 временных переменных, всё назначение и время жизни которых, это сохранить на одно-два дальнейших присвоения промежуточное значение, чтобы упростить вычисление формул - я не парюсь. Главное, чтобы визуально весь блок кода, где они порождаются и используются - умещался на экране. Тогда никаких проблем с читаемостью кода нет.
Когда с математикой сложной работаешь постоянно, временные переменные нужны часто, и тогда именовать tmp_SumDispersion_n1 слишком много чести для них...
Как я ниже писал, (p.getValue() != t.getCount()) не самое приятное чтиво. Даже если в рамках одного экрана можно отследить откуда это идет.. И как по мне, это не имеет смысла в плане экономии чего бы то ни было..
Многие вещи, понятные и интуитивные в процессе написания кода, не на столько же понятны и интуитивны, при его чтении.. А особенно, если читает кто-то другой..
Ну, у вас это уже контейнер, или объект, для них совсем иные правила именования. Я сразу уточнил - промежуточные значения. В 99,99% - это скалярные типы данных. Когда математики много, многочлены цветут и пахнут буйным цветом, очень часто приходится часть предвычислять, для вставки потом в более сложную формулу. Тогда очень часто помогают n, k, p... для особо сложный формул могут быть и индексы. Или когда работаешь с пространственными преобразованиями, и нужны какие-то промежуточные x, y, z, h...
Тут нет особой экономии времени, это как дополнительный маркер, увидев такую переменную в коде, я уже знаю, что это объявлено в 3-5 строках выше данного места и умрёт не далее чем в стольких же строках ниже. И не имеет права быть передано по ссылке куда-то ещё и прочая.
Я ещё так делаю, если мне нужна временная переменная для отладки. Я её ещё могу назвать _ или __.
Потом я её либо удаляю, либо переименовываю нормально (если вдруг окажется, что она нужна постоянно).
Не, он там сначала SDM и GMR выпилил долбоящер криворукий, а когда понял что получилась хуйня, сделал бэкап, снес все к хуям и събался в отпуск на 40 дней, пока админы у себя в подвале закбывались фиксить хуйню с FreeBSD серверами. Потом вернулся, смонтировал бэкап в RRAT и сделал вид что так должно быть, великий архитектор, блять.
Лямбды.
Ну серьезно, кто-то называет очевидный параметр в лямбде, у которого скоуп даже не строки, а один-два оператора в лямбде, каким-то длинным именем?
Всегда использую "i" для первого цикла, "k" и "j" в следующих вложенных, потому что других однобуквенных переменных у меня никогда не бывает, а эти однобуквенные узнаются, как старые знакомые.
Хотя однажды увидел в коде "i", внутри "ii" и еще внутри "iii", и первым делом подумал "какой же придурок так обзывает переменные?", а потом вспомнил себя...
С i и j могут потом выросли траблы в некоторых языках если надо цикл включить в формулу и там i j вдруг становится мнимой единицей... так что я всегда использую ni для цикла и для последующего (вложенного) просто добавляется nii
недавно читал один проект на голанге. Там почти везде так. Я как-то постеснялся спросить автора(вроже ж взрослые люди). Вот вас спрошу, уважаемые пидоры. В голанге так принято или это как раз про этот случай комикс?
В голанге это чаще встречается, да. По разным причинам: кто-то то что на хип не падает называет времянкой и однобуквенно, есть стандартная конвенция рецивер метода по ссылке однобуквенно звать, ну и по примеру стдлибы всякие штуки типо респонс/реквест/врайтер/контекст чаще всего однобуквенно называются, но всегда просто одной и той же везде
Я помню времена, когда код программы мог занимать максимум 16КБ. Но такой большой бы не смог откомпилиться. Поэтому старались укладываться в 8Кб. Тогда односимвольные переменные были стандартом.
Модные гуру программирования пояснят тебе за нейминг, и за отсутствие комментариев для каждой строки, и про то что ты обсос потому что код должен быть самодокументируемым, и про архитектуру. Ещё расскажут про новейшие технологии/методы которые нужно внедрять немедленно, правда через несколько лет уже об этих методах и технологиях будут говорить что это моветон.
Только один хуй твой код говно и слепое следование чьим-то советам этого не исправить, смирись.
i, j, k для вложенных циклов это святое. В x, y и z для координат тоже ничего плохого не вижу. А вообще, сильно от контекста зависит: в функции, которая с первого взгляда понятно что делает, может быть очевидно, что h и w это, например, высота и ширина; а в некоторых функциях и с полными названиями переменных ничего не понятно.
Ещё один случай, с которым я встречался - это математический код. Математики постоянно называют переменные 1 буквой, так что приходится называть их так же и в коде, чтобы они не расходились с работой-первоисточником.
Но если мне нужны 2-3 временных переменных, всё назначение и время жизни которых, это сохранить на одно-два дальнейших присвоения промежуточное значение, чтобы упростить вычисление формул - я не парюсь. Главное, чтобы визуально весь блок кода, где они порождаются и используются - умещался на экране. Тогда никаких проблем с читаемостью кода нет.
Когда с математикой сложной работаешь постоянно, временные переменные нужны часто, и тогда именовать tmp_SumDispersion_n1 слишком много чести для них...
Многие вещи, понятные и интуитивные в процессе написания кода, не на столько же понятны и интуитивны, при его чтении.. А особенно, если читает кто-то другой..
Тут нет особой экономии времени, это как дополнительный маркер, увидев такую переменную в коде, я уже знаю, что это объявлено в 3-5 строках выше данного места и умрёт не далее чем в стольких же строках ниже. И не имеет права быть передано по ссылке куда-то ещё и прочая.
Потом я её либо удаляю, либо переименовываю нормально (если вдруг окажется, что она нужна постоянно).
val sumFunction: (Int, Int) => Int = _ + _
там было что то типа о 0 8 оо
Ну серьезно, кто-то называет очевидный параметр в лямбде, у которого скоуп даже не строки, а один-два оператора в лямбде, каким-то длинным именем?
Я бы вообще предпочёл читать типа
filter(_.val != _.count)
Хотя однажды увидел в коде "i", внутри "ii" и еще внутри "iii", и первым делом подумал "какой же придурок так обзывает переменные?", а потом вспомнил себя...
Как же у меня бомбит от этого догматизма.
Модные гуру программирования пояснят тебе за нейминг, и за отсутствие комментариев для каждой строки, и про то что ты обсос потому что код должен быть самодокументируемым, и про архитектуру. Ещё расскажут про новейшие технологии/методы которые нужно внедрять немедленно, правда через несколько лет уже об этих методах и технологиях будут говорить что это моветон.
Только один хуй твой код говно и слепое следование чьим-то советам этого не исправить, смирись.
Если же по какойто причине код оказался не говном, то это на неделю максимум - до первой правки от заказчика