Переменные в программах

varban> Критерий понятности сорса != возможность прочитать его с выражением.

Это верно только для old-school программистов и только для программистов на одном языке

Татарин>> А это именно чистая вкусовщина, в лучшем случае - с псевдорациональной аргументацией.
Balancer> Фигушки, есть рациональная аргументация такой_текст_мозг_токенизирует прощеЧемТакой Элементарно с нашей письменностью связано.
Это напрямую связано с тем, что подчёркивание похоже на пробел. И плохая сторона в том, что имя переменной/функции нужно "токенизировать" лишь однажды, при понимании её смысла, а в тексте программы имя целиком является токеном. Единым токеном. То есть, введёные тобой в имя переменной делимитеры мешают пониманию программы в целом.

Сравни
fgn = pfgnUpdated->value - pfgnUnknown->value + pfgnOld->getUpdatedOffset(pfgnUpdated->value, TRUE).

и

fignya = updated_fignya_pointer->value - unknown_fignya_pointer->value + old_fignya_pointer->get_updated_offset(updated_fignya_pointer->value, TRUE);

Первая строчка ещё вполне управляема. Вторая - не читается вообще. Too many tokens.

Татарин>> Та же информация в меньшем количестве символов - более информативно.
Balancer> Угу. А теперь вспомни принципы помехозащищённости.
У меня нет проблемы помехозащищённости. У меня нет рисков, что где-то там по пути с винта на экран пропадёт или исказится буковка.
Что реально нужно - читаемость, а для этого - сюрприз! - избыточная информация - помеха, потому что тебе нужно уместить прочитаное в кратковременной памяти. См. пример.

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

Татарин>> Я ж не зря сказал про strict convention.
Balancer> Единого стандарта нет даже в рамках одного языка. А уж когда начинаешь работать на смеси языков - вообще сливай воду.
Конечно нет. Именно поэтому мы вынуждены их вводить. Coding guidelines - вплоть до того, где ставить скобку.

Balancer> Именно поэтому button_ok будет нагляднее, чем btnOk.
Практика показывает, что нет, не будет.

Balancer> Плохой. И практика это показывает. По сути сегодня она прижилась только в низкоуровневом программировании на Си++ в Windows
Потому что её часто применяли не там, не те, и не так. А так получалось из-за того, что её насильно насаждали через СДК.

Татарин>> Двно уже бринтские учёые устаоили, что мжно выкнть или прпстить поолину бкв без ущерба для понтнсти.
Balancer> Но читать такой текст сложнее. Трудно это не заметить
Программы не состоят из текстов.
А в смысле понятности btn ничуть не хуже button. btn - лучше, потому что короче (а значит - быстрее читается, в составе сложного имени легче в восприятии (экономит кратковременную и зрительную память).

Татарин> И плохая сторона в том, что имя переменной/функции нужно "токенизировать" лишь однажды

Только в простой программе, с которой работаешь единомоментно. Если к такому коду возвращаешься хотя бы месяц спустя, не говорю уже про год, всё в голову "загружать" надо по новой.

Татарин> Сравни
Татарин> fgn = pfgnUpdated->value - pfgnUnknown->value + pfgnOld->getUpdatedOffset(pfgnUpdated->value, TRUE).
Татарин> и
Татарин> fignya = updated_fignya_pointer->value - unknown_fignya_pointer->value + old_fignya_pointer->get_updated_offset(updated_fignya_pointer->value, TRUE);

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

Татарин> Первая строчка ещё вполне управляема. Вторая - не читается вообще. Too many tokens.

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

Татарин> У меня нет проблемы помехозащищённости.

Она есть у любого представителя Homo Sapiens. Если ты этому виду не принадлежишь - то, возможно, у тебя её нет

Татарин> Что реально нужно - читаемость, а для этого - сюрприз! - избыточная информация - помеха

Эргнмки с псхлгми с тбй свршн. не сгстся

Татарин> Только не в том случае, когда существуют правила создания сокращений.

Угу. Но у каждого языка и даже в каждом проекте правила в итоге разные.

Татарин> Практика показывает, что нет, не будет.

Значит, у нас с тобой очень разная практика

Татарин> Программы не состоят из текстов.

Программы (с которыми работает программист) состоят из текстов. Все. Даже машинные коды Только лексический состав текстов разный. И чем дальше, тем ближе компьютерные языки стремятся к естественнным. Хотя, если ты практикуешь только Си/Си++, ты этого можешь не замечать

Татарин> А в смысле понятности btn ничуть не хуже button. btn - лучше, потому что короче

Хуже. Хотя бы потому что вместо одного токена button в голове оказывается два связных токена - btn и button

varban>> Критерий понятности сорса != возможность прочитать его с выражением.
Balancer> Это верно только для old-school программистов и только для программистов на одном языке

Я, пожалуй, middle-school

Кстати, у нас на форуме нет ни одного программиста старой школы

Balancer> Хотя, если ты практикуешь только Си/Си++, ты этого можешь не замечать

Профессионально (не для себя) - только С.

varban> Кстати, у нас на форуме нет ни одного программиста старой школы

Это для нас с тобой. Для 90% нынешних программеров - мы древние как известная субстанция мамонта

Татарин> btnCancel - btn тут не может стать button, Button, button_, Button_ или _Button. В этом суть.

Почему? На мой взгляд, как раз, совершенно неважно. Важно, что кнопка. Более того, btnCancel на самом деле нужен только тогда, когда всякие очень уж нетривиальные действа с кучей контролов/логики. Т.е. плохой стиль. А обычно методы, вызываемые от объекта вполне понятно дополняют контекст. Like this:

1.       if( sex.getSelected() == MALE ) {
2.           person.sex = MALE;
3.           if( isMaleAllowed().isChecked() ) {
4.                 OK.setEnabled();
5.           }
6.       }

Хотя по старой привычке у все btnCancel и проч. А они имеют смысл только когда интерфейс объекта близок:

1.      labelSex.setText("Sex:");
2.      editSex.setText("male");

Но на самом деле такой код - недоработка, надо делать без префиксов так:

1.      sex.getLabel().setText("Sex:");
2.      sex.setText("male");

А некоторые и вовсе делают так:

1.      form.getComponent(SEX).getLabel().setText("Sex:");
2.      form.getComponent(SEX).setText("male");
3.      form.getButton(OK).setEnabled();

И это на самом деле вовсе не бессмысленно.

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

Сергей-4030> А обычно методы, вызываемые от объекта вполне понятно дополняют контекст.

Что, кстати, справедливо и для "обычного" языка. Можно сказать "автомобиль едет", а можно что "машина едет". И ничего, живем как-то.

Татарин> Постой-постой. Но ведь тут явно указан тип: btnCancel. ЧТо же это, как не венгерская запись?

А с того, что button-ы разные бывают. А int один.

Татарин> А по-моему, очень помогает.

Не, я предпочитаю не типам группировать, а по функциональности или даже бизнес функциональности — т.е. кастомеры вначале, а потом его представление, как объекта, как запись (си) в БД и т.д.

Татарин> Любую идею можно извратить и довести до абсурда.
Дык, это суть венгерской нотации. :f

Balancer> Фигушки, есть рациональная аргументация такой_текст_мозг_токенизирует прощеЧемТакой Элементарно с нашей письменностью связано.

Не, фигня. Мне не надо, чтобы переменную токенизировали. Мне она нужна как один токен. А вот, если надо понять суть токена, то верблюд подсказывает. Если длинные переменные токенизировать, то в среднем операторе/строке будет намного больше 7 токенов, а предел короткой памяти для среднего человека — 7 токенов. Поэтому эту строчку понимать будет трудно. В математике всякие термины и обозначения не зря более 2,000 лет применяют. Иначе просто будет нифига не понять.

Balancer> Угу. А теперь вспомни принципы помехозащищённости. И почему английские радисты понимают друг друга намного хуже, чем немецкие

Это совсем не в тему. У тебя искажения букв при чтении текста не встречается. Поэтому более информативно, хотя и менее помехозащищённо.

Balancer> Именно способы с разного рода сокращениями годятся только для работы в одиночку Ибо в большом коллективе всегда появятся люди, для которых принципы сокращений будут разными. Я на это в L2Fortress хорошо напоролся, когда пытался пропихивать идеи Форт-сокращений. Вот уж где компактность и информационная насыщенность! Увы, и ах. Кмпксть и нсщеннсть обртн. проп. наглядности и понятности


Не, Ром, Татарин прав. У нас тоже есть стандарты кодирования и именования. И это документ уровня policy. т.е. за несоблюдение можно и с работы вылететь.

Balancer> Единого стандарта нет даже в рамках одного языка. А уж когда начинаешь работать на смеси языков - вообще сливай воду.

Его и не надо. Пришёл в чужой монастырь (команду) — подчиняешься его уставу. И смесь языков тут не причём. Вот наша системка использует С, С++, Perl, TCL, Java, Java Scripts, Python, .Net ещё чего-то. Правилоа везде одинаковы.

Balancer> Именно поэтому button_ok будет нагляднее, чем btnOk.
В точности наоборот. Не нужна излишняя токенизация — забивает память, перегружает её.

Balancer> Плохой. И практика это показывает. По сути сегодня она прижилась только в низкоуровневом программировании на Си++ в Windows Можно сказать, что венгерская нотация - пережиток древних времён, во время которых не было нормальных IDE и не было языков с достаточно строгой типизацией

Они плохой, ИМХО, тоже. Но идея стандартов стиля и кодирования — очень даже нет.

Balancer> Но читать такой текст сложнее. Трудно это не заметить

А читать, как формулы легче.

Сергей-4030> sex.getLabel().setText("Sex:");

Кстати, вот чего ещё не понимаю - зачем писать get? Чем логика названия .getLabel() отличается от .label()?

Понятно, когда метод выполняет какое-то действие. Но тогда у него и имя будет из глагола, а не существительного

...

Несколько лет назад отказался от префикса "get" и ни разу не пожалел. Только программы чуть нагляднее стали. Особенно с учётом того, что читать свойства, всё же, приходится обычно много чаще, чем писать

Mishka> А вот, если надо понять суть токена

Да, речь именно об этом. Код, который пишется один раз и забывается редко бывает ценным

Mishka> Если длинные переменные токенизировать, то в среднем операторе/строке будет намного больше 7 токенов, а предел короткой памяти для среднего человека — 7 токенов.

Одинаково будет токенов. Что btnOk, что button_ok - два токена. И там, и там.

Mishka> В математике всякие термины и обозначения не зря более 2,000 лет применяют.

Где в математике аналог camelCase?? А аналог snake_style - обычная письменность.

Mishka> Это совсем не в тему. У тебя искажения букв при чтении текста не встречается.

Легко встречается btnOk + bitOk и button_ok и bit_ok, например. Конечно, от балды, но встречается нередко в сложных именах, когда ошибка в беглом восприятии кода приводит в недоумение и приходится вчитываться внимательнее. Навскидку, конечно, сложнее вспомнить пример из практики

Mishka> Не, Ром, Татарин прав. У нас тоже есть стандарты кодирования и именования.

Да, но это ваши стандарты А латиница - она и в Африке латиница

Mishka> И это документ уровня policy. т.е. за несоблюдение можно и с работы вылететь.

Это совсем другая история. Но то, что документ - полиси, не делает то, что в нём описано, автоматически хорошим Да, когда того требуют правила, я и сам пишу и в camelCase, и в венгерской нотации Ту же Java взять. Там уже "так принято". Но - только когда требуют правила. И это не мешает мне понимать неудобство этих правил с точки зрения эргономики

Mishka> Его и не надо. Пришёл в чужой монастырь (команду) — подчиняешься его уставу.

Да. Но иногда монастырь создаёшь сам. И тут удобно не тупо копировать неудобный стиль, а задействовать оптимальные решения

Mishka> И смесь языков тут не причём.

Очень даже при чём Разные языки диктуют разные стили и сокращения.


Mishka> Вот наша системка использует С, С++, Perl, TCL, Java, Java Scripts

Ну, это одно и то же

Mishka> Python

Вот, хороший пример. В Питоне не принят camelCase. Там принят snake_style. Так что же, вы используете смесь стилей в нём? Или пишете обёртки стандартным методам?

Mishka> .Net

Это ж не язык А на .Net - в том же C# будет всё тот же Си-стиль, а в boo - будет python.

Mishka> Правилоа везде одинаковы.

Так как вы на Питоне пишете? С нарушением его правил?

Mishka> В точности наоборот. Не нужна излишняя токенизация — забивает память, перегружает её.

ЧтоЖеТыТогда в русскомЯзыке излишнейТокенизации неИзбегаешь?

Balancer> Да, речь именно об этом. Код, который пишется один раз и забывается редко бывает ценным

Нет, это разные вещи. Вот скажем, ты имеешь ф-цию sin. За ней стоит много чего. Но она токен. Точно так же arctan один токен, хотя математически есть префикс обратной ф-ции. И воспрималось бы всё по другому, если бы было arc_tan. А вот arcTan уже ни чем не отличается от arctan. И не надо его каждый раз токенизировать. И нормально воспринимается. Потому, что в коде важен и алгоритм. Там свои токены. Другого уровня, но токены. А, если ты их будешь разжижать токенами переменных, то совсем плохо.

Balancer> Одинаково будет токенов. Что btnOk, что button_ok - два токена. И там, и там.

Неа. Вот возми

1. alpha_small = ( delta_deviation * average_value ) / number_of_tests;

"Глаз" совершенно точно выделяет 9 слов, 2 действия и 2 скобки. Всего 13 токенов.

Другой код

1. alphaSmall = ( deltaDeviation * averageValue ) / numberOfTests;

И у нас 4 слова, 2 действия, 2 скобки — всего 8.

Кстати, это мой стиль — выделять пробелами, тогда глаз хватает.

И дальше, как в математике — токен alphaSmall опознаётся на ура и ассоциация сама всплывает.

Balancer> Где в математике аналог camelCase?? А аналог snake_style - обычная письменность.

A^i, к примеру. До фига надстрочников, подстрочников, индексов. А так же куча стилей написания — A, B, C не то же самое, что а, и, с.

Balancer> Легко встречается btnOk + bitOk и button_ok и bit_ok, например.

У меня без проблем. Было бы плохо, если бы btnOk и bit0k, но тут и это уже совсем криминал.

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

Чтобы при беглом чтении понять, ИМХО, как раз опознование по токену надо. А не по двум.

Balancer> Да, но это ваши стандарты А латиница - она и в Африке латиница

Это потому, что это наша команда. Не 1,000 человек, но около 100 будет. И потому, зная правила, читать легче. Но насчёт латиницы — посмотри у вьетнамцев. И попробуй использовать.

Balancer> Это совсем другая история. Но то, что документ - полиси, не делает то, что в нём описано, автоматически хорошим Да, когда того требуют правила, я и сам пишу и в camelCase, и в венгерской нотации Ту же Java взять. Там уже "так принято". Но - только когда требуют правила. И это не мешает мне понимать неудобство этих правил с точки зрения эргономики

Нет, но это именно то, про что говорит Татарин. Предсказуемость.

Balancer> Да. Но иногда монастырь создаёшь сам. И тут удобно не тупо копировать неудобный стиль, а задействовать оптимальные решения

Гы, какая разница кто создаёт? Важно, что ты устанавливаешь правила. И другие им должны следовать.

Balancer> Очень даже при чём Разные языки диктуют разные стили и сокращения.

В нонешний век — нифига! Раньше — да, всякие ограничения на длину были маленькие.

Balancer> Вот, хороший пример. В Питоне не принят camelCase. Там принят snake_style. Так что же, вы используете смесь стилей в нём? Или пишете обёртки стандартным методам?

Как это не принят. У нас очень даже принят. У нас. И расслоение у нас с API везде. Ну и различие наших имён и системных легко позволяет отличить одни от других.

Balancer> Это ж не язык А на .Net - в том же C# будет всё тот же Си-стиль, а в boo - будет python.

Да примерно то же самое, что и python — набор библиотек со своими API, а так же расширениями языка.

Balancer> Так как вы на Питоне пишете? С нарушением его правил?

Обёртки-скрипты разные. И правил там нет на эту тему. Есть некоторые соглашения.

Balancer> ЧтоЖеТыТогда в русскомЯзыке излишнейТокенизации неИзбегаешь?

Да тем же самым — ты же ставишь заглавную букву после точки. А токенизации избегаю, скажем, когда говорю про наш продукт, то и называю его eHealth. Ну и разные сокращения-аббревиатуры — именно оттуда. Про математику уже говорил.

Сергей-4030>> sex.getLabel().setText("Sex:");
Balancer> Кстати, вот чего ещё не понимаю - зачем писать get? Чем логика названия .getLabel() отличается от .label()?

Ну, в общем-то можно не писать, но тут такая проблема - иногда слово может быть и глаголом и существительным. И тогда непонятно, что такое o.job() - это значит "работай" или "какое задание назначено?". Можно, конечно, сделать в качестве "работай" o.doJob(), но возвращаемся к префиксам.

Сергей-4030> Можно, конечно, сделать в качестве "работай" o.doJob()

Именно так и делаю

Сергей-4030> но возвращаемся к префиксам.

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

arcicle()->image()->thumbnail()->html_code();

сравни в

getArcicle()->getImage()->getThumbnail()->getHtmlCode();

Balancer> Но такие случаи встречаются намного реже, чем "get" в каждом первом вызове параметра
arcicle()->image()->thumbnail()->>html_code();

Если я правильно помню, то в этом случае ты можешь изменить состояние объекта (в том числе и присваниванием) в твоём примере.

Balancer> сравни в
getArcicle()->getImage()->getThumbnail()->>getHtmlCode();
Balancer>

Гораздо лучше, поскольку тут оно означает, согласно местным правилам read only.

Mishka> arcicle()->image()->thumbnail()->>html_code();
Mishka> getArcicle()->getImage()->getThumbnail()->>getHtmlCode();
Не стал править, но при ответе на твой пост местами получились двойные знаки больше.

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

Потому что парсер воспринимает их как цитирование Нужно в [code]...[/code] включать

Mishka> arcicle()->image()->thumbnail()->html_code();
Mishka> Если я правильно помню, то в этом случае ты можешь изменить состояние объекта (в том числе и присваниванием) в твоём примере.

Нет, все объекты тут - R/O. Изменение только через set_XXX(...)

Mishka> Гораздо лучше, поскольку тут оно означает, согласно местным правилам read only.

Но это ваши местные правила

Татарин>> И плохая сторона в том, что имя переменной/функции нужно "токенизировать" лишь однажды
Balancer> Только в простой программе, с которой работаешь единомоментно.
В любой. При любом раскладе ты один раз понимаешь, что значит данная переменная. Дальше подчёркивания тебе только мешают.

Balancer> Получается, второй вариант - самодокументирующийся. Первый же требует ещё отдельного соглашения о нотации.
Так, блин, мы же и говорим о преимуществах введения соглашений. Разумеется, требует, разумеется их и пользует, в этом-то и суть.
При этом соглашения (и привычка к ним) существуют в любом случае - явно ли оговорены или нет. Гораздо лучше в больших проектах, когда соглашения оговорены явно.

Уровень самодокументации в итоге - один и тот же.

Татарин>> У меня нет проблемы помехозащищённости.
Balancer> Она есть у любого представителя Homo Sapiens. Если ты этому виду не принадлежишь - то, возможно, у тебя её нет
Что вероятнее: что я не принадлежу Хомо Сапиенс или что ты всё-таки тут неправ?


Татарин>> Что реально нужно - читаемость, а для этого - сюрприз! - избыточная информация - помеха
Balancer> Эргнмки с псхлгми с тбй свршн. не сгстся
Пусть хоть пять тысяч триста восемьдесят девять психологов плюс восемьсот сорок три раза эргономиков со мной не соглашаются каждый по разу, я буду прав все 5389+843 раза.

Татарин>> Только не в том случае, когда существуют правила создания сокращений.
Balancer> Угу. Но у каждого языка и даже в каждом проекте правила в итоге разные.
Да. И?
Изначально утверждалось, что для больших проектов эти соглашения рулят. В нынешнем индустриальном программировании человек может провести несколько лет в пределах одного проекта. И это скорее правило, чем исключение.

Татарин>> Практика показывает, что нет, не будет.
Balancer> Значит, у нас с тобой очень разная практика
Да.

Татарин>> А в смысле понятности btn ничуть не хуже button. btn - лучше, потому что короче
Balancer> Хуже. Хотя бы потому что вместо одного токена button в голове оказывается два связных токена - btn и button
Токен один - btn. Откуда button-то?

Татарин>> Постой-постой. Но ведь тут явно указан тип: btnCancel. ЧТо же это, как не венгерская запись?
Mishka> А с того, что button-ы разные бывают. А int один.
Татарин>> Любую идею можно извратить и довести до абсурда.
Mishka> Дык, это суть венгерской нотации. :f
Ладно, хорошо, это не венгерская запись.

Что это?

Гм, а я в счетчиках циклов не "i", а "c" всегда применяю. Наверно сказываются ассемблеровские замашки . i, j и k я применяю только для индексов массивов. А вообще - предпочитаю говорящие имена переменных. Написать несколько лишних букв с меня не убудет, зато гораздо проще потом в коде программы разбираться при отладке.

Татарин> Ладно, хорошо, это не венгерская запись.
Татарин> Что это?

Свои правила. Правила, применённые по делу — рулят. А правила ради правил — всегда и везде без изменений — не очень.

Вообще-то надо соблюдать нотации, принятые в данной компании. Очень забавно работать в компаниях, в которых единных кодинг стандартов не существует (большинство).
Для меня, лично, венгерская нотация - рулез. Очень хорошо смотрятся большие проекты, легко навигировать и вносить изменения.
Для составных типов хорошо придерживатся к йерархии названий. Например:
class Table;
class TableCell;
class TableCellContent;

Если пользуемся IDE, очень удобно придерживатся к йерархии смысла, например:
вместо
class CubePrimitive;
class SpherePrimitive;
class PlanePrimitive;
class CurvedPlanePrimitive;
лучше написать:
class PrimitiveCube;
class PrimitiveSphere;
class PrimitivePlane;
class PrimitivePlaneCurved;

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