Стиль кода и правила именования идентификаторов

[zer_owlet]

"потому что не привили преподаватели нормальное именование переменных"
Скажи это EvilMax'у и Елене Осиповне как минимум.
Ну и Полякову тоже можешь.

1. С Савковой и Поляковым плотно общался все 5 лет учебы, вопрос по именованию переменных не возникало, хотя транслит и TForm1 были поголовно у всех.
2. Если на 5-м курсе человек все еще юзает TForm1 и Sortirovka, то преподаватели закрывали на это глаза весь курс обучения. Если подобное именование не нравится, Поляков просто не примет лабу или курсовой и студент к 5-у курсу или привыкнет нормально именовать или не дойдет туда.

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

Я в свое время принимал на работу порядка 6-7 студентов, так плевать на TForm1, пусть хоть код форматировать научатся.... это ж просто АААААА ((

Кстати, никто не вспомнил именование таблиц в виде t_customers, а ведь это тоже вызывает вопросы

[Волера]

Та какой t_customers, ето ещё хорошо)
Блощ напостой требовал именовать таблицы типа тСтуденты, тПреподаватели, тЕщёКакаятоХрень.
такой гемор был напостой переключать с англ на русский язык когда пишешь запрос.
(Отправлено в: Июнь 15, 2010, 09:07:16 )
 ага, типа хороший стиль воспитывали)

[Polyakov]

"потому что не привили преподаватели нормальное именование переменных"
Скажи это EvilMax'у и Елене Осиповне как минимум.
Ну и Полякову тоже можешь.

А как Вам прививать - розгами что ли?
У меня, например, в любом программном блоке вряд ли наберется больше 30 переменных. Поэтому мои любимые идентификаторы это:
i, j, n, m, k, i1, j1, n1, p_rec, p_kol, x, y - для целочисленных переменных
p_sum, p_vs, p_s1, p_***(где ***-имя поля) - для вещественных переменных
p_str, p_name, p_fio, p_kpd, p_***(где ***-имя поля) - для символьных переменных
ar, array, aget, an, am, a1, v1, s, s1, sum - для массивов
ob - для объекта
l_key - для кода нажатой клавиши
scr - для сожержимого экрана
col - для хранения цветовой палитры
vz - для возвращаемого значения
А больше мне и не надо - этих идентификаторов хватает для написания программного продукта любой сложности с объемом содержательного кода до 100 тысяч строк.
P.S.Для справки объем содержательного кода задачи "зарплата" менее 50 тысяч строк

[zer_owlet]

Polyakov, а можно вопрос? Вот хорошие у вас переменные, красивые. Но только кто в них, кроме вас, разберётся, если ему дать этот код?

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

Кстати, кудя тяженее работать с таким кодом: $salary_previous_quarter = $opening_balance_shop + $sum_sales + ..... При 10+ таких переменных читать код без мата невыносимо.

[Polyakov]

Polyakov, а можно вопрос? Вот хорошие у вас переменные, красивые. Но только кто в них, кроме вас, разберётся, если ему дать этот код?

А что специалисты или те кто себя таковыми считают уже не в состоянии понять содержимое и назначение переменной по контексту программы?

Или называть переменные надо как индейцам:

Например, "это_та_переменная_которая_будет_использоваться_как_параметр_для_внешних_циклов_с_параметром_и_при_необходимости_как_счетчик_итераций_для_циклов_пред_и_пост_условиями_и_т_п",

но вместо всего этого я вначале программного блока в разделе описания переменных просто пишу "i=0"

[Polyakov]

как нормально и AbstractDataMatrix, InMemoryDataMatrix, PagedDataMatrix, DataMatrixColumnPropertyDescriptor.

Если честно, то такие имена для меня - не нормально. При использовании в коде таких имен - зарплату такому программисту нужно урезать минимум вдвое, а то и втрое, так как он очень много времени будет тратить только на написание названий этих идентификаторов. И чем больше у него таких идентификаторов, тем ниже его зарплата. И если бы я выступал для тех кто использует такие идентификаторы как работодатель, то поверьте я бы не стал платить за то лишнее время, которое уходит на написание таких длинных имен переменных. Кроме того это увеличивает не только исходный текст программы, а и компилируемый модуль, и выполняемый модуль.
Ну конечно, ну чего мы будем мелочиться и считать какие-то байты программы, при современных та объемах оперативной памяти. Но только лишние байты имеют свойства превращаться в лишние килобайты, а лишние килобайты - в мегабайты и т.д. по цепочке. А потом мы слышим, что причина того что программа не работает как надо - слабая техника. Хотя в большинстве случаев все наоборот.

P.S. Хотя мы в нашей дискуссии отвлеклись от темы.
(Отправлено в: Июнь 16, 2010, 11:17:48 )
 

Polyakov, утрируете

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

[Волера]

Polyakov,

У тех, кто пользует нормальную IDE, таких проблем просто нет.

В большинстве хороших IDE реализован механизм автодополнения (IntelliSence), при котором что на переменную i, что на DataMatrixColumnPropertyDescriptor тратится одинаковое кол-во времени - 1 сек.

Ну конечно, если писать код в блокноте - тогда да..

[Alder]

А что специалисты или те кто себя таковыми считают уже не в состоянии понять содержимое и назначение переменной по контексту программы?

При больших объемах кода понять назначение переменной описанной в начале, а используемой где-то в середине громадного цикла с кучей ветвлений, довольно затруднительно.

он очень много времени будет тратить только на написание названий этих идентификаторов

Нормальные IDE имеют расширенные средства подстановки имени переменной при написании кода. И расширенные средства рефакторинга кода.

[Polyakov]

В большинстве хороших IDE реализован механизм автодополнения (IntelliSence), при котором что на переменную i, что на DataMatrixColumnPropertyDescriptor тратится одинаковое кол-во времени - 1 сек.

Чем больше у Вас переменных начинающихся на букву "D" тем больше вариантов выбора в вспывающем окне подстановки и Вам придется либо выбрать с помощью нажания клавиши "Стрелка вниз" и "Enter" нужную альтернативу или набирать следующую букву сокращая таким образом список альтернатив.
"Делали - знаем"
Так, что не надо хоть мне рассказывать эту чушь о равных временных затратах.
Если хотите приходите - сделаем хронометраж.
(Отправлено в: Июнь 16, 2010, 11:40:28 )
 

При больших объемах кода понять назначение переменной описанной в начале, а используемой где-то в середине громадного цикла с кучей ветвлений, довольно затруднительно.

У каждого разное понятие слова "громадный". А вообще разбивать программу на функции учат, если я не ошибаюсь, уже на 4-ой лабораторной 1-го сесместра.

[Polyakov]

И расширенные средства рефакторинга кода.

Только не надо здесь выражаться.

[naxellar]

Polyakov, время тратися больше, но шансов запутаться меньше. Особенно, если посмотреть код через некоторое время. Так что, не факт, что таккая экономия времени действительно его экономит.

[EvilMax]

Если хотите приходите - сделаем хронометраж.

Только если так, давайте хронометраж просуммируем с временем разбора достаточно сложного кода программистом, его не писавшим, в случаях с информативными идентификаторами и идентификаторами an, am, a1, p_* (кстати, о * - а имена полей какие? если длинные - чем хуже полное имя, если нет - тогда очень интересно, сколько новый человек будет разбираться с кодом и привыкать к нему)

(Отправлено в: Июнь 16, 2010, 11:49:41 )
 

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

Это не моя цитата ))) Но я согласен.

[Alder]

Только не надо здесь выражаться.

Александр Иванович, если вы за 19 лет своего опыта разработчика не разу не сталкивались с понятием рефакторинга (переведу - улучшения, переработки) кода, то мне искренне жаль ваши 17летние программы. Dixi.

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

[Polyakov]

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

В своей программе никогда не запутаешься.

Если наши преподаватели будут из-за имен не принимать лабораторные

У меня такого никогда не было. Хотя я если очень длиннные идентификаторы - обращаю внимание студента на это.

[TapTap]

Вот уже 19 лет как я пишу программы для различных предприятий и некоторые из них уже 17 лет как работают. Операционные системы, компьютера меняются, а они все работают. Может быть в них все-таки что-то есть?

Может быть, они морально уже устарели?

По поводу названия переменных: работая с одним большим проектом, вначале тоже называла переменные сокращенно, чтобы "минимизировать код", но впоследствии пришла к тому, что не все переменные можно сократить. И сокращенные переменные, такие как c_t, n_b, n_b1, nb2 и проч., только усложняют программу. Потому что через время больше времени тратится на то, чтобы вспомнить и разобораться что именно подразумевает эта переменная, чем на написание кода.

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

[Polyakov]

Александр Иванович, если вы за 19 лет своего опыта разработчика не разу не сталкивались с понятием рефакторинга (переведу - улучшения, переработки) кода, то мне искренне жаль ваши 17летние программы.

Мальчик. Я к твоему сведению постоянно перерабатываю и улучшаю свои программы, а ты, кроме якобы умных слов, ни хрена на знаешь и не умеешь.
Я тебе недавно на одной из веток этого форума предлагал сделать программу и доказать кто есть "who". Причем не просто так сделать, а за приличные деньги. Но ты почему-то не согласился. Так что хватит здесь выпендриваться.
К твоему сведению у меня выполняемый модуль программы "Зарплата" сейчас занимает 1 017 856 байт и я не один раз бывал счастлив, когда в результате очередной глобальной переработки мне удавалось снизить его объем на 100-150 килобайт.

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

[TapTap]

В своей программе никогда не запутаешься.

Досадное заблуждение.
Если программа невелика (размера лабораторной или даже курсовой),  то вполне возможно удержать в голове все переменные.
Но если это большой совместный проект, то я бы всё-таки советовала называть переменные понятным языком. В этом случае высвобождается ОЗУ мозга человека от переменных для написания продуктивного кода 

[Волера]

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

[mars]

Досадное заблуждение.

У Александра Ивановича очень хорошая память. Думаю все, кто пытался сдать ему курсовую, которую он уже видел, в этом убедились ))))))))

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

[tos]

"Кроме того это увеличивает не только исходный текст программы, а и компилируемый модуль, и выполняемый модуль. "
да ладно!
ну, время компиляции может чуток учеличится из-за большего объёма.
Провёл тест.
Компилятор min-GW(другого нет).

Код:

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);


	int SUPER_DLINNOE_NAZVANIE_CHTOB_UBEDITSA_CHTO_ETO_NE_VAZHNO=0;

	while (SUPER_DLINNOE_NAZVANIE_CHTOB_UBEDITSA_CHTO_ETO_NE_VAZHNO)
	{
		int SUPER_DLINNOE_NAZVANIE_CHTOB_UBEDITSA_CHTO_ETO_NE_VAZHNO_SUPER_DLINNOE_NAZVANIE_CHTOB_UBEDITSA_CHTO_ETO_NE_VAZHNO;
		SUPER_DLINNOE_NAZVANIE_CHTOB_UBEDITSA_CHTO_ETO_NE_VAZHNO_SUPER_DLINNOE_NAZVANIE_CHTOB_UBEDITSA_CHTO_ETO_NE_VAZHNO--;
		SUPER_DLINNOE_NAZVANIE_CHTOB_UBEDITSA_CHTO_ETO_NE_VAZHNO_SUPER_DLINNOE_NAZVANIE_CHTOB_UBEDITSA_CHTO_ETO_NE_VAZHNO++;
		break;
	}

    return a.exec();
}

И короткий вариант

Код:

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);


	int i=0;

	while (i)
	{
		int j;
		j--;
		j++;
		break;
	}

    return a.exec();
}

итак, билдим Release.

Размеры -56,832 и (ВНИМАНИЕ!) 56,832

(Отправлено в: Июнь 17, 2010, 10:04:25 )
 "А вообще рефакторинг - это то что заботящийся о своем программном детище человек делает постоянно."
не могу не согласиться. +1

[Polyakov]

Размеры -56,832 и (ВНИМАНИЕ!) 56,832

Да !?  Распределение и выделение памяти Вам еще учить и учить!

[tos]

А причём тут выделение памяти к длине имени переменной?
Ну расскажите, что ли

[Polyakov]

А причём тут выделение памяти к длине имени переменной?
Ну расскажите, что ли

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

[tos]

мда.

[Kenny]

А причём тут выделение памяти к длине имени переменной?
Ну расскажите, что ли

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

А я думал вся суть преводавателя в том, чтобы делится с остальными.

[naxellar]

Polyakov, у вас ЧСВ зашкаливает явно.

[Kenny]

Polyakov, у вас ЧСВ зашкаливает явно.

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

[srs]

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

потому, что вы преподаватель.

[transformator]

Polyakov, у вас ЧСВ зашкаливает явно

хоть с этим я совершенно согласен, имхо, поскромнее вести себя надо, но с этим

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

я тоже не могу не согласится.

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

[zer_owlet]

А причём тут выделение памяти к длине имени переменной?
Ну расскажите, что ли

Не знаю что там про выделение памяти, но в свое время видел результаты тестов (не могу найти ту страницу, к сожалению) для PHP и при увеличении длинны имени переменной, время выполнения скрипта увеличивалось. Так что, называть переменную $this_is_the_array_of_products_attributes автор статьи не советовал.
(Отправлено в: Июнь 17, 2010, 01:16:49 )
 

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

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

[tos]

"для PHP и при увеличении длинны имени переменной, время выполнения скрипта увеличивалось."
Привет, КЭП!
И лишние пробелы и отсутпы и прочая фигня в HTML, CSS и JavaScript тоже зло.
Но мы-то про КОМПИЛИРУЕМЫЕ ЯП, в частности, про всеми любимый С/С++.
Да хоть и про ASM, там та же песня.
Для программиста имени переменной ставиться в соответствие адрес.
При компиляции имя опускается.
Про Java и C# без обфускации промолчим - там остается метаинформация класса.
Но, подозреваю что на скорость это не повлияет.

[zer_owlet]

"для PHP и при увеличении длинны имени переменной, время выполнения скрипта увеличивалось."
Привет, КЭП!

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

И лишние пробелы и отсутпы и прочая фигня в HTML, CSS и JavaScript тоже зло.

не такое уж и зло, но со знатоками спорить ну буду ))

[tos]

"не такое уж и зло,"
да я лишь о том, что немного падает скорость разбора документа, а насчёт того что так удобнее и яснее - это очень даже добро.

[zer_owlet]

"не такое уж и зло,"
да я лишь о том, что немного падает скорость разбора документа, а насчёт того что так удобнее и яснее - это очень даже добро.

Чешутся руки вернуть "Привет, КЭП!", но не буду )) Пробелы, комменты и всякое такое влияет на размер документа, т.е. юзер его будет дольше скачивать. Но это, конечно же, все знают ))

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

[Katushka]

Александр Иванович, если вы за 19 лет своего опыта разработчика не разу не сталкивались с понятием рефакторинга (переведу - улучшения, переработки) кода, то мне искренне жаль ваши 17летние программы.

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

Куда смотрят модераторы? Тут пошли завуалированные и не очень оскорбления.
Я считаю, что каждый сам решает, как называть переменные. И даже 20-летний опыт разработчика не дает человеку права таким образом унижать молодых.
Преподаватель может в виде рекомендаций указать на то, что переменные по ЕГО мнению названы некорректно, но не таким образом, как сейчас идет неприятная дискуссия.

Забросайте меня помидорами

[tuft]

Katushka, да ладно, тут все привыкли к манере общения Polyakov'а =)
Никто всерьёз не воспринимает 

[srs]

забаньте старого пердуна

[Alder]

Katushka, ой, а я ответ пропусти этот Спасибо, увидел.

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

А это уже не вам решать. И вам (ну вот лично вам) я доказывать ничего не собираюсь. У меня вполне хватает интересных проектов (за деньги, ага) и без ваших предложений. Но, впрочем, я опять повторяю свой ответ двумесячной давности. Я могу бы тыкнуть вас в незнание основ С++, которое вы продемонстрировали на этом форуме в одной из тем, но не буду. Кто следил - тот помнит о чем речь.

Теперь дополню немного Тоса. Компилятор в процессе компиляции переводит исходный код в исполняемый (открываю Америку, всем внимание!) Исполняемый код есть скомпилированный ассемблер. В котором никаких имён переменных нет! Для ассемблера ваша переменная всего лишь адрес памяти. Адрес есть 8-16-32-64-битное число, на которое длина имени переменной повлиять ну никак не может. Т.е. понятные имена переменных программист даёт для собственного удобства и они никоим образом не влияют на распределение памяти, объем исполняемого модуля и скорость работы программы. Это справедливо для всех компилируемых языков.
Для скриптовых языков (php, perl, python etc) ситуация другая. Здесь длина имени переменной может влиять на скорость работы транслятора. Поэтому и рекомендуют следовать золотой середине - использовать понятные идентификаторы, но при этом следить за их длиной. Зер_овлет не даст соврать - в крупных веб-системах, состоящих из сотни модулей, понятное имя существенно облегчает понимание кода и не заставляет искать по всем модулям ее описание и инициализацию.

[zer_owlet]

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

ИМХО в функции в 30 строк хоть как называй те переменные, если логика понятна. Названия типа p_asdf для глобальных переменных -- это зло. Названия типа dSummOfAllTransactionsForMay тоже зло. Имена типа sum_may_trans (sumMayTrans) тоже длинные, но в нормальной ИДЕ набираются за 2 секунды. Рассказы "та я не буду платить за то время" можно рассказывать владельцу конторы или менегеру. Остальным для начала нужно дорасти до понимания смысла процесса разработки в команде, при котором у разработчика просто может выпасть день из-за того что рифма не придумывается. При таких делах считать секунды набора имени переменной -- побойтесь Гейтса, ну мы же о рабах на галерах говорим...

Отдельный респект за фразу "Мальчик. Я к твоему сведению постоянно перерабатываю и улучшаю свои программы" -- если разговор о нескольких прогах, которые продаются организациям, то ОК. Но если говорить, например, о фрилансе или о поиске новых клиентов с новыми задачами, то откуда столько времени чтобы улучшать прошлое?