Здравствуйте, CreatorCray, Вы писали:
E>>Ну фар или NotePad не так уж и разнятся. CC>Раскраской синтаксиса как минимум.
ИМХО, вопрос привычки
E>>А вообще хинт в том, что даже если у тебя есть пять файлов из проекта, где их 1000, то без проекта IDE тебе не поможет CC>Зачастую все же помогает.
Ну да, но и просто поиск рулит, а ещё больше рулит хороший код
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Left2, Вы писали:
L>префиксы типа перед переменными существенно (настолько существенно, что есть смысл заморачиваться на их написание) увеличивают читабельность кода.
1) Простые типы, кроме чисел, в хорошем С++ коде -- редкость.
Вот, например, какой "венгерский" префикс ты используешь для переменной типа std::vector< std::pair<int, std::string> >::itrrator?
2) В нормальном С++ коде тип переменных обычно не важен. Случаи, когда таки важен, обычно такие, что хотя бы одна из двух переменных, а обычно обе -- классы какие-то.
Короче пользы мало, да ещё и для большинства переменных и не понятно что писать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: правильный современный стиль кодирования на C++?
L>>Ну вот — а венгерская нотация позволяет это делать реже за счёт того что основную идею о том какого типа переменная можно понять не елозя мышкой. CC>Набор везде по коду префиксов гораздо более трудооемко чем пару раз шевельнуть мышой когда уж очень припрет узнать какой же тип у этой переменной.
При наличии Assist-а — ничуть не более трудоёмко. А в отличие от чтения кода, редактирую я его практически всегда в IDE.
Наличие префиксов позволяет быстрее читать код. Присваивание (к примеру) разнотипных переменных бросается в глаза сразу, для этого не надо подводить мышку.
E>1) Простые типы, кроме чисел, в хорошем С++ коде -- редкость. E>Вот, например, какой "венгерский" префикс ты используешь для переменной типа std::vector< std::pair<int, std::string> >::itrrator?
iter. или даже it. Не нужно громоздить префикс полностью описывающий тип. Достаточно — чтобы он давал понятие о типе. Иначе получится майрософтовский lpctstrЧегоТоТам.
E>2) В нормальном С++ коде тип переменных обычно не важен. Случаи, когда таки важен, обычно такие, что хотя бы одна из двух переменных, а обычно обе -- классы какие-то.
вот этого аргумента я не понял.
E>Короче пользы мало, да ещё и для большинства переменных и не понятно что писать
Непонятно что писать — пиши наиболее общий префикс, я так думаю. Ну там к примеру, если это смартпоинтер на что-то — то просто sp будет достаточно. Уже неплохо, по крайней мере видно что код
spMyPtr = NULL;
реально вызывает delete (ну или уменьшает счётчик ссылок), а не просто обнуляет переменную.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[4]: правильный современный стиль кодирования на C++?
Здравствуйте, eao197, Вы писали:
E>Главная причина выбора lower_case вместо CamelCase (или camelCase, или Camel_Case) в том, что у меня глаза меньше устают при написании и чтении кода. И, как говорят мои коллеги, не только у меня.
у меня наоборот устают от lower_case
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Erop, Вы писали:
A>>т.е. JobMonitor а не MonitorJob (если речь о "мониторе" контролирующем какие-то задания) A>>если же Job является первичным то например BlowJob :) E>Это всё хорошо, и в целом просто сводится к рекомендации "изучите английский" :) E>Но в этом причудливом языке часто нельзя сказать что за часть речи мы видим. E>Вот, например, LinkMonitor -- это функция или класс :)
LinkMonitor — наблюдатель за ссылками
linkMonitor — подключить монитор
E>Да и вообще мне всё-таки нраыится правило "потроха с маленькой, морда с большой" :) E>>>А можно ли написать так, например:
class MyClass
E>>>{// Это я так понимаю, что ты хочешь такое?
E>>>public:
E>>> int Size() const{return size; }// А так можно?
E>>>};
A>>согласен, это частный случай предыдущего
Use the force. Если от нарушения правила становится читабельнее, нарушай. Если приходится часто нарушать, то вряд ли это хорошее правило.
E>Я бы всё-таки советовал тебе не заморачиваться на точном следовании расстановки скобок именно так. Предложи все популярные вменяемые паттерны, правда я бы запретил if, for, while и do while без скобок использовать. Чтобы такие косяки не сбивали:
for( int i = 1; i < size; i++ );
E> doItOneTime();
+1. Кроме else if, и кроме if(expr); else в макросах.
E>>>ИМХО в таком случае можно применять и венгерскую нотацию, если у тебя есть какой-то простой способ порождать на все типы префиксы, потому что иначе ты упрёшься
char const* name = getSomeName(); // правильно?char const* utf8Name = sSomeNameInLocalCharset(); // пожалуй, нет
std::wstring name = wsFromUtf8(utf8SomeName()); // OK
E>Про спец. комменты тоже правильно. Только ещё классно эти все комменты где-то регить.
MSVS вроде понимает //TODO, //FIXME и т. п. — отображает их в том же окошке, что и ошибки (предупреждения) компиляции.
Здравствуйте, Roman Odaisky, Вы писали:
RO>LinkMonitor — наблюдатель за ссылками RO>linkMonitor — подключить монитор
Так тоже можно. Суть состоит в том, что хочется по имени формально понимать класс это или функция E>>Да и вообще мне всё-таки нраыится правило "потроха с маленькой, морда с большой"
Просто регистр первой буквы мне нравится использовать для маркирования степени "внешности" идентификатора.
Так что приходится использовать C
Но это всё вопрос вкуса, конечно
RO>Use the force. Если от нарушения правила становится читабельнее, нарушай. Если приходится часто нарушать, то вряд ли это хорошее правило.
Ну так вот я и говорю, что, ИМХО, занафиг это не надо со скобками...
А если и надо, то есть несколько очевидных контекстов, где недо явно позволить, или, наоборот, запретить писать так илии наче.
RO>+1. Кроме else if, и кроме if(expr); else в макросах.
Ну я бы про else if "рекомендовал" бы использовать фигурные скобки, а для вложенных и для if без else "обязал" бы...
RO>
RO>char const* name = getSomeName(); // правильно?
RO>char const* utf8Name = sSomeNameInLocalCharset(); // пожалуй, нет
RO>std::wstring name = wsFromUtf8(utf8SomeName()); // OK
RO>
RO>MSVS вроде понимает //TODO, //FIXME и т. п. — отображает их в том же окошке, что и ошибки (предупреждения) компиляции.
А вдруг не MSVS?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Left2, Вы писали:
L>Правда. Бредово и громоздко. А поэтому — давайте не доводить идею до абсурда. Давайте писАть так: L>
L>Job jobMonika;
L>jobMonika = jobKlinton; // Пусть Моника почувствует себя президентом. Сразу видно что мы присваиваем переменной переменную того же типа.
L>
Очень хорошо, а что делать с объектами класса BestPathFinder?
Писать bestPathFinderFirstAttempt и bestPathFinderLastAttempt?
A>>так почему мы для одних типов делаем исключения, а для других нет? нотация не консистентна L>Честно говоря мне абсолютно пофигу консистентность Мне важна читабельность кода, ничего более.
Да? И где вот в таком идентификаторе bestPathFinderNextAttempt где префикс, а где имя?
И легко ли заметить чем он отличается от bestPathFinderNewAttempt?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: правильный современный стиль кодирования на C++?
Здравствуйте, Left2, Вы писали:
L>Наличие префиксов позволяет быстрее читать код. Присваивание (к примеру) разнотипных переменных бросается в глаза сразу, для этого не надо подводить мышку.
А зачем надо, чтобы это бросалось в глаза сразу?
ИМХО при нормальном дизайне нетирвиальные присваивания разнотипных переменных не компилируются
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: правильный современный стиль кодирования на C++?
Здравствуйте, CreatorCray, Вы писали:
E>>Ну тогда без ложной скромности: http://eao197.narod.ru/desc/lower_case.htm E>>Главная причина выбора lower_case вместо CamelCase (или camelCase, или Camel_Case) в том, что у меня глаза меньше устают при написании и чтении кода. И, как говорят мои коллеги, не только у меня. CC>Как по мне так camelCase читается гораздо естественнее. На lower_case у меня глаза ломаюццо
Просто интересно, как вы различаете индентификаторы вроде:
IllegalIndirection
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Left2, Вы писали:
L>iter. или даже it. Не нужно громоздить префикс полностью описывающий тип. Достаточно — чтобы он давал понятие о типе. Иначе получится майрософтовский lpctstrЧегоТоТам.
Да? А для вектора что писать? А для мапа? А для вктора умных указателей?
Я уже не говорю о хмурых шаблонах или классах с длинными именами. Например с таким: CPseudoEroupeanComplexLetterDescriptor
E>>2) В нормальном С++ коде тип переменных обычно не важен. Случаи, когда таки важен, обычно такие, что хотя бы одна из двух переменных, а обычно обе -- классы какие-то. L>вот этого аргумента я не понял.
Ну в каком контексте надо знать тип переменной, а не её семантику?
L>
L>spMyPtr = NULL;
L>
L>реально вызывает delete (ну или уменьшает счётчик ссылок), а не просто обнуляет переменную.
ИМХО намного лучше, чтобы писать надо было так:
MyData.Delete();
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: правильный современный стиль кодирования на C++?
E>Очень хорошо, а что делать с объектами класса BestPathFinder? E>Писать bestPathFinderFirstAttempt и bestPathFinderLastAttempt?
bpfFirstAttempt и bpfLastAttempt
A>>>так почему мы для одних типов делаем исключения, а для других нет? нотация не консистентна L>>Честно говоря мне абсолютно пофигу консистентность Мне важна читабельность кода, ничего более. E>Да? И где вот в таком идентификаторе bestPathFinderNextAttempt где префикс, а где имя? E>И легко ли заметить чем он отличается от bestPathFinderNewAttempt?
bpfNextAttempt и bpfNewAttempt — вполне себе неплохо отличаются. Префикс должен быть маленкими буквами и не больше 3-4 букв.
L>>iter. или даже it. Не нужно громоздить префикс полностью описывающий тип. Достаточно — чтобы он давал понятие о типе. Иначе получится майрософтовский lpctstrЧегоТоТам. E>Да? А для вектора что писать? А для мапа? А для вктора умных указателей?
Для любого массива или вектора — arr (поскольку у него семантика массива). Для map и multimap — map. Для set и multiset — set.
Не надо усердствовать и впихнуть всю информацию о типе в префикс Достаточно самого общего понятия.
E>>>2) В нормальном С++ коде тип переменных обычно не важен. Случаи, когда таки важен, обычно такие, что хотя бы одна из двух переменных, а обычно обе -- классы какие-то. L>>вот этого аргумента я не понял. E>Ну в каком контексте надо знать тип переменной, а не её семантику?
Вот! Так и я про то же! Префикс должен описывать СЕМАНТИКУ а не весь тип. Чтобы можно было понять — массив это или указатель. К примеру, глядя на
arrFoo = arrBar; // При этом arrFoo может быть вектором, а arrBar - boost::array, или чем-то ещё что работает как массив.
я сразу могу понять что здесь копируется массив, и это возможно длительная и ресурсоёмкая операция. а вот здесь:
pFoo = pBar;
я сразу вижу что это — копирование двух указателей, операция дешёвая и никогда не выбрасывающая исключение.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[6]: правильный современный стиль кодирования на C++?
Здравствуйте, eao197, Вы писали:
E>Просто интересно, как вы различаете индентификаторы вроде: E>
E>IllegalIndirection
E>
camelCase и gcc_style требуют разных шрифтов. Это понятно.
Для первого нужен моноширинный шрифт, который всегда с засечками (как, например, в примерах кода на КУВТе )
Для второго можно использовать более компактный Arial, опять же и идентификаторы подлиннее будут.
Но мне традиционно (ещё с FORTRAN'а) нравится моноширинный шрифт -- видно какая же из строчек тут длинная на самом деле
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: правильный современный стиль кодирования на C++?
Здравствуйте, Left2, Вы писали:
L>bpfNextAttempt и bpfNewAttempt — вполне себе неплохо отличаются. Префикс должен быть маленкими буквами и не больше 3-4 букв.
Очень хорошо, а для классов BestStepFinder и BestStrokeFinder?
Мало того, как не запутаться, вот как по префиксу ssc восстановить AsianLangs::SimpleScriptCharater, например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Left2, Вы писали:
L>Для любого массива или вектора — arr (поскольку у него семантика массива). Для map и multimap — map. Для set и multiset — set. L>Не надо усердствовать и впихнуть всю информацию о типе в префикс Достаточно самого общего понятия.
1) А зачем знать что MyTasks -- это set?
2) А по использованию не видно?
L>Вот! Так и я про то же! Префикс должен описывать СЕМАНТИКУ а не весь тип. Чтобы можно было понять — массив это или указатель. К примеру, глядя на L>
L>arrFoo = arrBar; // При этом arrFoo может быть вектором, а arrBar - boost::array, или чем-то ещё что работает как массив.
L>
Имхо лучше вместо Foo и Bar выбрать понятные имена. И разу станет ясно долго это копируется или не очень
Ещё, кстати, интересно узнать как ты нотируешь параметры шаблона
Ну, там, например, есть у тебя шаблон Array с параметром TElement. Вот ты переменной типа TElement какой префикс даёшь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
L>>bpfNextAttempt и bpfNewAttempt — вполне себе неплохо отличаются. Префикс должен быть маленкими буквами и не больше 3-4 букв.
E>Очень хорошо, а для классов BestStepFinder и BestStrokeFinder? :) E>Мало того, как не запутаться, вот как по префиксу ssc восстановить AsianLangs::SimpleScriptCharater, например? :)
Это уже извращение. И bpf — извращение. Чтобы понять, что xxxNextAttempt — экземпляр класса BestPathFinder, можно подвести к нему мышку (в IDE). Нужно называть nextAttempt, или finderNextAttempt, если тот факт, что это класс, сильно меняет дело. Суть венгерской нотации не в lpsz, и даже не в irgch, а всего лишь в том, что суть переменной отправляется в начало идентификатора. Любой уважающий себя разработчик упомянет в имени переменной типа char const * тот факт, что она UTF-8, «венгр» просто отправит этот префикс в начало. Это strlen(nameInUtf8) vs. cOfUtf8(utf8Name).
С венгерской нотацией, кстати, можно избавиться от префиксов get/set. Например:
Re[2]: правильный современный стиль кодирования на C++?
От:
Аноним
Дата:
20.09.07 10:01
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Тебе это надо не тут обсуждать, а с теми, кто по нему жить будет. А>Нету "правильного современного стиля кодирования".
Полностью согласен с Вами.
К тому же кто будет определять "правильность" и "современность" стиля кодирования?
