Длинные имена переменных

[Александр Дмитриев]

У меня в школе все именовали переменные как попало и, как правило, очень кратко. На первом курсе в институте приучали писать длинные полные имена. Недавно один знакомый достаточно опытный программист сказал, что начиная с некоторого момента перестал писать длинные имена, потому что придумывать их долго и бессмысленно. Собственно, хотелось бы услышать мнения форумчан на этот счёт.

[Matew]

Александр Дмитриев, на сколько длинные? Более 15 ИМХО плохо читаются. Голосовал за "да".

[Александр Дмитриев]

Ну я имел в виду сам принцип - описывать ли переменные в их имени подробно или нет. Вот, например, сейчас пишу программу, в ней использую переменную prevCommonChars - 15 символов, но вроде не очень плохо. Читаемость, наверно, не очень зависит от длины имени, больше влияет разделимость слов, количество идущих подряд согласных и т. д. Скорее даже длинные имена лучше читаются, потому что больше походят на естественный язык и нашему мозгу удаётся быстрее реагировать на образы слов. Другое дело, что длинные имена набирать на клавиатуре дольше, но есть же всякие IntelliSence...

[Хакер]

У меня в школе все именовали переменные как попало и, как правило, очень кратко.

Есть такая шиза у школьных большинства преподавателей. Одна из, так сказать.

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

Его выбор.

Чтобы проголосовать нужно чётко определиться с понятием "длинное". Вот у меня в текущем проекте есть переменная ioRel2UDEP_FromEP_PTAtc. И в рамках этого проекта эту переменную сложно назвать переменной с очень длинным именем

[Viper]

Конечно надо давать длинные имена переменным, вернее даже не длинные, а понятные. Если нужен счетчик для цикла, то можно назвать его просто i, если нужно количество чего-то, то nCount или даже просто c, а если циклов или количеств чего-то несколько, то вот и пошли длинные имена, типа iRivet и iScrew или nRivetCount и nScrewCount.

[alibek]

Как-то использовал хеши в качестве имен переменных (CRC32). Было забавно, но не практично.

[Ramzes]

private ProcessAction m_action;
private string AppPath = "";
private FTPClient.FTPClient m_UpCatPictFTP;
private FTPClient.FTPClient m_UpCatDataFTP;
private string[] m_UpCatFilesOnFTP;
private FTPClient.FTPClient m_DownOrdFtpClient;
private FTPClient.FTPClient m_UpOrdProcFtpClient;
private string[] m_DownOrdOrdersOnFtp;
private FTPClient.FTPClient m_UpDataFTP;
думаю, что эти имна не длинные, голосовал за нет, потому, что если длинные читать трудно

[burik]

Смотря на каком уровне объявляется переменная и сколько переменных там доступно. Глобальные переменные имхо должны иметь достаточно внятные названия, отражающие содержание т.к. эти переменны будут доступны везде и при объявлении переменных более низких уровней легко запутаться.. Если это маленькая функция c тремя переменными, то сойдут и краткие (a,b,c,i,j,g), а если переменных хотя бы 10-15, то с переменными типа "a", "b", "c" и т. д. легко запутаться.
А вообще, если учесть что VB позволяет использовать до 255 знаков в имени переменной , то на мой взгляд длинные имена использовать крайне не желательно..

[Александр Дмитриев]

Хакер

Чтобы проголосовать нужно чётко определиться с понятием "длинное".

Александр Дмитриев, на сколько длинные?

Ну я имел в виду сам принцип - описывать ли переменные в их имени подробно или нет.

ioRel2UDEP_FromEP_PTAtc

Да уж Тут получается, и не кратко, и не подробно

burik

а если переменных хотя бы 10-15, то с переменными типа "a", "b", "c" и т. д. легко запутаться.

А может быть, если хорошо пользоваться принципами инкапсуляции и минимизации использования глобальных переменных, то таких случаев вообще не возникнет?

[Amed]

Недолюбливаю длинные. Предпочитаю сокращать, но так, чтобы из имени было понятно (пред)назначение:

intDefaultActivationFunctionType -> intDefActFcnType

[RayShade]

Я всегда пишу длинные имена функций и переменных - так легче читать и понимать код Учитывая что в современных IDE есть всякие code completion и тому подобные фичи, проблем это никаких не доставляет.

[BV]

Ну, если "длинные" -- это от 15 символов, то нет. А если просто больше чем, скажем, void *pNV;, то да, но это сильно зависит от ситуации. Итераторам гораздо разумнее давать короткие имена, как и переменным в каком-нибудь сложном алгоритме (сортировка массива, графический фильтр, отрисовка фрактала и т.д.) -- i, j, k, a, cnt, sum. А вот переменным класса, глобальным переменным и т.п. как раз наоборот, разумнее давать длинные имена, например, LPTSTR g_AppCachePath.

[Dashka]

В общем, да.

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

Хотя для локальных переменных или счетчиков циклов сойдут и короткие.

[HKEY_SUPER_MASHINE]

Проще дать понятное с первого взгляда имя, которое всё равно урежется компилятором. Во-первых, бегать в обьявление переменных как-то глупо. Попробуйте, например, понять, что doc1 - активный документ,или g2 - признак выхода из игры. Во-вторых, понятное имя позволяет быстро выявить ошибку и экономит время на отладке

[Александр Дмитриев]

private ProcessAction m_action;
private string AppPath = "";
private FTPClient.FTPClient m_UpCatPictFTP;
private FTPClient.FTPClient m_UpCatDataFTP;
private string[] m_UpCatFilesOnFTP;
private FTPClient.FTPClient m_DownOrdFtpClient;
private FTPClient.FTPClient m_UpOrdProcFtpClient;
private string[] m_DownOrdOrdersOnFtp;
private FTPClient.FTPClient m_UpDataFTP;

intDefaultActivationFunctionType -> intDefActFcnType

Это всё с моей точки зрения длинные имена, потому что под длинными я имел в виду хорошо описательные имена. Короткие - это вот: q, ip7, pNV. Причём венгерская нотация возможна в кратких именах.

Dashka, HKEY_SUPER_MASHINE
Всё равно достаточно понятно для эффективной отладки и/или чтения другими программистами переменную в имени не опишешь. Получается, что нужно либо писать короткие имена, либо как у Хакер'а в посте выше.

[Ramzes]

m_action
m_UpCatPictFTP
m_UpOrdProcFtpClient

это по твоему длинные?

[pronto]

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

Код: Выделить всё

Public Const LVM_SETEXTENDEDLISTVIEWSTYLE As Long = LVM_FIRST + 54
Public Const LVM_GETEXTENDEDLISTVIEWSTYLE As Long = LVM_FIRST + 55

А это уже целые предложения, а не имена

Код: Выделить всё

Public Const BSF_NOTIMEOUTIFNOTHUNG& = &H40
Public Const CACHE_S_FORMATETC_NOTSUPPORTED& = &H40170


[Ramzes]

pronto
не всегда впысываешься в 20 символов. А для того, чтобы переменные были более читабельными можно их разделять по регистру

например вместо
BSF_NOTIMEOUTIFNOTHUNG
можно написать
BSF_NoTimeOutIfNotHung

[Александр Дмитриев]

Ramzes
Ну разве что m_action короткое.

[Debugger]

Пропорционально с объемом проекта растут длины имен его переменных.
Имена больше 7-10 символов плохо смотрятся.
Префиксы и постфиксы (int, bln, lng) не люблю. Разве только 1й буквой (iCnt, bRun).
Примеры длинных имен - D3D_TYPE_OPTIMIZEDVERTEXBUFFER, DIKEYBOARD_APOSTROPHE, DI8DEVTYPEDEVICECTRL_COMMSSELECTION_HARDWIRED (гы, нашел в Object Browser'е. Надеюсь, она в реальности никогда не встретится)

[Хакер]

Ненавижу читать подобные имена

[syntax=vb]Public Const LVM_SETEXTENDEDLISTVIEWSTYLE As Long = LVM_FIRST + 54
Public Const LVM_GETEXTENDEDLISTVIEWSTYLE As Long = LVM_FIRST + 55[/syntax]

Дизреспект.


Кстати, с длиной переменной всё веселее в сях:
Если мы пытаемся включить в имя переменной ещё и её суть (например Dim hBitmap As Long), то у сишников (с их обычиями создавать синонимы базовым типам согласно назначению новых типов) достаточно написать HBITMAP b;


Из HBITMAP b всегда можно будет понять, что b таки содержит хендл битмапа. Если же написать Dim b As Long -- то просто так понять, а что же такое b не получится.

[pronto]

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

[HKEY_SUPER_MASHINE]

переменную в имени не опишешь

А что имеется в виду?

Префиксы и постфиксы (int, bln, lng) не люблю. Разве только 1й буквой (iCnt, bRun)

А мне наоборот, проще. На осознание того, что s - это String у меня уходит гораздо больше времени, чем на str. Тем более попробуйте разобраться - префикс b - это Byte или Boolean?

...(iCnt, bRun)

А это в сочетание с предыдущим высказыванием по поводу "b" - просто убой. Мне секунд десять потребовалось, чтобы понять суть переменных.

[Debugger]

HKEY_SUPER_MASHINE, на вкус и на цвет братьев нет.. Хакер'у тоже самое.
А зачем тебе разбираться, что такое b? А если без префикса? Если код писал ты, тебе все прозрачно. А если не ты - это другая история.

[Zenitchik]

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

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

Глубоко убежден, что локальные переменные "тупого назначения" - циклические, для промежуточного хранения чего-то там и т.п. - должны быть однобуквенные или однобуквенные с цифрами.
Если локальная переменная содержит что-то, имеющее смысл в самой модели - то Венгерская нотация.
Еще у меня есть набор устоявшихся однобуквенных имен: скажем, буквой q - я привык обозначать состояние КА, s - результат Split(), t - переменная для Line Input #file, t - ну и т.п.

О! Еще, когда работаем с физикой или метематикой - надо применять обозначения, принятые в самой науке.

[HKEY_SUPER_MASHINE]

А зачем тебе разбираться, что такое b? А если без префикса? Если код писал ты, тебе все прозрачно. А если не ты - это другая история.

Ага... Проблемы возникнут, когда выложишь код, и мне придётся в нём копаться. Две-три буквы написать не проблема, зато экономит порой ценное время.

[Zenitchik]

Если код писал ты, тебе все прозрачно.

Вот года через полтора как все прозрачно будет!..

ДЕЙСТВИТЕЛЬНО прозрачными могут быть только тривиальные алгоритмы, состоящие из пары-тройки строк, а то и вовсе из одной
(Max=iif(a<b,b,a)),
или классический алгоритмы - алгоритм Евклида, например.
В таких процедурах действительно предпочтительнее короткие (однобуквенные) имена, но только при условии смыслового имени самой функци и наличия коментария, что за алгоритм используется. Чтобы увидеть
'НОД по алгоритму Евклида
и больше о нем не думать.