Случатся ли со мной плохие вещи, если я назову свои массивы, коллекции, списки, перечислимые значения и т. Д. Только множественным числом того, что они содержат? - PullRequest
21 голосов
/ 01 сентября 2009

Я всегда думал, что это было "наилучшей практикой" - явно указывать в именах переменных моей коллекции. Итак, если бы у меня была коллекция объектов Car, я бы обычно назвал Car[] carArray и List<Car> carList.

А потом в 99% случаев я просто делаю что-то вроде ...

foreach (Car car in carArray)
{
    ...
}

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

И теперь, когда у нас есть IEnumberable<T>, я на самом деле сталкиваюсь с вопросом о том, могу ли я написать что-то вроде carIEnumerable? или carEnumerable. Пока что ответ был «нет».

Здесь я думаю, что тип коллекции часто не имеет значения, а когда это имеет значение, все равно не имеет значения, записан ли тип коллекции в имя переменной. У меня просто был случай, когда мне пришлось переключиться с IEnumerable<Car> на List<Car>, потому что мне нужен был «скобочный доступ» к предметам (например, carList[3]). В этом случае два типа коллекций не ведут себя одинаково, но будет ли проблема с именованием переменной cars здесь?

Чтобы не добавлять еще один уровень сложности к этому вопросу, что произойдет, если я использую var? Например.,

var cars = GetCars();

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

Итак, просто чтобы убедиться, что мой вопрос ясен: как вы называете переменные вашей коллекции и почему? Существуют ли серьезные трудности с читабельностью или ясностью для простого «множественного числа» названия предмета?

Ответы [ 12 ]

36 голосов
/ 01 сентября 2009
var car = cars.Where(c => c.Name == "Robin Reliant");

Читаемость выигрывает.

Следовательно я иду с множественным числом.

Доброжелательность,

Dan

20 голосов
/ 01 сентября 2009

Проблема с этим типом именования заключается в том, что он слишком сильно концентрируется на фактической реализации, а не на цели свойства. Вместо CarArray вы можете использовать OwnedCars, или что-то еще, что говорит пользователю, почему существует это перечисление.

Я думаю, что именование переменной цикла "car" в маленьком foreach цикле - это нормально.

Если вы напишите var cars = GetCars(), компилятор смотрит на тип в правой части присваивания, в данном случае, возможно, IEnumerable<Car>, и выдает cars этот тип. Вы даже можете увидеть это при последующем использовании переменной, если навести на нее курсор мыши.

Если вы меняете тип коллекции и вам не нужно менять код, потому что вы используете var, подумайте о том, что эти разные типы коллекций, вероятно, имеют что-то общее, что позволяет вам выполнять то же операции на них. Вероятно, это IEnumerable, если вы используете их в foreach циклах.

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

12 голосов
/ 01 сентября 2009

Предпочитаю автомобили carArray, но машины, вероятно, тоже не то, что вам нужно. Какие машины?

  • allCars
  • RedCars
  • brokenCars
  • carsWith3Axels

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

12 голосов
/ 01 сентября 2009

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

Я почти никогда не использовал бы carArray, скорее всего allCars, selectedCars или что-то подходящее.

12 голосов
/ 01 сентября 2009

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

  1. Меньше беспокоится о реализации конкретной коллекции
  2. Сделать код короче / более кратким, чтобы тип переменной был однозначным

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

12 голосов
/ 01 сентября 2009

Мне никогда не нравился подход «поместите тип переменной в его имя» - я действительно думаю, что он мешает гладкому чтению источника. Я считаю, что код должен читаться как история, и поэтому для меня совершенно логично называть группу машин (и мне все равно, будет ли она реализована в виде массива, связанного списка, кучи, набора или чего-то еще) "Тачки":

foreach (Car currentCar : ParkingLog.getCars()) {
    stolenCars.add(currentCar);    
}

fencer.cars = stolenCars;

У меня работает.

5 голосов
/ 01 сентября 2009

Я назвал свои переменные вещи, которые включают тип переменной, как часть обучения. Мне полезно видеть carArray где-то в коде как напоминание о том, что это массив. Но ваш вопрос поднимает очень обоснованный вопрос: если вы измените это позже, вам придется искать все эти ссылки, и это может стать большим кошмаром. Я вижу разумность именования переменных в соответствии с ответом Мэтью Вайнса «allCars», «brokenCars». Я думаю, что я буду делать это чаще, так как мое кодирование улучшается.

5 голосов
/ 01 сентября 2009

Вы, конечно, не должны добавлять имя типа как часть имени переменной - по большей части по той причине, которую вы упомянули. Лично, если бы у меня была коллекция объектов Car, я бы просто назвал коллекцию Cars - множественное число передает тот факт, что их больше, чем один, не раскрывая тип, который не нужен.

3 голосов
/ 01 сентября 2009

Помещение типа коллекции в имя переменной является проблемой, когда обслуживание приводит к необходимости изменения типа. Использование множественного числа или чего-то общего, например, «carColl», проще. Он понимает суть, не будучи тем, на что могло бы повлиять будущее изменение.

2 голосов
/ 01 сентября 2009

Я думаю, я мог бы просто называется массив автомобилей, и это не будет сделали любую разницу.

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

В Visual Studio я могу быстро найти тип данных. Поэтому я использую полные описательные имена. Множественное число в порядке. Если множественное число кажется неуклюжим, тогда я добавляю «Листинг» или все, что нужно, чтобы указать, что переменная содержит «коллекцию».

Например, carArray ничего не значит для меня. Является ли car аббревиатурой? Что если вы измените реализацию carArray на IList или IEnumerable объектов Car? Означает ли это, что вы меняете имя переменной или оставляете ее как есть? Слишком много, чтобы думать. Тем не менее, я бы понял Cars, CarListing, CarList, CarsByModel и так далее.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...