Вы используете переменные 1-3 букв EVERYWHERE?

Я заметил, что в С# я использую очень короткие имена переменных EVERYWHERE. Мой код загрязнен

foreach(var (v|f|i) in SOMETHING)

for(int (i|n|z)=0

var (ret|r) = blah();
...
return ret;

var sw = new StringWriter();

using(var r = cmd.ExecuteNonQuery()) {
    while(r.Read()) {
        r.GetSomething(3)

Я не знаю, плохо это или хорошо. Я, конечно, могу это прочитать. Я havent посмотрел на код 5 месяцев назад или старше, поэтому я не могу сказать, понимаю ли я старый код. Все мои функции короткие и делают одну вещь, поэтому, читая эту функцию, вы можете получить представление о переменной, особенно, поскольку theres <= 5vars в функции.

Люди используют, чтобы кричать на меня о том, чтобы не использовать хорошие имена переменных. Я не использую хорошие имена переменных или это нормально?

Ответы

Ответ 1

Напишите код для чтения людьми. Хорошее эмпирическое правило - чем больше область применения переменной, тем более описательным является ее имя. Функциональные параметры особенно должны иметь очень описательные имена, за исключением функций, где очевидно, что делает параметр, как в double sqrt(double n)

Однако, если это что-то обычно дает короткое имя и используется в небольшой области, то используйте короткое имя. Примеры:

//these are okay
var sb = new StringBuilder();
var sw = new StringWriter();
var cmd = new SqlCommand();
for(var i = 0; i< count; i++) {}

Ответ 2

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

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

Ответ 3

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

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

using (StreamReader sr = new StreamReader(inputStream))
{
    sr.ReadByte();
}

В отличие от:

using (StreamReader streamReader = new StreamReader(inputStream))
{
    streamReader.ReadByte();
}

Это действительно все о читаемости. Каждая ситуация отличается, а команды разработчиков - разные. Следуйте стандарту кодирования для проекта, если это существует. Если нет, следуйте стилю существующей базы кода, если это существует.

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

Примечание. Только потому, что использование переменной ограничено в своей области, необязательно означает, что бессмысленное имя в порядке. Если есть хорошее имя, которое представляет то, что делает объект, тогда оно должно использоваться. Если вы можете придумать имя переменной, которое отвечает "Why?", То это имя намного предпочтительнее.

Кроме того, разработчики могут хорошо понимать индексы i 'и' j 'для for. По соглашению, переменные счетчика циклов были названы таким образом со времен FORTRAN.

for (int i = 0; i < 10; i++)
{
    for (int j = 0; j < 10; j++)
    {
        PerformOperation(i,j);
    }
}

Ответ 4

Несколько лет назад я обнаружил, что произойдет, если я сделаю свои функции короткими:

  • Я мог понять их. Мой мозг маленький, а длинные функции не подходят.

  • Классы усложняются (множество функций). Но Extract Class создавал небольшие, сплоченные, одноцелевые классы. Опять же, маленький мозг, поэтому маленькие классы.

  • Число переменных в функции (или классе) невелико. Вспомните, что из времени объявления использовать время легко, потому что расстояние короткое.

  • Число областей в моих функциях невелико, поэтому мне не нужно определять, какие переменные идут туда.

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

Поскольку число переменных в области видимости невелико, и цель очевидна, мне редко приходится прикладывать все усилия для выбора описательного имени. Поскольку я не хочу напрягать свой маленький мозг больше, чем должен, я никогда не сокращаю. Мое имя по умолчанию для переменной - это имя типа. Например. class Foo переходит в переменную Foo. В моем коде, если что-то другое, вы знаете, что что-то особенное происходит, и вы должны обратить внимание.

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

Ответ 5

Это не просто вопрос с хорошими именами переменных (что является хорошей идеей), а скорее, если кто-то еще может понять, что вы написали, опираясь на комментарии, а также на имена переменных.

Конечно, для таких вещей, как счетчики или простые действия, имеют смысл короткие и сжатые имена. Для более сложных алгоритмов или чего-то, что немного труднее читать, вы хотите уточнить, насколько код ясно.

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

Ответ 6

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

Ответ 7

За небольшими исключениями нет - это не нормально. Там просто нет оправдания для одиночных букв или слишком сокращенных имен переменных. Даже если вы машинист-охотник и клюшка, intellisense означает, что вам почти никогда не нужно ничего писать. Если вы продолжаете называть переменные таким образом, вы наказываете обоих себя, любого, кому не хватало должного, чтобы было поручено поддерживать ваш код.

Ответ 8

Я считаю, что это плохой стиль кодирования? Ну, да.

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

Есть несколько исключений, где я думаю, что короткие имена переменных в порядке:

Индексы (в основном для циклов), например:

for (int i = 0; i < 10; i++)
{
}

Переменные, используемые в очень ограниченной области, такие как запросы Linq, лямбда-выражения или некоторые из уже упомянутых примеров, такие как Streamwriters и -readers и т.д., являются еще одним примером, когда я думаю, что короткие имена переменных прекрасны.

Кроме того, всегда возникает вопрос о том, насколько читабельным является ваш код. Причина, по которой я буду постоянно возиться с людьми, использующими короткие имена переменных, - это то, что для меня это показатель, который обычно не заботится о том, насколько читабельны их коды (особенно для других).

Ответ 9

Я понятия не имею, как вы можете отслеживать вещи, когда у вас есть имена переменных.

Как правило, гораздо лучше иметь более длинные имена, которые фактически описывают переменные. Вещь, к которой нужно стремиться, - это чтобы кто-нибудь мог прочитать код и понять, что происходит, чтобы понять, для чего они нужны и т.д. =)

Ответ 10

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

Ответ 11

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

О единственном времени, когда я использую короткие имена переменных, является либо короткое имя полностью описательным (т.е. x и y в ситуации, касающейся координат), либо функция полезности, которая работает с типом данных (т.е. первая буква этой строки. Это строка, что еще вы можете сказать об этом? Я назвал ее S.)

Ответ 12

Возможно, я не знаю, что в коде "r". Кроме того, имена переменных - это одно, но вы должны комментировать код для подробного объяснения. NB: Вероятно, это будет вики сообщества, так как нет определенного ответа.

Ответ 13

Это плохо. Это недостижимо.

Короткие переменные имеют свое место. На самом деле нет причин писать   for (int iterator; iterator

Эмпирическое правило: одна буква на экране досягаемости. С стандартным 24-строчным экраном.

Исключением является выбор одного-двух чрезвычайно часто используемых глобалов или полуглаблей, таких как указатель на хранилище данных или указатель входных данных, и сделать их длиной 1-3 буквы. Но все остальное - используйте разум. Короткие петли - одна буква. Местные функции - 3-5 букв. Переменные класса - полное слово. Названия классов библиотек/функций - два слова.

Ответ 14

Я не вижу причин использовать короткие имена переменных, которые ничего не говорят. Мы живем в 21 веке, у нас есть IDE с IntelliSense (или другим автозаполнением)! Просто нажмите Ctrl + Пробел, и он подскажет вам нормальное имя для вашей переменной в зависимости от типа переменной, например.

StringBuilder <Ctrl+Space> stringBuilder;
List<Person> <Ctrl+Space> persons;

Это еще проще, чем набрать что-то вроде sb или другое короткое имя. Нет причин использовать короткие имена.

P.S.: Единственное исключение для меня - это счетчики, такие как i, j, k для цикла.

Ответ 15

Я предпочитаю короткие "загадочные" переменные (Символы, в Mathematica) в сочетании с описательными комментариями.

Mathematica уже имеет VeryLongFunctionNames для встроенных команд, и добавление моего собственного часто распространяется на код больше, чем мне нужно.

Мне легче читать более короткий блок кода, где я вижу все сразу, а также ряд описаний символов.