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

HolyBoy> Подумал: а ведь в самом деле, я практически всегда использую эту переменную в циклах. Интересно с чего началось победное шествие именно этого имени, а также, j и k? С математических умолчаний для диапазонов?
С традиции. i у математиков традиционно "пусть существует принадлежащая" N или Z. Самое логичное взять её для счётчика. Кроме того, index == idx == i.

HolyBoy> Также, интересно, кто как называет переменные?

Татарин> С традиции. i у математиков традиционно "пусть существует принадлежащая" N или Z. Самое логичное взять её для счётчика. Кроме того, index == idx == i.

Ага, так и думал.

Татарин> Венгерская нотация — Википедия

Зло. Но кому что нравится… ©

HolyBoy> Зло. Но кому что нравится… ©


Вот именно так, да.

HolyBoy> Подумал: а ведь в самом деле, я практически всегда использую эту переменную в циклах. Интересно с чего началось победное шествие именно этого имени, а также, j и k?

патамушта из всех циклов с переменными первым придумали цикл с простым инкрементом.
пс ну а дальше тупо по алфавиту...

Татарин> С традиции. i у математиков традиционно "пусть существует принадлежащая" N или Z. Самое логичное взять её для счётчика. Кроме того, index == idx == i.

Ага. a, b, c — константы; x, y, z — переменные; i, j, k — индексы для перечисляемых множеств; для мощностей всякие алефы, для чего-то подобного i, j, k в непрерывном случае всякие дельта-эпсилоны. Ну и надо вспомнить, кто были первые потребители Фортрана — там ещё и тип переменной объявлялся неявно как целый для определённых букв.

А венгерская нотация зло. Вот такое моё ИМХО.

Mishka> А венгерская нотация зло. Вот такое моё ИМХО.

Для плюсов и прочих языков, где помимо встроенных типов данных есть ещё полиморфные объекты, - да. А для какого-нибудь C сойдёт Хотя я тоже не пользуюсь - не вижу особого смысла.

ЗЫ лично я i воспринимаю как сокращение от iterator, а не от index

Kuznets> патамушта из всех циклов с переменными первым придумали цикл с простым инкрементом.
Kuznets> пс ну а дальше тупо по алфавиту...

Шиш. Матрицы вполне себе придумали до циклов. У них уже были такие индексы. Ну, а ряды ещё раньше.

Mishka> А венгерская нотация зло. Вот такое моё ИМХО.
"Вы их готовить не умеете." (С)

fpszString, dwCounter - это, конечно, зло чистое, рафинированое.
А вот btnCancel, m_tblCustomers - рулез. Потому что это сильное (strict) соглашение об информативных именах, и это гораздо лучше, кратче, информативнее, чем OKButton, CustomersDataTable.

kuku67> настоящие программисты выросли из фортрана
kuku67> в фортране I, J, K по умолчанию целочисленные

Угу. А потом ещё в Бейсике закрепили DEFINT I всякими

Татарин> "Вы их готовить не умеете." (С)

Умеем, просто отличаем хрен от пальца венгерские, от общих.

Татарин> fpszString, dwCounter - это, конечно, зло чистое, рафинированое.

Это и есть венгерская.

Татарин> А вот btnCancel, m_tblCustomers - рулез. Потому что это сильное (strict) соглашение об информативных именах, и это гораздо лучше, кратче, информативнее, чем OKButton, CustomersDataTable.

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

kuku67> настоящие программисты выросли из фортрана
kuku67> в фортране I, J, K по умолчанию целочисленные

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

... L, M, N.

Я на FORTRAN пересел с BASIC (и чуть Algol, в рамках учебного курса).
Ну и напейсал программу интегрирования дифура без учета этой особености.

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

Mishka> А венгерская нотация зло. Вот такое моё ИМХО.

Кому как.

Это способ держать перед глазами типы переменных и постоянно напоминать о преобразовании типов.

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

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

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

varban> Кому как.

Почти всем и всегда.

varban> Это способ держать перед глазами типы переменных и постоянно напоминать о преобразовании типов.

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

Венгерская нотация способ подсказать. Для языков со структурной типизацией. С, Алгол 68 (не беря структуры, как типы). А вот с именной типизацией такого уже нет — Паскаль, Ада. Компилятор в последних сам отслеживает.

varban> Я на венгерскую нотацию набрел, когда пришлось поддерживать чужой софт. В начальном варианте компилятор завершал транцляцию, выдавая несколько сотен предупреждений. Было несколько редко проявляющихся багов. Смена версии компилятора приводила к неработоспособностью софта.

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

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

А зачем тут венгерская нотация? Если ты убирал предупреждения вставлением ядер, то это, как бы, и не кошерно. Потому, как компилятор перестанет ругаться, но это не значит, что семантически верно. А тот же С++ уже позволяет писать вполне кошерно на уровне классов. Правда, преобразования типа вводят в ступор даже хорошо разбирающихся в С++. Но это скорее правила поиска преобразований (или приведений в термнах Алгола 68).

varban> Поскольку перед этим вдвоем бились несколько месяцев, на меня этот успех произвел неизгладимое впечатление. И в следующий свой проект я использовал венгерскую нотацию еще с чистого экрана.

Mishka> так писать можно на любом языке.

По-сиукски. Конкретно - Turbo C 1.0.
Я к тому времени писал на Borland C 3.0 и переползал на 3.1.

атарин> А вот btnCancel, m_tblCustomers - рулез. Потому что это сильное (strict) соглашение об информативных именах, и это гораздо лучше, кратче, информативнее, чем OKButton, CustomersDataTable.

1. Любые проявления camelCase считаю чистым злом

2. Более короткий вариант не считаю более информативным. Поэтому в моих программах это будет ok_button или button_ok (по контексту) Если лениво вводить лишний символ в имени переменной - то что-то не так в консерватории. Походу, ты пишешь так много, что не остаётся времени думать

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

Mishka> Но, если первая хорошо, то вторая уже спорно.
А по-моему, очень помогает.

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

Balancer> 1. Любые проявления camelCase считаю чистым злом
оВкусахНеСпорят.
А это именно чистая вкусовщина, в лучшем случае - с псевдорациональной аргументацией.

Balancer> 2. Более короткий вариант не считаю более информативным.
Та же информация в меньшем количестве символов - более информативно.
Ты можешь не считать, но оно так ЕСТЬ.

Balancer> Поэтому в моих программах это будет ok_button или button_ok (по контексту) Если лениво вводить лишний символ в имени переменной - то что-то не так в консерватории. Походу, ты пишешь так много, что не остаётся времени думать
Э, не. Вот именно первое предложение твоего абзаца полностью раскрывает эту тему. "ок_буттон или буттон_ок (по контексту)" - такой подход сканает только если ты работаешь один или в команде из 2-3 человек. А если за время жизни твоего кода к нему имеет активно доступ (читает, понимает, перепользует, вносит серьёзные правки, рефакторит) 2-3 десятка человек, подход уже совсем-совсем иной.

Я ж не зря сказал про strict convention. Потому что как только ты поработаешь в большой команде, меньше всего, что тебе захочется - это сидеть и думать, глядя на код, о том, какой "контекст" был в голове того, кто это писал. Тебе захочется предсказуемости и однозначности правил именования, единый стиль. Венгерская запись - хороший путь к.
btnCancel - btn тут не может стать button, Button, button_, Button_ или _Button. В этом суть. А лишние три буквы ничего к понятности не добавляют совершенно. Двно уже бринтские учёые устаоили, что мжно выкнть или прпстить поолину бкв без ущерба для понтнсти.

varban> Поскольку перед этим вдвоем бились несколько месяцев, на меня этот успех произвел неизгладимое впечатление. И в следующий свой проект я использовал венгерскую нотацию еще с чистого экрана.
Дело в том, что венгерская нотация часто навязывалась MS во всех её SDK людям, которые не понимали её смысла и часто в случаях, когда она на самом деле не имела смысла.

Отношение у людей, которые сами пришли к ней и используют с пониманием - совсем иное.

Татарин> Та же информация в меньшем количестве символов - более информативно.
количество меньше, а вот нажатий на клавиши - одинаково. Хотя ИМХО на "верблюдов" глаз цепляется лучше, и подчеркивания с пробелами мешаться не будут.

Татарин> А это именно чистая вкусовщина, в лучшем случае - с псевдорациональной аргументацией.

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

Татарин> Та же информация в меньшем количестве символов - более информативно.

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

Татарин> Э, не. Вот именно первое предложение твоего абзаца полностью раскрывает эту тему. "ок_буттон или буттон_ок (по контексту)" - такой подход сканает только если ты работаешь один или в команде из 2-3 человек.

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

Татарин> Я ж не зря сказал про strict convention.

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

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

Именно поэтому button_ok будет нагляднее, чем btnOk.

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

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

«Этот стиль выбора имён называется «венгерской» записью по названию родины руководителя отдела программирования Microsoft Чарльза Симони, который его изобрёл. (А не потому, что его использование придаёт программам такой вид, будто они написаны на венгерском языке»

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

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

spam_test> количество меньше, а вот нажатий на клавиши - одинаково.
Лично меня нажатия на клавиши не ломают, лишь бы текст был понятен, легко читался и правился.

spam_test> Хотя ИМХО на "верблюдов" глаз цепляется лучше,
По-моему - тоже.

Я логику в твоем постинге не отрицаю, но не могу пройти мимо:

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

Сорс - особый вид текста.

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