ИМХО это зло, потому что если в конце названия переменных есть цифры, то это повод сделать массив из эти переменных.

например :

а почему не

?

mimik, наверно будет разница как вызывать ее 

или

обычно если

то и вызов этой функции будет примерно таким

тогда не проще ли так

?

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

проще так :




потому что это другое...


это и есть осмысленные имена..

еще пример это плейсхолдеры : _1, _2...
http://liveworkspace.org/code/cafb802b2063...e13a631e435079d


Это сообщение отредактировал(а) mes - 20.3.2011, 14:00

понятно что это проще, имелось в виду что a[0], a[1], a[2] ещё где-то используются

да это другое, но чем оно хуже?

a1, a2, a3 это осмысленные имена?   

я с C++ не так хорошо знаком
_1 это имя?
или это параметр по умолчанию?

  , также как и first,second, third
это особенность обобщенного программирования, когда неизвестно что именно скрывается за параметрами и известен лишь алгоритм обработки.. 

например 

как видно для make_pair абсолютно не важно чем являются A1, и А2.. главное что надо из них сделать структуру.. 


 , имя..


может и не хуже, но не подходит для той задачи

оно и видно, в с++ запрещена инициализация подобным образом


a[0], a[1], a[2] осмысленней?

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

Добавлено через 1 минуту и 28 секунд

полагается что с массивом осуществляется работа в цикле.. а следовательно "ручного" 
a[0], a[1], a[2] в таком случае не будет.. 

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

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

 

это смотря, что твориться внутри функции.
Разница в том, что в результате вычислений внутри функции void fun( int a[]) могут измениться данные  в массиве a..
в отличии от вызова функции void fun(int A[0],int A[1],int A[2] )

Это сообщение отредактировал(а) миг - 20.3.2011, 15:12

вот для наглядности, сами посмотрите что читабельней :


http://liveworkspace.org/code/2910ce13cff0...db0e784392b9f87

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


имхо, да

гораздо лучше чем



можно пример?




Добавлено через 2 минуты и 3 секунды

ну можно поставить const, или как там

(left, right),  (lhs, rhs) , (a1,a2), (first,second), (_1, _2) 
являются в данном случае абсолютно равно осмысленными и зависят от вкуса разботчика.
но при количестве аргументов три и более, цифры вытесняют своих конкурентов..


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


имеется ввиду корень слова без цифрового/буквенного аффикса..


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

Это сообщение отредактировал(а) mes - 20.3.2011, 15:30

А почему левый-правый, а не верхний-нижний?

имхо, не совсем

ну, левый операнд и правый операнд
в некоторых ЯП можно так


это в c++ так, в некоторых ЯП можно так


вот мне недавно надо было добавить новый функционал в чужой код, так так вместо массива используется ассоциативный ряд, код на 2000 строк и с фнукциями с 40 параметрами,
мне сказали что вначале были 3 переменные, потом добавили ещё 2, а потом ещё 35   , код надо было написать быстро  и некогда было вникать в функионал, поэтому они просто копипастили,
сейчас, с массивом, этот код занимает где-то 200 строк

Ну первый операнд, второй операнд  , 
Так отчего бы их и не пронумеровать?

если есть такая функция

и надо будет добавить параметр, то тут код заставляет подумать о рефакторинге

а если

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

Это сообщение отредактировал(а) mimik - 23.3.2011, 13:25

swap() с тремя параметрами?    

  к чему сказано то это ?!
имелось ввиду, что для человека легче для восприятия :

чем

где вперед заметили и легче выявили не стыковку ?


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


ну заставляет.. поняли что все таки нужно 4ре одинаковых параметра.. как их теперь называть ?

Добавлено @ 16:00

ну так речь же не о самом swape...

Добавлено @ 16:03
П.С. то что названия нужно изначально стараться подбирать наиболее эффективные и удобные, я не спорю..
я лишь говорю, что ситуации, когда именно цифровые аффиксы являются наиболее подходящими, не редки.. и не вижу ни одного повода не использовать их в таких случаях..

Добавлено через 11 минут и 31 секунду
кстати если бы я писал swap то с большой вероятностью назвал бы аргументы не (left, right),(lhs,rhs) - которые больше подходит для операторов, а (a,b) потому что на мой взгляд наиболее точно передают семантику и не добавляют лишнего мусора..
но a,b является по сути ничем не отличается от _1 _2.. последние бы не использовал (касается только (c++)), из за их "зарезервированного" смысла, как плейсхолдеры..






Это сообщение отредактировал(а) mes - 23.3.2011, 16:04

ну да


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


массив/структура будет занимать примерно столько же памяти сколько и параметры функции, не?


зависит, моно массивом, можно хэшмэп, можно классом

дело не в памяти, а в смысле, который вкладывается в решение.. 

имхо, если в коде используется ассоциативный ряд, это один из поводов для того отрефакторить код, заменить ряд на массив/хэш/структуру/класс

имхо, если в каком-то ЯП не принято/оптимально/возможно использовать какой-то подход, это не означает что подход плохой,
в Lisp например, всё есть список 
а в Java насколько я помню, функцию swap вообще написать не возможно, т.к. нельзя передать параметр по ссылке

Это уже простите не swap() а shift()  

А вообще мысль состоит в том, что иногда (не часто) функция принимает фиксированное количество параметров (потому неудобны массивы) которые семантически различаются только порядком в котором они переданы в функцию. Например sum(a1, a2), нет никакой разницы между первым и вторым аргументом. Потому я не вижу принципиальной разницы между: left/right, first/second, a1/a2.

нет

http://ru.wikipedia.org/wiki/Lisp

я это хотел сказать

тогда почему не сказал?

и таки не все.

123
123.4
123.4+5i
#\a
"abc"
x
|xyz|

и др.

это литерал   

скобки, запятая, плюс это всё выражения, ага, щас

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

• В ряде языков массив это объект и передается по ссылке, а переменные передаются по значению. Совсем разные вещи, не так ли?
• В ряде языков массив в формальных параметрах функции не может иметь заданного размера. Поэтому такой массив снижает императивность кода.
• Отведение памяти под массив обычно требует больше времени, чем под независимые переменные. Да и доступ к элементам массива обычно медленнее. Если имеются серьезные требования к быстродействию - массивы не лучшее решение.

Можно и дальше продолжать. ИМХО если цифры читабельности кода не снижают, недостатком они не являются. Впрочем, сам их использую очень редко.

конечно