Здравствуйте, antropolog, Вы писали:
A>помимо нормальных ide код может оказаться в блокноте, вьювере, письме, распечатан, передан по скайпу, запосчен на форум и стековерфлоу.
Проблемы индейцев шерифа не волнуют. A>Чем m_ помешал-то?
Потому-что номенклатура.
Здравствуйте, bnk, Вы писали:
bnk>Наверное чтобы в дебаггере было удобно смотреть (возможно что в вотч эти самые x, y, a, b добавлены) bnk>Хотя да, общая неряшливось присутствует. Явно у чувака с чувством прекрасного напряженка.
Зато нам удобно смотреть — видим большую функцию на пол экрана — а по сути в ней ничего нет.
V>>Да и нотации типа m_, в новом коде я не приемлю, уже есть нормальные IDE.
bnk>"m_" ничем не хуже "_" разве что на один символ длиннее, к тому же там mfc bnk>Про поддержку IDE — она позволяет забыть про m_lpstr (венгерскую нотацию), но не про члены класса.
ИМХО номенклатура. У меня локальные переменные и члены класса по разному подсвечиваются.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Шахтер, Вы писали:
Ш>>Вообщем, начинать надо с проработки базовых вещей. Проект сделан неряшливо. И я думаю, что вина здесь не только автора данного кода.
S>А что Вы скажете про код из опенсорсов?
Это зависит от проекта, конечно же. Скажем boost сделан достаточно хорошо. Многие open source проекты, однако, сделаны довольно плохо. Скажем, в том же Linux е нет нормальной дисциплины имен, что для крупного C проекта просто необходимо.
Здравствуйте, GhostCoders, Вы писали:
GC>Данный код был написан моим сотрудником. Мне этот код не нравится, но он мне отвечает что я субъективен и его код неплох.
Здравствуйте, vpchelko, Вы писали:
V>Здравствуйте, bnk, Вы писали:
bnk>>Тогда конечно можно и без "_". У меня одиниково. А как это в студии настроить?
V>Я использую VA для таких целей.
Понятно что VA.
Я просто что-то не знаю у него такой настройки, чтобы переменные и мемберы показывать по-разному?
Здравствуйте, bnk, Вы писали:
bnk>Понятно что VA. bnk>Я просто что-то не знаю у него такой настройки, чтобы переменные и мемберы показывать по-разному?
там в Fonts & Colors есть опция Local symbols in bold ( правда у меня достаточно старая версия, не знаю как в новых )
Здравствуйте, antropolog, Вы писали:
A>Здравствуйте, bnk, Вы писали:
bnk>>Понятно что VA. bnk>>Я просто что-то не знаю у него такой настройки, чтобы переменные и мемберы показывать по-разному?
A>там в Fonts & Colors есть опция Local symbols in bold ( правда у меня достаточно старая версия, не знаю как в новых )
А понял про что ты, пасиб. В новых так же. Просто тогда будет разный шрифт — мне это не нравится
Здравствуйте, landerhigh, Вы писали:
L>>>У вас coding conventions вообще есть? где оформленный заголовок с именем файла, автором, датой создания, названием проекта? A>>для всего этого есть система контроля версий.
L>Иногда, читай вероятность этого стремится к единице, информация об истории может потеряться. Происходит это при переезде на другую систему контроля версий или при просто копипасте файла из одного места в другое.
A>>есть смысл разве что писать копирайт, и то не очень-то нужно.
L>Заголовок с копирайтом позволяет сразу понять, что это, откуда оно взялось и кто в этом виноват. Даже когда работаешь из движущегося поезда без подключения к системе. Но я не настаиваю, хозяин-барин, это и правда не так уж и важно.
тут есть два противоположных подхода —
ориентироваться на то что у тебя практически всегда есть самые современные инструменты, и использовать их,
или ориентироваться на то что однажды у тебя этих инструментов не будет, и по этому использовать эти замечательные инструменты по минимуму.
кажется что для максимальной продуктивности надо оптимизировать именно повседневную работу, а не те редкие случаи когда тебе пару раз в год надо поработать оффлайн или без VPN.
потери истории изменений и т.п. случаются, но такое бывает ну очень редко.
L>Комментарий должен быть. Он должен обосновывать необходимость этого холдера, в т.ч. содержать объяснение, почему аффтар не стал использовать умный указатель вместо этого, а также рассказывать, с какого такого бодуна объект вдруг стал называться ссылкой и зачем ему может понадобиться внешний удалятор. Любое инженерное решение должно быть обосновано. У меня сразу возникает вопрос — зачем нужно убивать объект, который является членом класса, неким внешним функтором. Если бы автор потрудился это описать в комментарии, он бы примерно на полпути, скорее всего, догадался бы, что инкапсуляция — не просто красивое слово, которое непонятно как правильно транслителировать на русском языке, а весьма правильный подход к проектированию подобных классов. Ну или бы четко описал, почему это должно быть сделано именно так, а не иначе.
это и есть умный указатель. код очевидно писался для С++03, по этому unique_ptr с кастомным делитером нету.
зачем используется функция DeleteObj — наверное это понятно из ее реализации. может там какой-то отладочный код, или возможность подключения глобального кастомного аллокатора.
и я совершенно не согласен с тем что любое инженерное решение должно быть обосновано комментариями.
многие паттерны и идиомы общеизвестны, легко распознаются на глаз, и потому в комментариях не нуждаются.
L>>>Все то же самое плюс — почему в одном заголовочном файле объявлено более одного класса? A>>а почему бы и нет? особенно если классы используются вместе L>В итоге все классы в программе используются вместе так или иначе. Это не повод всех их запихивать в один файл.
есть существенная разница между "запихнуть всё в 1 файл", и "запихнуть несколько в 1 файл".
требование "1 файл — 1 класс" звучит так же экстремально как и попытка запихнуть всю программу в 1 файл.
Здравствуйте, RonWilson, Вы писали:
RW>этого сотрудника не Александром случаем зовут?
Нет, это Юра Лазарев.
Динозар еще тот. Он еще в 80-х на Фортране что-то писал.
Анархист и вообще, человек со странностями (не только в коде).
Оказывается, он про do{ }while(false) у МакКонела прочитал.
Бить функции на более мелкие — категорически отказывается, типа для него это плохо,
приходиться "скакать как козлу" с метода на метод, непонятным код становиться.
Заменить стиль линий (константа 1 в нескольких местах в этом коде) на const int TMP_STYLE_LINE = 1; согласился сделать только после часа дискуссий (!).
При этом мы в какие дебри только не лезли, он и в метафизику какую-то забрел и черт знает еще что (это когда я ему пытался доказать что магические константы — это зло).
При этом, он обвиняет меня в том, что я невнимательно прочитал "МакКонела" ("Совершенный код"),
а он прочитал его очень внимательно, результат прочтения данной книжки — это его выше приведенный код.
Я спрашиваю его — а что МакКонел рекомендует использовать магические константы и методы по 1000 строк в длину?
А он на какие-то неправильные аналогии выходит, например, "муж в квартире чинит свет. Летят стружки,
а жена его пилит. А муж в интересах жены делает". — поэтому у него в коде много балласта,
отладочной информации, которая портит форматирование и т.д.
Я совершенно серьезно, не шучу.
Вообще непробиваемый. С ним можно спорить и час и два и весь день. Толку почти 0.
Упрямый. Систему контроля версий (у нас GIT), не любит. Его перл это "это гит виноват".
Можно ему дать какую-нидубь книжку, например, "Рефакторинг" Мартина Фаулера — он ее прочтет, а делать все будет по-старому.
Могу составить список замечаний к его коду — только все равно, он его исправлять не будет.
Я уже махнул на него рукой — код ревью делать бессмысленно.
Поэтому он не работает в основной команде, а одиночкой над своим проектом.
Проект у него небольшой, в стиле "сделали" проект, сдали и забыли. Да и ничего там особо секретного нет, поэтому я выложил его тут как есть.
Никто туда лезть не собирается.
Может как-нибудь видео дискуссии с ним на видео сниму — круче Петросяна будет.
С ним спорить вообще невозможно — у меня некоторые сотрудники хватаются за голову.
Приемами демагогии владеет он отлично. Причем выходит так — что он один пишет отличный код,
"внимательно" прочитал "Совершенный Код" МакКонелла, а мы читали только поверхностно это книжку, и толком ее-то не знаем.
Еще типа что пишем одни только "обвертки", которые ничего не делают, много куча коротких функций,
которые тоже ничего не делают, только вызывают другие функции и т.д.
есть у меня такой знакомый.
так у меня когда с коллегами аргументы заканчивались — мы лезли на форум, задавали вопрос, и потом мнение большинства приводили как пример.
так он отвечал что-то типа "так они все идиоты, кого вы мне в пример приводите?"
в итоге, все забили ему что-либо объяснять...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, GhostCoders, Вы писали:
RW>>этого сотрудника не Александром случаем зовут? GC>Нет, это Юра Лазарев.
был у меня на оочень данвней работе подобный, читаю Ваш пост как про него почти. Единственное, что помогло вытащить как клеща наружу в реальный мир (не, не новомодные вещи какие-то) этого кренделя, так чуть подтолкнуть, сделать почву в собственных сомнениях, а потом он сам старался передовое отдать мне, а сам возвращался в свой погребок. Есть такие люди, с ними приходится работать. Плакать не надо, люди разные.
Здравствуйте, Abyx, Вы писали:
A>тут есть два противоположных подхода - A>ориентироваться на то что у тебя практически всегда есть самые современные инструменты, и использовать их, A>или ориентироваться на то что однажды у тебя этих инструментов не будет, и по этому использовать эти замечательные инструменты по минимуму.
A>кажется что для максимальной продуктивности надо оптимизировать именно повседневную работу, а не те редкие случаи когда тебе пару раз в год надо поработать оффлайн или без VPN.
Мне офлайн работать приходится весьма регулярно.
A>потери истории изменений и т.п. случаются, но такое бывает ну очень редко.
Достаточно одного раза в 10 лет, и каждый раз придется заново проводить расследование "откуда вообще мы это взяли".
A>это и есть умный указатель. код очевидно писался для С++03, по этому unique_ptr с кастомным делитером нету.
Каким местом это умный указатель? Ты повнимательнее посмотри. Если это и умный указатель, то кривой на всю голову.
И еще, сегодня 2014, С++03 совершенно неочевиден.
A>зачем используется функция DeleteObj — наверное это понятно из ее реализации. может там какой-то отладочный код, или возможность подключения глобального кастомного аллокатора.
Еще раз, DeleteObj применяется к значению, а не указателю. Это либо самый страшный случай нарушения принципов ООП, который я видел в этом году, либо что-то чрезвычайно хитрое. В обоих случаях такое решение должно быть обосновано, и обосновано именно здесь.
A>и я совершенно не согласен с тем что любое инженерное решение должно быть обосновано комментариями.
Ты можешь не соглашаться, но это не делает тебя правым. Я требую обосновывать абсолютно все классы. Без исключения.
В частности и особенно те, которые очень похожи на что-то стандартное.
И знаешь что? Во многих случаях аффтар подобного говнокода, со скрипом рожая камент (каменты писать некогда, копать нужно), где-то на третьей строчке понимает, что написал какую-то фигню, и что все это можно заменить стандартным(бустовским) shared_ptr, например.
A>многие паттерны и идиомы общеизвестны, легко распознаются на глаз, и потому в комментариях не нуждаются.
Тут распознается лишь один паттерн.. и это вовсе не хорошие новости.
L>>>>Все то же самое плюс — почему в одном заголовочном файле объявлено более одного класса? A>>>а почему бы и нет? особенно если классы используются вместе L>>В итоге все классы в программе используются вместе так или иначе. Это не повод всех их запихивать в один файл.
A>есть существенная разница между "запихнуть всё в 1 файл", и "запихнуть несколько в 1 файл". A>требование "1 файл — 1 класс" звучит так же экстремально как и попытка запихнуть всю программу в 1 файл.
Здравствуйте, GhostCoders, Вы писали:
GC>Нет, это ***. GC>При этом, он обвиняет меня в том, что ..., Вообще непробиваемый ... Упрямый ... GC>Я уже махнул на него рукой ... Поэтому он не работает в основной команде, а одиночкой над своим проектом GC>С ним спорить вообще невозможно — у меня некоторые сотрудники хватаются за голову. Приемами демагогии владеет он отлично ... GC>Еще типа что пишем одни только "обвертки", которые ничего не делают...
Как-то не комильфо... Раскрываете имена, да и не о C++ совсем. Если всё так плохо, почему он ещё работает в компании?
GC> Бить функции на более мелкие — категорически отказывается, типа для него это плохо, приходиться "скакать как козлу" с метода на метод, непонятным код становиться. Заменить стиль линий (константа 1 в нескольких местах в этом коде) на const int TMP_STYLE_LINE = 1; согласился сделать только после часа дискуссий (!).
Спорить о таких вещах странно: не стоит тратить нервную энергию на то, что можно описать в корпоративном стандарте кодирования..
Здравствуйте, GhostCoders, Вы писали:
GC>Оказывается, он про do{ }while(false) у МакКонела прочитал.
в целом, я положительного мнения об этом труде
решил найти подтверждения:
в главе 16 Циклы можно найти параграф "Аномальные циклы с выходом", где демонстрируется замена "плохой практики (С++)"
goto Start:
while ( expression ) {
// Делаем что-то.
...
Start:
// Делаем что-то еще.
...
}
на православный лучший вариант
while ( true) {
Блоки перед и после break поменяны местами
// Делаем что-то еще.
...
if ( !( expression ) ) {
break;
}
// Делаем что-то.
...
}
то есть показано, как заменить цикл со странным входом на обычный цикл с break выходом. подчеркну, что здесь описываются циклы (то есть когда подразумевается наличие нескольких итераций)
в следующей же главе обсуждается goto и не упоминается применение "аномальных" циклов, как альтернативы. даже название уже намекает, что использовать их нежелательно
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, _Dreamer, Вы писали:
N>встроить линтер на прекоммит.
N>Так и называется, "Линтер"? В svn такое есть?
Уже сказали про cpplint, по факту это может быть что угодно для проверки стиля.
Хоть clang-format (http://clang.llvm.org/docs/ClangFormatStyleOptions.html)
У cpplint действительно есть false-positive срабатывания, но с этим можно жить, а можно его допиливать.
Так что это можно прикрутить не только на svn.
Здравствуйте, zaufi, Вы писали:
Z>как по мне, лучше тим лиду подписаться на коммиты и бегло просматривать их, выдавая люлей коммитерам нарушающим стиль. и параллельно с этим проводить code review, на которых мемберы учатся т.ч. правильному стилю.
Это может быть куча времени, к сожалению. А скрипт не устает и не отвлекается, как раз для него работа.
К тому же, Вы предлагаете оценивать коммиты постфактум?
Именно этого я бы и не стал допускать.
Потому что по разным причинам коммит может так и остаться в ненадлежащем виде.
А вот тупо не дать закоммитить без -n уже гораздо действеннее, не смотря на некоторые неудобства.
