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

Я всегда считал, что это была "лучшая практика", чтобы быть явным в том, чтобы называть мои переменные коллекции. Итак, если бы у меня была коллекция объектов 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. Это кажется мне очень привлекательным, и у меня проблемы с большим недостатком.

Итак, чтобы убедиться, что мой вопрос ясен: как вы называете переменные коллекции и почему? Есть ли серьезная читаемость или ясность стоимости просто "плюрализации" имени элемента?

Ответ 1

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

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

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

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

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

Ответ 2

var car = cars.Where(c => c.Name == "Robin Reliant");

Побеждает читаемость.

Следовательно, я иду с плюрализацией.

Доброта,

Dan

Ответ 3

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

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

fencer.cars = stolenCars;

Работает для меня.

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

Предпочитайте автомобили carArray, но автомобили, вероятно, не то, что вы хотите. Какие автомобили?

allCars
redCars
brokenCars
carsWith3Axels

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

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

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

Ответ 11

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

Ответ 12

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