Здравствуйте, McSeem2, Вы писали:
MS>Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем). MS>
Здравствуйте, McSeem2, Вы писали:
MS>Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем). MS>
Ох нехотел влезать в этот бестолковый спор о вкусах, но такая "изумительная" аргументация просто подталкнула к этому.
Не споря о том, какой стиль лучше (на мой взгляд лучше тот к которому привык и о котором договорился с остальными), скажу, что твой пример не чем кроме как подтасовки назвать нельзя, так как твои оппонетны предлагают использовать подчеркивания исклчительно для выделения переменных членов и глобальных переменных. Причем в их натации после подчеркивания не пишется так нелепо выглядящая в этом случае большая буква. Если твой код отформатировать в соотвествии с предложением твоий оппонентов, то он будет выглядеть примерно так:
Это при условии, что все неописанные переменные являются полями. Рельно же такого количества полей вряд ли встртишь.
Кстати, со своим экстровагантным выделением скобок и стремлением сжать все в кучу, ты потерял скобку.
А вот на что действительно стоило бы оратить внимание, так это на то что весь код утыкан совершенно бессмыслеными однобуквенными идентификатороами которые что с подчеркиваеним, что без него смысла не имеют.
... << RSDN@Home 1.2.0 alpha rev. 631>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Неужели, говорят, в C# слово this надо обязательно писать? Отвечал, что не обязательно, но я его всегда пишу потому что я дисциплинированный.
Сергей! А как же синтаксический оверхед?
На мой взгляд, стиль m_nnn — это вполне разумно. Собственно, это единственное, что я активно использую из старых MS-рекомендаций. А в C# его явно или неявно душат (дизайнером форм, например). Типа раньше всех убеждали, как "m_" и венгерская нотация полезны для здоровья, а теперь это стало не вкусно, выплюньте.
Что же касается подчеркиваний, то начинать или заканчивать ими — это полный атас. Мало того, что может потенциально привести к конфликтам, так еще и код весь превращается в крокозяблики.
Лично у меня от такого рябит в глазах и болит голова.
По моему глубокому убеждению, идентификаторы должны начинаться и заканчиваться буквами. Прописными или строчными, но буквами. Подчеркивания допустимы (и даже необходимы) внутри идентификатора, но не по краям. В этом случае, идентификаторы гораздо легче визуально отделяются от знаков препинания (операций) — как в обычном, естественном тексте. Иначе неизбежно полявляются brainfuck-шедевры типа:
_a_-_b_._c_->_d_
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ответ вызван в связи твоего вопроса. Блин. Да. Вот. Десять. Рекомендую учить РУССКИЙ!
эти все разговоры мне напоминают дискуссии на тему: "мля" это суффикс или приставка?
И всегда очень серьезно, с указаним различных первоисточников с нумерами страшными и ссылок на внутренние стандарты корпораций "мля-Вован" и "Колян-мля".
Здравствуйте, McSeem2, Вы писали:
MS>Что же касается подчеркиваний, то начинать или заканчивать ими — это полный атас. Мало того, что может потенциально привести к конфликтам, так еще и код весь превращается в крокозяблики. MS>
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Здравствуйте, FurJ, Вы писали:
FJ>>для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.
L_L>Имена, начинающиеся с __ или _Большая буква — зарезервированы. Имя, начинающееся с подчеркивания зарезервировано в глобальном пространстве имен (и пространстве имен ::std).
Точнее, зарезервированы имена содержащие __, в начале или нет — не важно.
The last good thing written in C was Franz Schubert's Symphony No. 9.
Здравствуйте, McSeem2, Вы писали:
MS>По моему глубокому убеждению, идентификаторы должны начинаться и заканчиваться буквами. Прописными или строчными, но буквами. Подчеркивания допустимы (и даже необходимы) внутри идентификатора, но не по краям. В этом случае, идентификаторы гораздо легче визуально отделяются от знаков препинания (операций) — как в обычном, естественном тексте. Иначе неизбежно полявляются brainfuck-шедевры типа: MS>
Сам для членов класса использую префикс m_. Привычно, хотя и избыточно слегка. В последнее время в C++ модно стало завершающее подчеркивание использовать (в ACE, например, это вообще стандарт кодирования), но меня смущает, чть если к члену через точку к методу какому-то обращаться, то эта точка получается не очень заметна визуальна (особенно, если в редакторе пропорциональный шрифт используется).
А одновременное использование лидирующего и заверщающего подчеркивания действительно неудобоваримые комбинации могут образовывать
Здравствуйте, FurJ, Вы писали:
AVK>>В Java стиль описан документом от Sun.
FJ>Подчеркивания я там что то не припомню. — к сожелению не видел документа от Sun (можно ссылку?), но замечал что этот стиль у большинства Java-программеров (Фаулер — самый яркий представитель).
Field naming
Names of non-constant fields (reference types, or non-final primitive types) should use the infixCaps style.
Start with a lower-case letter, and capitalize the first letter of any subsequent word in the name, as well as
any letters that are part of an acronym. All other characters in the name are lower-case. Do not use underscores
to separate words. The names should be nouns or noun phrases. Examples:
Здравствуйте, FurJ, Вы писали:
FJ>для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.
Имена, начинающиеся с __ или _Большая буква — зарезервированы. Имя, начинающееся с подчеркивания зарезервировано в глобальном пространстве имен (и пространстве имен ::std).
Of course, the code must be complete enough to compile and link.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>На самом деле любую нотацию можно довести до brainfuck-a. Замени в этом примере подчеркивание на "m_" — в глазах будет рябить не меньше.
Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем).
А я на (C#):
Переменные члены класса (в т.ч. статические) называю маленькими буквами: channel, handler, recognizer;
Локальные переменные (с маленькой областью видимости) обозначаю 1-2 буквами: a, b, c, s, h, i, j, n, rd, wr...;
Типы, процедуры, свойства, элементы enum-ов начинаю с большой буквы (а интерфейсы с I): Channel, Handler, IReader, IWriter,...;
Константы пишу заглавными буквами: MIN_LENGTH
При обращении к любым идентификаторам пишу их полное имя:
this.*** — обращение к членам;
MyClass.*** — обращение к статическим членам;
Namespace1.Namespace2.Namespace3.SomeClass1.*** — обращение ко всему, что за пределами данного класса.
Короче, получается так, что глядя даже на небольшой фрагмент текста (заранее не зная, что обозначают идентификаторы) — становится понятно что написано. Всегда!
Плюсовики видевшие мои тексты сразу спрашивали почему у меня везде написано: this.***, this.***, this.***? Неужели, говорят, в C# слово this надо обязательно писать? Отвечал, что не обязательно, но я его всегда пишу потому что я дисциплинированный.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Надо же как-то указать на то что идентификатор принадлежит объекту, а не взят с потолка.
Зачем? И так понятно.
СГ>Кстати, например, в языках Oberon-2 и Component Pascal аналог this надо писать обязательно:
Брр. Г-н Вирт что, Турбо-Паскаль не учил?
Синтаксический оверхед однозначна.
Что касается вашего стиля, это все равно что скрестить ужа с ежом. Точнее прилеплять иголки к ужу. Ну не идет подходит стиль Оберона к С#. Слишком разные языки. Пацаны такой текст не поймут.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А я на (C#): СГ>Переменные члены класса (в т.ч. статические) называю маленькими буквами: channel, handler, recognizer; СГ>Локальные переменные (с маленькой областью видимости) обозначаю 1-2 буквами: a, b, c, s, h, i, j, n, rd, wr...; СГ>Типы, процедуры, свойства, элементы enum-ов начинаю с большой буквы (а интерфейсы с I): Channel, Handler, IReader, IWriter,...; СГ>Константы пишу заглавными буквами: MIN_LENGTH
СГ>При обращении к любым идентификаторам пишу их полное имя: СГ>this.*** — обращение к членам; СГ>MyClass.*** — обращение к статическим членам; СГ>Namespace1.Namespace2.Namespace3.SomeClass1.*** — обращение ко всему, что за пределами данного класса.
Если придерживаться 3 простых правил, то путаницы не будет:
1. функции не больше 2 экранов.
2. глобальным объектам — строгое нет.
3. локальные переменные объявлять непосредственно перед использованием.
СГ>Короче, получается так, что глядя даже на небольшой фрагмент текста (заранее не зная, что обозначают идентификаторы) — становится понятно что написано. Всегда!
Утешай себя Просто так, добавляя лишь this, понятность не вырастет, если код изначально корявый.
СГ>Плюсовики видевшие мои тексты сразу спрашивали почему у меня везде написано: this.***, this.***, this.***? Неужели, говорят, в C# слово this надо обязательно писать? Отвечал, что не обязательно, но я его всегда пишу потому что я дисциплинированный.
Нет, это — неуместное занудство, а не дисциплина. И достаточно чтобы посторонний человек поработал с таким кодом чуть-чуть и кое-где забыл написать this, все, целостность нарушена и дальше тебя будут вспоминать только недобрыми словами.
Здравствуйте, GlebZ, Вы писали:
GZ>Этот код не пацан писал. А генерировал автоматизированный resharper.
Не resharper, а reflector! Это немного разнае программы.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_". Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания. Подобный стиль нередко встречается и у Unix-программистов. Насколько применима данная рекомендация для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.
Здравствуйте, FurJ, Вы писали:
FJ>Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_". Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания. Подобный стиль нередко встречается и у Unix-программистов. Насколько применима данная рекомендация для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.
Нормально все применимо. Ты все равно не угадаешь. Вот у нас был свой контейнер CStringBuf, а потом вышел ATL7.0, где появился с таким же именем — и все, наш пришлось переименовать.
Здравствуйте, FurJ, Вы писали:
FJ>Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_". Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания. Подобный стиль нередко встречается и у Unix-программистов. Насколько применима данная рекомендация для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.
Вроде бы МС и для C# не рекомендует начинать идентификаторы с подчеркивания из соображений совместимости
ээээ...
с нижнего регистра начинаются имена любых переменных..
с верхнего — функций..
а имена переменных-членов (класса) должны еще заканчиваться _ (подчеркиванием)
кстати "альтернативная" типа была предложена г.саттером.....
STOP Java !
STOP .NET !
STOP JIT at ALL !
Take UnRestricted !
Здравствуйте, FurJ, Вы писали:
FJ>Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_".
Нет. Венгерка предполагает не просто префикс, а префикс, отражающий тип.
FJ> Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания.
В Java стиль описан документом от Sun. Подчеркивания я там что то не припомню. А в C# разные стили бывают, в том числе и с m_.
Здравствуйте, smidy, Вы писали:
S>а имена переменных-членов (класса) должны еще заканчиваться _ (подчеркиванием)
Александреску в своей литертуре примеры пишет с подобной загагулиной. Также подобный стиль принят в сорцах Loki. Однако, хотелось бы узнать, что говорит стандарт по поводу переднего подчеркивания.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет. Венгерка предполагает не просто префикс, а префикс, отражающий тип — согласен, просто я это опустил, поскольку к сути вопроса это отношения не имеет.
AVK>В Java стиль описан документом от Sun. Подчеркивания я там что то не припомню. — к сожелению не видел документа от Sun (можно ссылку?), но замечал что этот стиль у большинства Java-программеров (Фаулер — самый яркий представитель).
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Имена, начинающиеся с __ или _Большая буква — зарезервированы. Имя, начинающееся с подчеркивания зарезервировано в глобальном пространстве имен (и пространстве имен ::std).
Таким образом можно смело называть член класса именем типа _мАленькаяБуква?
Здравствуйте, McSeem2, Вы писали:
MS>Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем). MS>
Здравствуйте, AndrewVK, Вы писали:
AVK>В Java стиль описан документом от Sun. Подчеркивания я там что то не припомню. А в C# разные стили бывают, в том числе и с m_.
Стили то разные. Но префикс m_, насколько я помню, был явно запрещен в рекомендательном порядке.
Здравствуйте, GlebZ, Вы писали:
GZ>Сергей! А как же синтаксический оверхед?
Он отсутствует.
Надо же как-то указать на то что идентификатор принадлежит объекту, а не взят с потолка. Записывая так:
"идентификатор объекта"."идентификатор члена"
мы получаем то, что нам было нужно, и платим за это минимальную цену.
Кстати, например, в языках Oberon-2 и Component Pascal аналог this надо писать обязательно:
PROCEDURE (me: MyObject) DoSmth* (arg: Arg), NEW, EXTENSIBLE;
BEGIN me.value := arg
END DoSmth;
Здесь me — играет роль this (можно называть как хочется: me, self, this, p, q,..., я,... — это просто имя 0-вого аргумента вызова
процедуры связанной с типом MyObject).
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Он отсутствует. СГ>Надо же как-то указать на то что идентификатор принадлежит объекту, а не взят с потолка. Записывая так:
СГ>"идентификатор объекта"."идентификатор члена"
СГ>мы получаем то, что нам было нужно, и платим за это минимальную цену. СГ>Кстати, например, в языках Oberon-2 и Component Pascal аналог this надо писать обязательно:
А, то есть минимальная цена = (цене в Oberon-2 и Component Pascal) по определению?
Минимальная цена — не указывать лишних квалификаторов. Несложные правила именования позволяют не натыкаться на конфликты между именами параметров, переменными, и полями.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
MS>>Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем).
VD>Если твой код отформатировать в соотвествии с предложением твоий оппонентов, то он будет выглядеть примерно так:
[. . .]
Я специально сделал оговорку, что "прочие аспекты не рассматриваем".
VD>Кстати, со своим экстровагантным выделением скобок и стремлением сжать все в кучу, ты потерял скобку.
Код не мой, Copyright (c) 1995 by P.J. Plauger. Это copy-paste куска из std::vector. Я его привел, чтобы показать всю несуразность, когда сначала возникают некие догмы, а потом они доводятся до полного абсурда.
STLPort, кстати, не лучше
Тот же самый brainfuck и спереди и сзади, похожий на азбуку Морзе. Плюс ко всему, в нем присутствуют строки неимоверной длины. Но эту тему мы не будем развивать.
За потерянную скобку приношу наиглубочайшие извинения и проч.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, aik, Вы писали:
aik>Нет, это — неуместное занудство, а не дисциплина. И достаточно чтобы посторонний человек поработал с таким кодом чуть-чуть и кое-где забыл написать this, все, целостность нарушена и дальше тебя будут вспоминать только недобрыми словами.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>На самом деле любую нотацию можно довести до brainfuck-a. Замени в этом примере подчеркивание на "m_" — в глазах будет рябить не меньше.
MS>Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем). MS>
Здравствуйте, alexeiz, Вы писали:
A>Что тебе не нравится? Двойное подчёркивание?
Ну да. Я честно не понимаю, зачем все аргументы функций и все локальные переменные начинать с двойного подчеркивания. Это чисто мусор, без малейшей реальной пользы.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
A>>Что тебе не нравится? Двойное подчёркивание? MS>Ну да. Я честно не понимаю, зачем все аргументы функций и все локальные переменные начинать с двойного подчеркивания. Это чисто мусор, без малейшей реальной пользы.
Это из-за препроцессора. Чтобы конфликта имен небыло.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, McSeem2, Вы писали:
A>>>Что тебе не нравится? Двойное подчёркивание? MS>>Ну да. Я честно не понимаю, зачем все аргументы функций и все локальные переменные начинать с двойного подчеркивания. Это чисто мусор, без малейшей реальной пользы. WH>Это из-за препроцессора. Чтобы конфликта имен небыло.
Точно. Агрумент такой, что ты можешь определить макро совпадающее с идентификатором из стандартной библиотеки перед включением хедеров из библиотеки. И тогда она сломается. Если же библиотека использует только зарезервированные имена идентификаторов, которые ты по стандарту не имеешь права определять, то ты защищён от подобного конфликта.
Здравствуйте, FurJ, Вы писали:
FJ>Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_".
Много смеялся, спасибо. Почуял ностальгию.
FJ>Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания. Подобный стиль нередко встречается и у Unix-программистов. Насколько применима данная рекомендация для C++ — программирования?
Хочешь — применяй. Не хочешь — не применяй. Как ты думаешь, насколько важно ходить на работу в малиновых штанах если ты не менеджер?
FJ>Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.
Да, зарезериврованы.
Но!
Ответ вызван в связи твоего вопроса. Блин. Да. Вот. Десять. Рекомендую учить РУССКИЙ!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!