Здравствуйте, MasterZiv, Вы писали:

MZ>Это плохо, однако!
вам и правда необходим тег "сарказм"?

aik>>>>лютый трындец. write-only.
BFE>>>Ничего подобного. Бывает много, много хуже. В коде, прошу заметить, всего одна глобальная переменная и числа с плавающей точкой сравниваются через == только в ассёртах.
O>>Угу, код конечно с первого взгляда выглядит пугающе, но если вчитаться — все это без труда можно отрефакторить.
ЮЛ>Кстати, ловлю на слове. Давайте покажите, как этот код рефакторится, да еще без труда.
ЮЛ>Докажите, что вы не трепло, в отличие от большинства здесь кидающихся бандерлогов.
Переводя на вашу лексику одну известную поговорку — если выйдя на улицу вы встретили бандерлога — значит вы встретили бандерлога. Если же вокруг вас все бандерлоги — значит вы бандерлог.
Весь код рефакторить не буду, мне еще есть чем заняться, но могу показать как я бы начал делать декомпозицию, даже не вникая пока в весь алгоритм. К примеру берем одну из самых длинных ф-ий — CSewingDlg::PseudoProcessAcceptedData. ВИдим цикл в самом начале. Видим коммент //PARSING TEST. Выносим весь этот цикл в ф-ю с название ParsingTest().
Видим следующий цикл, откоменченный как optimizing vertices (sorting). С ним сложнее — потому посмотрим что у него внутри. Натыкаемся на for (size_t j = 0; j < LineEnds.size(); j++). Смотрим что делает. А делает он подготовку концов отрезков, или чтото типа того. Потому пишем такую функцию

void PrepareLineEnds(std::vector<Edge>& LineEnds, std::vector<LineEnd> &EndsX)
{
        for (size_t j = 0; j < LineEnds.size(); j++)
        {
            //LineEnds[j].curve = 0;
            LineEnds[j].link_index = LineEnds[j].node_index1 = LineEnds[j].node_index2 = 0;
            LineEnds[j].back_count = LineEnds[j].back_index1 = LineEnds[j].back_index2 = 0;
            double x1 = LineEnds[j].x1;
            double y1 = LineEnds[j].y1;
            EndsX.push_back(LineEnd(x1, y1, (j + 1)));      // (ordered from 1!)
            double x2 = LineEnds[j].x2;
            double y2 = LineEnds[j].y2;
            EndsX.push_back(LineEnd(x2, y2, (j + 1)));      // (ordered from 1!)
        }

        std::sort(EndsX.begin(), EndsX.end(), LineEnd::SortedYpostX);

        for (size_t j = 0; j < EndsX.size(); j++)
        {
            size_t edge = EndsX[j].index;
            if (edge == 0) continue;
            if (LineEnds[edge - 1].back_count++ == 0)
                LineEnds[edge - 1].back_index1 = (j + 1);
            else LineEnds[edge - 1].back_index2 = (j + 1);
        }
}

...код под if (ii == 0 && ii0==1) ниче не делает — потому его тут нету. Это тоже не идеальная декомпозиция, но для первой итерации рефакторинга сойдет. Далее по тексту видим комент PARSING SORT — видимо последующий код можно выделить в ParsingSort(), но как я уже писал — я не подрядился перелопачивать весь ваш код, тут работы на несколько дней, а не на 10 минут. Вообще всю эту гиперфункцию PseudoProcessAcceptedData лучше вынести в отдельную сучность-класс, назвать ее AcceptrdDataPseudoProcessor а все что я написал выше, и что не написал — сделать ее методами. Про мелочи типа именования переменных и т.п. я уж не говорю (ii0 — это жесть). Ваш код для proof-of-concept вполне годный, но для продакшена его нужно переделать. К счастью его и _можно_ переделать, что бывает далеко не всегда.

Здравствуйте, MasterZiv, Вы писали:

MZ>Здравствуйте, niXman, Вы писали:

X>>в общем, довольно не плохо с первого взгляда, видал и похуже %)
X>>"порадовало" использование запятой:

MZ>Это плохо, однако!

Так, а чем плохо использование запятой или вложенных тернарных операций, можете ясно ответить? Может, вам стоит написать Страустрапу, чтобы запретить запятую?

Здравствуйте, ononim, Вы писали:

O>Весь код рефакторить не буду, мне еще есть чем заняться, но могу показать как я бы начал делать декомпозицию, даже не вникая пока в весь алгоритм. К примеру берем одну из самых длинных ф-ий — CSewingDlg::PseudoProcessAcceptedData. ВИдим цикл в самом начале. [] назвать ее AcceptrdDataPseudoProcessor а все что я написал выше, и что не написал — сделать ее методами. Про мелочи типа именования переменных и т.п. я уж не говорю (ii0 — это жесть). Ваш код для proof-of-concept вполне годный, но для продакшена его нужно переделать. К счастью его и _можно_ переделать, что бывает далеко не всегда.

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

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

Теперь с точки зрения разработки. Допустим, я пишу локальный цикл, еще не зная, насколько он будет полезен в окончательном алгоритме. Вы рекомендуете мне сразу оформлять его в виде метода класса, или подождать, пока код устоится? Если я его оформляю в метод, то 1) он отрывается визуально от контекста (а именно из контекста я решаю о его полезности), мне надо проделать лишнюю техническую работу по заведению метода, разрешить вопросы с переменными и т.д. В результате я выбрасываю этот метод.
Или же просто я пишу цикл по месту алгоритма, оцениваю его и при желании правлю или удаляю, никуда не перемещаясь. Результат получается тот же, но без лишних хлопот.

Поскольку логика алгоритма в основном последовательная, то нет большой беды в раздувании функции, — при исследовании каждого блока необходим лишь ближайший участок кода. Кажется, и у МакКонелла говорится об том же, что подобная последовательность кода не обязательно требует формального ограничения числа строк.

Если вернуться к аналогии с Войной и Миром, то заведение отдельных методов для мелких частей алгоритма подобно простановке названий параграфов в оглавлении длинной главы. Насколько это будет полезно? Кто читает главы по параграфам?
К слову сказать, те 8 подфункций, к которым я прибег, в этой аналогии приобретают смысл страниц — чисто технический прием для преодоления иэбыточного объема.

ЮЛ>Но в любом случае это насилие над кодом, реально не приносящее особых выгод. Слишком искусственный подход, еще немного, и получится обертка каждой строки. Я ищу семантический (осмысленный) способ рефакторинга. Скажем, если бы можно было придумать определенную алгебру узлов, я взял бы ее за основу класса безоговорочно.
Это не насилие над кодом, это дело тренировки восприятия + "дефолтовые настройки" этих особенностей у большинства людей. Большинство людей не могут держать в активной обработке большое количество сущностей без разделения их на иерархии. Да, можно ценой многолетней практики научится это делать, расширив количество одновременно обрабатываемых мозгом сущностей. И даже для такого человека работа с большим количеством однаранговых entities может быть эффективнее нежели работа над иерархией с "подгрузкой" в сознание каждого уровня по мере необходимости. Но надо отдавать себе отчет что код вы пишете не для себя, а для дяди, который вам платит за него денежку. Потому мнение этого дяди как минимум нужно принимать в расчет, иначе дядя вас может уволить, как видимо и произошло.
А дальше вопрос плавно перетекает в плоскость как вас можно было замотивировать сделать нужные изменения. Я думаю это тоже достаточно несложно можно было сделать, и то что этого не смог сделать менеджер — признак его непрофессионализма. Но методы мотивации вас лежат в не-технической плоскости, потому они скучны и вообще офтопны в этом разделе

Здравствуйте, ononim, Вы писали:

ЮЛ>>Но в любом случае это насилие над кодом, реально не приносящее особых выгод. Слишком искусственный подход, еще немного, и получится обертка каждой строки. Я ищу семантический (осмысленный) способ рефакторинга. Скажем, если бы можно было придумать определенную алгебру узлов, я взял бы ее за основу класса безоговорочно.
O>Это не насилие над кодом, это дело тренировки восприятия + "дефолтовые настройки" этих особенностей у большинства людей. Большинство людей не могут держать в активной обработке большое количество сущностей без разделения их на иерархии. Да, можно ценой многолетней практики научится это делать, расширив количество одновременно обрабатываемых мозгом сущностей. И даже для такого человека работа с большим количеством однаранговых entities может быть эффективнее нежели работа над иерархией с "подгрузкой" в сознание каждого уровня по мере необходимости. Но надо отдавать себе отчет что код вы пишете не для себя, а для дяди, который вам платит за него денежку. Потому мнение этого дяди как минимум нужно принимать в расчет, иначе дядя вас может уволить, как видимо и произошло.
O>А дальше вопрос плавно перетекает в плоскость как вас можно было замотивировать сделать нужные изменения. Я думаю это тоже достаточно несложно можно было сделать, и то что этого не смог сделать менеджер — признак его непрофессионализма. Но методы мотивации вас лежат в не-технической плоскости, потому они скучны и вообще офтопны в этом разделе

Ну хорошо если +, а если -? Если "дефолтные настройки" не помогают в разработке? Вы такое исключаете?
Откуда берутся эти настройки? Не догматические ли это сущности?
Вы пытаетесь меня (себя) убедить в том, что бездумное заискивание благосклонности этого дяди (денюшки, какой аргумент!) важнее цели разработки?
Так что все же вы скажете, 200 строк на функцию — это табу, или признаете возможные исключения из правил (которые я вовсе не подвергаю сомнению с общей точки зрения разумности, вообще — но не в частности).

ЮЛ>>>Но в любом случае это насилие над кодом, реально не приносящее особых выгод. Слишком искусственный подход, еще немного, и получится обертка каждой строки. Я ищу семантический (осмысленный) способ рефакторинга. Скажем, если бы можно было придумать определенную алгебру узлов, я взял бы ее за основу класса безоговорочно.
O>>Это не насилие над кодом, это дело тренировки восприятия + "дефолтовые настройки" этих особенностей у большинства людей. Большинство людей не могут держать в активной обработке большое количество сущностей без разделения их на иерархии. Да, можно ценой многолетней практики научится это делать, расширив количество одновременно обрабатываемых мозгом сущностей. И даже для такого человека работа с большим количеством однаранговых entities может быть эффективнее нежели работа над иерархией с "подгрузкой" в сознание каждого уровня по мере необходимости. Но надо отдавать себе отчет что код вы пишете не для себя, а для дяди, который вам платит за него денежку. Потому мнение этого дяди как минимум нужно принимать в расчет, иначе дядя вас может уволить, как видимо и произошло.
O>>А дальше вопрос плавно перетекает в плоскость как вас можно было замотивировать сделать нужные изменения. Я думаю это тоже достаточно несложно можно было сделать, и то что этого не смог сделать менеджер — признак его непрофессионализма. Но методы мотивации вас лежат в не-технической плоскости, потому они скучны и вообще офтопны в этом разделе

ЮЛ>Ну хорошо если +, а если -? Если "дефолтные настройки" не помогают в разработке? Вы такое исключаете?
ЮЛ>Откуда берутся эти настройки? Не догматические ли это сущности?
Все люди разные. Дефолтовые настройки большинства мешают лично вашей разработке. Но код вы пишете не для себя, а для того самого большинства. Потому хотябы из соображений вежливости — перед передачей своего кода большинству — приведите его в тот вид, который оно сможет прожевать.

ЮЛ>Вы пытаетесь меня (себя) убедить в том, что бездумное заискивание благосклонности этого дяди (денюшки, какой аргумент!) важнее цели разработки?
Я не пытаюсь убеждать, я констатирую реальность Если ваша цель разработка — разрабатывайте как вам хочется, если ваша цель заработать денег дяде, чтобы он часть этих денег потом отдал вам — придется учитывать желания других. Кроме говоря про разработку — не забывайте что разработку эту ведете не вы один. Ну если вы ее собираетесь вести один — это ваше желание может не совпасть с желанием дяди. А дядя это не убеждения, дядя — это реальность. Иначе велком в шаровару — пишите софт сами, и сами его и продавайте.

ЮЛ>Так что все же вы скажете, 200 строк на функцию — это табу, или признаете возможные исключения из правил (которые я вовсе не подвергаю сомнению с общей точки зрения разумности, вообще — но не в частности).
У меня есть одно правило в жизни — не иметь правил в жизни Нужно смотреть каждую ситуацию в отдельности исходя из общих соображений оптимизации трудозатрат для разработки и поддержки продукта. В данном случае код можно и нужно побить на кусочки. Кстати можете если не лень провести длительный эксперимент — через пару месяцев (а лучше дольше) отсутствия работы с этим кодом отдайте его кому нить, и попросите внести какой нить мелкий баг. Ну или попробуйте модифицировать условия задачи. Потом приведите код в нужный вид.

Здравствуйте, ononim, Вы писали:

O>Все люди разные. Дефолтовые настройки большинства мешают лично вашей разработке. Но код вы пишете не для себя, а для того самого большинства. Потому хотябы из соображений вежливости — перед передачей своего кода большинству — приведите его в тот вид, который оно сможет прожевать.
O>Я не пытаюсь убеждать, я констатирую реальность Если ваша цель разработка — разрабатывайте как вам хочется, если ваша цель заработать денег дяде, чтобы он часть этих денег потом отдал вам — придется учитывать желания других. Кроме говоря про разработку — не забывайте что разработку эту ведете не вы один.

Видимо, вы не поняли обстоятельств. Код этот находился еще в разработке. Разработка прерывалась из-за резких поворотов манагера — он то хотел обслуживать заказчиков, то не хотел. Меня он оставил на самоокупаемость. Вы пробовали такой способ работы, да еще с отечественным заказчиком? Разумеется, никакой команды не было. Да если бы и была, с этой командой я потерял бы только больше времени и возможно не смог выполнить даже сделанного.

O>Ну если вы ее собираетесь вести один — это ваше желание может не совпасть с желанием дяди. А дядя это не убеждения, дядя — это реальность. Иначе велком в шаровару — пишите софт сами, и сами его и продавайте.
Кто вам сказал, что я собираюсь / собирался работать один? Вы всегда пользуетесь домыслами?

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

O>Кстати можете если не лень провести длительный эксперимент — через пару месяцев (а лучше дольше) отсутствия работы с этим кодом отдайте его кому нить, и попросите внести какой нить мелкий баг. Ну или попробуйте модифицировать условия задачи. Потом приведите код в нужный вид.
Давайте лучше я внесу баг в ваш самый лучший код. И вы его моментально найдете, через 2 месяца. Пустые заклинания.
Кстати, я такой опыт фактически уже провел — тот исходный код, что вы невзлюбили, уже существует в стадии второго и успешного релиза, с новым алгоритмом внешнего контура, который я даже не надеялся написать.

Здравствуйте, Юрий Лазарев, Вы писали:

ЮЛ>Здравствуйте, alexb1980, Вы писали:

A>>Здравствуйте, GhostCoders, Вы писали:

GC>>>Данный код был написан моим сотрудником. Мне этот код не нравится, но он мне отвечает что я субъективен и его код неплох.

A>>Я конечно особо не вникал в логику работы кода, но помоему тут целым namespace попахивает (вынести из этого dlg в классы логику) и таким образом "разгрузить" диалог.

ЮЛ>Да то, что диалог совмещен с алгоритмом, пусть вас не смущает. Это всегда можно разделить, но сейчас это несущественно. Разговор о самой длинной функции — как ее рефакторить? Говорят, без труда. Дайте просто идею, с чего начать. Без полной переработки — она не нужна, поезд уже ушел.

ЮЛ>(Манагеру надо было выкладывать только эту одну функцию, а не весь почти проект. Если уж цепляться ко всему проекту в целом, то надо заметить, что отдельные моменты — это установки фирмы, а не мои изобретения. И я не хочу их защищать или поносить, мне они безразличны).

Ну я вижу что самая длинная функция:
void CSewingDlg::PrepareContoursMakeEquidistants(...)
поробуйте разбить задачу на подзадачи ещё раз (разрабатывая рисование графических примитивов вы это уже сделали). Можно выделетить подзадачи в этом методе на основе private или protected методов.

Но кое-что ещё, я невооружённым глазом вижу что код не пройдёт коде ревью (если на проекте оно есть, но у вас я так понял манагер не доволен), просто видно что код messy т.е. очень много lines of code просто комменты // /**/

Здравствуйте, alexb1980, Вы писали:
A>Ну я вижу что самая длинная функция:
A> void CSewingDlg::PrepareContoursMakeEquidistants(...)
A> поробуйте разбить задачу на подзадачи ещё раз (разрабатывая рисование графических примитивов вы это уже сделали). Можно выделетить подзадачи в этом методе на основе private или protected методов.

A> Но кое-что ещё, я невооружённым глазом вижу что код не пройдёт коде ревью (если на проекте оно есть, но у вас я так понял манагер не доволен), просто видно что код messy т.е. очень много lines of code просто комменты // /**/

Вернее самая длинная функция скорее.
int CSewingDlg::PseudoProcessAcceptedData(...)

О, даже когда фунция кочается не видно в MFC вроде можно разделять так:
////////////////////////////////////////////////////////////////////////

Здравствуйте, alexb1980, Вы писали:

A> поробуйте разбить задачу на подзадачи ещё раз (разрабатывая рисование графических примитивов вы это уже сделали). Можно выделетить подзадачи в этом методе на основе private или protected методов.

A> Но кое-что ещё, я невооружённым глазом вижу что код не пройдёт коде ревью (если на проекте оно есть, но у вас я так понял манагер не доволен), просто видно что код messy т.е. очень много lines of code просто комменты // /**/

Я уже разбил на 8 подзадач. Но это все равно слишком формально. Теперь представим, что мы принимаем этот формальный подход и дальше. Нам рекомендуют разбить код на методы длиной не больше 20 строк. Это где то 80 методов. И что, такая каша малообусловленных методов (а к ним и названия придумать будет сложно) будет лучше , чем цельный алгоритм?

Как тяжело признаться себе в своих предрассудках!

Комменты — я уже писал, что это не просто комменты, а код тестов, уже завершенных. Все в комментах сдвинуто влево намеренно, чтобы была видна временность назначения этих лесов. По вашему, я стал бы упираться убрать эти комменты, которые и написаны были специально так, чтобы их легко было почистить?

Здравствуйте, Юрий Лазарев, Вы писали:

ЮЛ>Здравствуйте, alexb1980, Вы писали:

A>> Но кое-что ещё, я невооружённым глазом вижу что код не пройдёт коде ревью (если на проекте оно есть, но у вас я так понял манагер не доволен), просто видно что код messy т.е. очень много lines of code просто комменты // /**/

ЮЛ>Я уже разбил на 8 подзадач. Но это все равно слишком формально. Теперь представим, что мы принимаем этот формальный подход и дальше. Нам рекомендуют разбить код на методы длиной не больше 20 строк. Это где то 80 методов. И что, такая каша малообусловленных методов (а к ним и названия придумать будет сложно) будет лучше , чем цельный алгоритм?

ЮЛ>Как тяжело признаться себе в своих предрассудках!

ЮЛ>Комменты — я уже писал, что это не просто комменты, а код тестов, уже завершенных. Все в комментах сдвинуто влево намеренно, чтобы была видна временность назначения этих лесов. По вашему, я стал бы упираться убрать эти комменты, которые и написаны были специально так, чтобы их легко было почистить?

Сразу тоже ж ничего не получается, есть ещё один подход, которой редко используется в MFC (чаще в cross platform наверное). Можно использовать множественное наследование, т.е : public CDialog, protected BaseClass1, protected BaseClass2 {

таким образом эти методы (которых малопонятных у вас получается 80) хотябы не будут идти вперешку ...

Здравствуйте, Юрий Лазарев, Вы писали:

ЮЛ>Но в любом случае это насилие над кодом, реально не приносящее особых выгод. Слишком искусственный подход, еще немного, и получится обертка каждой строки. Я ищу семантический (осмысленный) способ рефакторинга. Скажем, если бы можно было придумать определенную алгебру узлов, я взял бы ее за основу класса безоговорочно.

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

а ты для начала ответь на один вопрос — хочешь ли ты, чтобы твои коллеги смогли сопровождать твой код после твоего ухода? да/нет

ЮЛ>Теперь с точки зрения разработки. Допустим, я пишу локальный цикл, еще не зная, насколько он будет полезен в окончательном алгоритме.

скажу сразу — твой код я считаю отличным для прототипа [1], т.е. той стадии, когда код в дальнейшем может быть либо выкинут, либо зарефакторен. противоречия с Злым Менеджером у вас возникли именно из-за рефакторинга, верно?

[1] плюс-минус всякие детали — например, константы надо делать сразу символическими, иначе потом их хрен найдёшь, а проблемные места в коде я предпочитаю помечать словами "to do: ..." в комментах, так что grep может их все найти

ЮЛ>Если вернуться к аналогии с Войной и Миром, то заведение отдельных методов для мелких частей алгоритма подобно простановке названий параграфов в оглавлении длинной главы. Насколько это будет полезно? Кто читает главы по параграфам?

аналог книги, которую ты читаешь — это exe-файл. что же касается технологий написания книги, то даже у переводчиков есть специальные средства для организации работы, а уж у писателей — и подавно

что касается Галуа, то напомню, что при жизни никто его идей не понял вообще и он помер в нищете в приюте. ты также хочешь?

я тебе могу подкинуть код на 2000 строк, который никто в мире кроме автора не понимает. но при этом он его поддерживает и развивает в течении 15 лет, и отдаёт под BSD лицензией. это код лучшего в мире алгоритма сжатия — lzma. и вот тут никто особых притензий автору не предъявляет, хочешь — разбирайся, не хочешь — отвали

если ты будешь разрабатывать свои решения, продавать их заказчику и обеспечивать сопровождение, то это будет твоё личное дело — как обеспечить их сопровождаемость (и проблемы твоего заказчика, если он переоценил твою надёжность). если же ты работаешь за зарплату, то это задача менеджера — обеспечить их сопровождаемость и независимость от первоначального разработчика. поэтому я могу только посочувствовать твоемук ЗМ, который потерял два месяца, плюс твою з/п, соцотчисления и прочие расходы совершенно зазря: если тебе самому выдать подобный кусок кода, написанный без структуры и комментов другим программистом, то ты его выкинешьб нафиг со словами "что за криворукий ламер написал!" и предложишь переписать всё заново

Здравствуйте, Юрий Лазарев, Вы писали:

ЮЛ>Если вы посмотрите на длинный код внимательно, вы увидите массу комментов, начинающихся у левого края. Это и были мои юнит-тесты, помеченные словом PARSE и пройденные и давно закрытые по причине завершения отладки каждого из предыдущих блоков текста.

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

ЮЛ>Понимаю, до некоторых такое тяжело доходит. На то они и каста манагеров.
ЮЛ>"Глупость это такой ум" (А.Лебедь)

При чем тут манагеры и глупость?

Здравствуйте, Юрий Лазарев, Вы писали:

ЮЛ>С волками жить. Не у вас ли тут в кодексе форума указано, что вы готовы презирать всех, кто ниже вас.

щито?

ЮЛ>Ну а если являюсь?

А если нет? Скромность украшает человека...

ЮЛ>Но равенство предполагает ведь и равенство в оплате, верно?
ЮЛ>Какое же уважение может заслуживать манагер, произвольно устанавливающий зряплату себе и остальным бездельникам?

Сколько проблем оказывается исчезает, когда народ не знает о зп друг друга

Здравствуйте, Юрий Лазарев, Вы писали:

ЮЛ>Так, а чем плохо использование запятой или вложенных тернарных операций, можете ясно ответить? Может, вам стоит написать Страустрапу, чтобы запретить запятую?

а зачем тебе запятая? Ты экономишь на скобках?

ИМХО, обычно операции разделяются точкой с запятой. Запятая применяется лишь там, где она необходима — в выражениях, блоках for и т.п.

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

Здравствуйте, BulatZiganshin, Вы писали:

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

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

BZ>а ты для начала ответь на один вопрос — хочешь ли ты, чтобы твои коллеги смогли сопровождать твой код после твоего ухода? да/нет

Во первых, никаких коллег у маня там нет и не было. Была пара хлюстов с раздутым ЧСВ и сидящих на одном "сопровождении", на которое босс из-за бугра отстегивал, и уж конечно ничего полезного с этими явными подхалимами манагера у меня быть не могло. Умные коллеги (если бы таковые были) сумели бы сопровождать мой код, но тогда они не были бы подхалимами и не напевали бы всякую благоглупость из молитвенника начальника. В коде они никогда не хотели и не разбирались (даже в стандартном), семантика их не занимала, своих алгоритмов они мне так и не представили, вся их "проверка" сводилась к формальным правилам. Что может быть интересного в общении с роботами?

BZ>скажу сразу — твой код я считаю отличным для прототипа [1], т.е. той стадии, когда код в дальнейшем может быть либо выкинут, либо зарефакторен. противоречия с Злым Менеджером у вас возникли именно из-за рефакторинга, верно?

Не только. Здесь это только явный повод указать мне на дверь. Но подноготная была — недостаток финансирования. Начиная с первого уже моего проекта, который удался (хлюст, напортачивший с гитом, тихо сопел в стену и что то там шипел), с которым манагер выезжал на Компасовскую конференцию, он тут же пошел на попятную. Проект плохо покупают, потребителей в России нет, а потому "скрипач не нужен". Это к вопросу о том, кто за что отвечает. За продажи отвечает манагер. Так почему бы ему было не урезать себе любимому зарплату за собственную недоработку?

BZ>[1] плюс-минус всякие детали — например, константы надо делать сразу символическими, иначе потом их хрен найдёшь, а проблемные места в коде я предпочитаю помечать словами "to do: ..." в комментах, так что grep может их все найти

grep вообще не применялся на фирме. Проблемные места я выделял для себя сам, и рассказал уже как. Если бы были какие то правила насчет этого, я не имел бы ничего против.


BZ>что касается Галуа, то напомню, что при жизни никто его идей не понял вообще и он помер в нищете в приюте. ты также хочешь?

Что значит, я так хочу? Так хочет руководство, хотите вы. А вы считаете, за идеи свои не стоит бороться?

BZ>если ты будешь разрабатывать свои решения, продавать их заказчику и обеспечивать сопровождение, то это будет твоё личное дело — как обеспечить их сопровождаемость (и проблемы твоего заказчика, если он переоценил твою надёжность). если же ты работаешь за зарплату, то это задача менеджера — обеспечить их сопровождаемость и независимость от первоначального разработчика. поэтому я могу только посочувствовать твоемук ЗМ, который потерял два месяца, плюс твою з/п, соцотчисления и прочие расходы совершенно зазря: если тебе самому выдать подобный кусок кода, написанный без структуры и комментов другим программистом, то ты его выкинешьб нафиг со словами "что за криворукий ламер написал!" и предложишь переписать всё заново

Да никто на фирме не стал бы писать этот проект вообще — мозги прокомпассированы инструкциями. Их обычный коронный ответ "Это невозможно", или "Это невыгодно", и эти ответы обожает манагер. Едва я только пришел на фирму, я удивился, почему окошко плагина сделано немодальным, очень некрасиво. Мне заявили на чистом глазу, "Это невозможно", потому что так сказал какой то их авторитет. Через два часа изучения их кода я сделал первую правку, которая показала, что это более чем возможно. Они даже не догадывались , что окнами в Windows можно управлять каким угодно образом.
Если вы полагаете, что именно на мне ЗМ понес самые большие убытки, то как быть с теми хлюстами, что ничего не делая, огребали вдвое больше?


Я не имею ничего против, если на фирме финансовые затруднения, и приходится урезать з/п. Но так если получать помалу, так всем помалу. Или одни выживают за счет других?

Здравствуйте, enji, Вы писали:

E>А если нет? Скромность украшает человека...

Зато бандерлога украшает бесцеремонность.

Удаления тут нет, что ли?

Здравствуйте, alexb1980, Вы писали:

A>Сразу тоже ж ничего не получается, есть ещё один подход, которой редко используется в MFC (чаще в cross platform наверное). Можно использовать множественное наследование, т.е : public CDialog, protected BaseClass1, protected BaseClass2 {
A>таким образом эти методы (которых малопонятных у вас получается 80) хотябы не будут идти вперешку ...

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