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

MTD>Ребята, поймите — быть практиком, не значит писать говнокод.
быть практиком — это иногда писать говнокод

MTD> Быть практиком — это решать проблему приемлемые сроки минимизируя затраты с адекватным качеством. В этом очень помогают проверенные практики, часть из которых я затронул — проверка контрактов, осмысленное именование, один класс — одна ответственность, инкапсуляция.

практики — это хорошо, только не только они есть. есть еще сроки, нервы и сложность решения и сопровождения
одна ответственность возможна только на определенном уровне абстракции: на одно уровне у тебя одна ответственность, а на другом класс делает двадцать разных действий

L>>этот класс, котороый одновременно и визитор, и обсервер и еще кое-что, и есть результат рефакторинга?

MTD>Рефактори дальше — результат неудовлетворительный.
нет предела совершенству, надо уметь остановиться в рефакторинге

почему нельзя всегда давать хорошие имена — да потому что мы не писатели, мы программисты. если давать хорошие имена, то получится жава с длинными названями и эпические поэмы. ты, например, любишь поэмы, а я — хокку
программист борется с двумя сложностями :
1) сложность прикладной задачи
2) сложность решения прикладной задачи, т.к. попутно из-за "бест практик" ему приходится вводить сущности не из доменной области. а так, взятые с потолка

в общем, ты слишком категоричен и перфекционист Ж)

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


ХГД>>Эээ, ты правда считаешь, что код, полагающийся на гарантированный стандартом языка порядок инициализации членов класса, обязательно сложный?

MTD>Если инициализация зависит от порядка членов в классе — это плохо, сломать это может кто угодно, да даже ты сам, через некоторое время.

Вот чтобы не сломали, я и пишу комментарии. Пока помогает.

MTD>Явное всегда лучше неявного, используй фабрику.

Фабрика-то тут при чем? Посмотри, например, rationale к boost::base_from_member — там описана похожая ситуация, только еще хуже, когда для обеспечения правильного порядка инициализации приходится выносить член в базовый класс.

ХГД>>О хорошем, а не о нереально совершенном. Вот, например, библиотека boost::asio, по-твоему, достаточно хороша?

MTD>Не знаю, не сталкивался.

Ну а с какой-нибудь хорошей кроссплатформенной плюсовой сетевой библиотекой сталкивался? Или таких нет в природе?


ХГД>>Да и что нам asio, как на счет стандартных стримов? Заслуживают ли комментария их мелкие отличия на различных платформах?

MTD>Как бы и сами разработчики не скрывают, что дизайн стримов неудачный.

Тем не менее, с ними приходится иметь дело. Значит и без комментариев не обойтись. Да не в дизайне там дело, а в особенностях реализиции.

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

U>быть практиком — это иногда писать говнокод

Даже в таком случае практик локализует его и обернет красиво, сразу и не поймешь.

U>практики — это хорошо, только не только они есть. есть еще сроки, нервы и сложность решения и сопровождения

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

U>нет предела совершенству, надо уметь остановиться в рефакторинге

Золотые слова.

U>почему нельзя всегда давать хорошие имена — да потому что мы не писатели, мы программисты. если давать хорошие имена, то получится жава с длинными названями и эпические поэмы. ты, например, любишь поэмы, а я — хокку

Я тоже сторонник лаконичности, а в яве длинные имена от увлечения паттернами и прочей хренью, когда вместо терминов задачи вылезают термины решения — ProactorVisitorObserverStateCacheManipulator

U>в общем, ты слишком категоричен и перфекционист Ж)

Да это я пофлудить решил

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

ХГД>>Двухстадийная инициализация еще хуже, запихивать их в unique_ptr — ваще отстой.

MTD>Почему?

А незачем без нужды хип теребить.

Здравствуйте, Хон Гиль Дон, Вы писали:

ХГД>Ну а с какой-нибудь хорошей кроссплатформенной плюсовой сетевой библиотекой сталкивался? Или таких нет в природе?

Сокеты Беркли Писал сам над ними кросплатформенную обертку которая так и прижилась в компании.

Здравствуйте, Хон Гиль Дон, Вы писали:

ХГД>>>Двухстадийная инициализация еще хуже, запихивать их в unique_ptr — ваще отстой.

MTD>>Почему?

ХГД>А незачем без нужды хип теребить.

Стек тоже не резиновый А двухстадийная инициализация чем не угодила?

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

ХГД>>Ну а с какой-нибудь хорошей кроссплатформенной плюсовой сетевой библиотекой сталкивался? Или таких нет в природе?

MTD>Сокеты Беркли Писал сам над ними кросплатформенную обертку которая так и прижилась в компании.

Отличный подход — все писать самому с нуля. Вот только цену софта увеличивает в разы, зато комментариев минимум

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

ХГД>>>>Двухстадийная инициализация еще хуже, запихивать их в unique_ptr — ваще отстой.

MTD>>>Почему?

ХГД>>А незачем без нужды хип теребить.

MTD>Стек тоже не резиновый А двухстадийная инициализация чем не угодила?

А мне удобно, например, в одном классе держать дивайс (в терминологии boost::iostreams), фильтр (оттуда же), стримбуфер, стрим и архив (из boost::serialization). А архив не умеет двухстадийно инициализироваться. Да и стрим тоже хочет буфер прямо в конструктор. И вообще все эти open/close усложняют код так, что связываться с ними без действительно веской причины я не желаю.

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

L>Топик-то про C++

Неа, топик уже про то кто лучше кодер и нужны ли комментарии — один спорщик тянет в сторону что они не нужны вообще (детсад), другой — что нужны везде (зануда). Как то так

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

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

L>>Топик-то про C++

aik>Неа, топик уже про то кто лучше кодер и нужны ли комментарии — один спорщик тянет в сторону что они не нужны вообще (детсад), другой — что нужны везде (зануда). Как то так

Если чо, то я за то, что комментировать надо интрефейсную часть юнитов, т.е. относиться к комментариям, как к документации API.
Потроха же лучше устраивать так, чтобы комментировать их было незачем.

U>>эта "идиома" в плюсовом коде не нужна. в старом добром Си — на здоровье
K>Предложи наглядное решение на С++. Мне вот интересно.

Кстати, еще вариант:

[&]()
{
    xxx;
    if (!a) return;
    
    yyy;
    if (!b) return;
    
    zzz;
    if (!c) return;

    blablabla;
}();

А еще лучше — вместо лямбды сделать отдельную функцию. Читаться будет легче.

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

L>Если чо, то я за то, что комментировать надо интрефейсную часть юнитов, т.е. относиться к комментариям, как к документации API.

Поправка — не комментировать, а документировать, по-нормальному — с ссылками, описанием исключений и прочего, доксиген здесь кстати.

L>Потроха же лучше устраивать так, чтобы комментировать их было незачем.

У тебя что раздвоение личности? Когда я об этом говорил ты со мной спорил с пеной у рта

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

L>>Если чо, то я за то, что комментировать надо интрефейсную часть юнитов, т.е. относиться к комментариям, как к документации API.

MTD>Поправка — не комментировать, а документировать, по-нормальному — с ссылками, описанием исключений и прочего, доксиген здесь кстати.

Как хочешь называй. Ни того, ни другого в куске кода ТС и близко нет.

L>>Потроха же лучше устраивать так, чтобы комментировать их было незачем.

MTD>У тебя что раздвоение личности? Когда я об этом говорил ты со мной спорил с пеной у рта

Учу читать. Дорого:

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

А теперь, краткий курс логики для планирующих сдавать IELTS!

Вышеприведенная цитата говорит о том, что:
1. Комментирование потрохов реализации обязательно.
2. Комментирование потрохов реализации излишне.
3. Not Given

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

L>

L>Кратко сообщать о том, что это за класс, зачем он нужен и как и в каких случаях используется, какие задачи решает, а какие-нет (в случае, если это неочевидно).

L>А теперь, краткий курс логики для планирующих сдавать IELTS!

L>Вышеприведенная цитата говорит о том, что:
L>1. Комментирование потрохов реализации обязательно.
L>2. Комментирование потрохов реализации излишне.
L>3. Not Given

Очевидно, пункт 1, так как далеко не все классы являются частью публичного интерфейса. А потом, ты вдруг выдаешь пункт 2:

Потроха же лучше устраивать так, чтобы комментировать их было незачем.

Раздвоение личности?

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

L>>Вышеприведенная цитата говорит о том, что:
L>>1. Комментирование потрохов реализации обязательно.
L>>2. Комментирование потрохов реализации излишне.
L>>3. Not Given

MTD>Очевидно, пункт 1, так как далеко не все классы являются частью публичного интерфейса. А потом, ты вдруг выдаешь пункт 2:

MTD>

MTD>Потроха же лучше устраивать так, чтобы комментировать их было незачем.

MTD>Раздвоение личности?

Все гораздо проще — ты бы завалил IELTS и схожие тесты.
Правильный ответ — 3.

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

L>Все гораздо проще — ты бы завалил IELTS и схожие тесты.
L>Правильный ответ — 3.

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

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

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

L>>Все гораздо проще — ты бы завалил IELTS и схожие тесты.
L>>Правильный ответ — 3.

MTD>Уверен, сейчас ты приведешь доказательство где у меня ошибка, не балабол же ты в самом деле.

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

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

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

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

L>Заголовок с копирайтом позволяет сразу понять, что это, откуда оно взялось и кто в этом виноват. Даже когда работаешь из движущегося поезда без подключения к системе.

Git — everything is local.

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

aik>лютый трындец. write-only.

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

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

L>>Заголовок с копирайтом позволяет сразу понять, что это, откуда оно взялось и кто в этом виноват. Даже когда работаешь из движущегося поезда без подключения к системе.

S>Git — everything is local.

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