Красивый код (2 стр)

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

Почему так??? Я привык TAB'ом структурировать код программы, добавлять отступы...

MrShoor
> если больше двух - сразу отказывать. Я с ним согласен, т.к. поддерживаю тот же код.
Не уловил смысл, поясните пожалуйста???

>http://habrahabr.ru/post/172091/

++ц просто...

ЗЫ: да там жавадрочер походу советы даёт.

Лучше же писать (в случае указателей) nullptr, да?

Laynos
Умные дяди плохого не посоветуют. Написано 0 - значит НОЛЬ!!1

static_cast
> Laynos
> Умные дяди плохого не посоветуют. Написано 0 - значит НОЛЬ!!1
int* something;

something = 0;
something = nullptr;

Как по мне, nullptr лишь подчеркнёт то, что мы работаем с указателем. Если же мы поставим 0, то нам придётся вспоминать что это за переменная и т.п. Разве я не прав? (да и nullptr != 0 вроде)

Laynos
> 38. Нельзя использовать специальные символы (например, TAB) и разрывы страниц.
>
> Почему так??? Я привык TAB'ом структурировать код программы, добавлять
> отступы...
Можно, но в каждом проекте свои заморочки, и всегда (ВСЕГДА) это упирается в дело вкуса ведущего программиста. По сути никакой разницы как именно делать, главное везде чтоб одинаково. А если получилось неодинаково -- есть программы, которые форматируют целиком все исходники под одну гребёнку (astyle например, замечательная штука, не нарадуюсь).
Laynos
> Лучше же писать (в случае указателей) nullptr, да?
да, конечно. Это правило про NULL скорее для компиляторов прошлой эпохи перед принятием стандарта С++ 2011.

Так же стоит использовать константы и функции там, где раньше программист не сомневаясь зафигачил бы #define.
Например два таких дефайна
#define X 1
#define TRY(Z) (Z[0] == '3')
гораздо лучше выглядят, компилируются, переименовываются средствами IDE, и проверяются на чистоту типов компилятором, если записать их в таком виде
const int X = 1;
bool TRY(const char *Z) { return Z[0] == '3'; }
А код получается одинаковый

Почитай 'Совершенный код' Макконела. Я очень жалею, что не прочитал ее раньше, но в итоге (в основном) пришел к тем же выводам, что описаны в книге. Одна из лучших книг по этой теме среди мной прочитанных.

А еще можно воспользоваться готовыми соглашениями (к примеру, гугловскими - хотя конкретно их С++'ные лично мне не очень нравятся): http://google-styleguide.googlecode.com/svn/trunk/cppguide.html

TheGrayWolf
> Не уловил смысл, поясните пожалуйста???
Многие "правильные" программисты страдают overengineering-ом, что в нагромождениях абстракций шею свернуть можно.

Laynos
> либо чересчур сложную, неоправданную систему проектирую

Привыкай. C++ - язык велосипедостроителей. Одни и те же паттерны приходится все снова и снова изобретать.

kvakvs
> Первым делом чтоб работало
> Вторым делом чтоб красиво выглядело
> Третьим делом (или никогда) оптимизация

Никогда не слушай таких плохих советов.

> Первым делом чтоб работало
> Вторым делом чтоб красиво выглядело

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

Книга по красивому коду: Скотт Майерс. Эффективное использование C++
Книга по красивой архитектуре: Microsoft. Руководство по проектированию архитектуры приложений.

> Третьим делом (или никогда) оптимизация
Если изначально выбирать неоптимальные алгоритмы, то весь код в целом будет работать равномерно медленно. Т.е. под профайлером ты не увидишь явно медленных участков кода. Все будет работать равномерно плохо. Лучше оптимизировать заранее по-возможности, не сильно затрачивая время.

Laynos
> Хм... Ок. А по поводу оптимизации... Слышал, что код можно прогонять по
> каким-то тестам... Что те или иные тесты вообще делают?

Юнит тесты обязательны. В качестве фреймворка могу порекомендовать Google Test и Google Mock. Измерят и время выполнения теста и правильность выполнения.

И еще одна просьба, ни в коем случае не пиши на С, используя С++. С и С++ разные языки. Макросы и голые указатели можно и нужно избегать в С++.

Laynos
> Лучше же писать (в случае указателей) nullptr, да?
Сейчас лучше писать nullptr. В с++11 nullptr спец. тип данных для указателей.
Пример:

Laynos
> Код пишу так, как это удобно мне. Дроблю на классы таким же макаром
это хорошо

Laynos
> Всегда работал один
это не очень хорошо

Laynos
> я хочу научиться писать красивый и понятный код

а эта формулировка содержит всю необходимую вам информацию.

dds
> Если заранее не продумать красивую архитектуру, никакой рабочий код не будет
> выглядеть красиво. А в перспективе, вообще не будет работать из-за:
> 1. конфликтующих компонентов или даже модулей
> 2. из-за чересчур связанного, но не связного кода.
1. лечится рефакторингом. Вот ты сейчас новичку советуешь читать какие-то умные книги об идеальном коде, которые он поймёт и начнёт осмысленно использовать только лет через 3-5. А сейчас ему это усложнение ни к чему.

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

kvakvs
> 1. лечится рефакторингом.

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

Если рефакторинг разделить на стадии, по интенсивности, то, переписывание с нуля, в сущности — это терминальная стадия рефакторинга. ;-)