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

TheGrayWolf
> ЗЫ: да там жавадрочер походу советы даёт.
от всей статьи буквально несет явой...
а вот эти

прям плевки в лицо порой )

покажите свои работы.

asvp
> class Foo { void fun(int); void fun(void*); };

Это вредный оверлоад. Если их использовать, мешанина неизбежна.
Из такой же области:

void fun(int);
void fun(bool);
void fun(float);
void fun(char);

shekh
Вредный не вредный, но хороший для демонстрирования nullptr.

shekh
> Это вредный оверлоад. Если их использовать, мешанина неизбежна.
> Из такой же области:
>
> void fun(int);
> void fun(bool);
> void fun(float);
> void fun(char);

Это вредно, только если fun в разных случаях выполняют принципиально разную логику.
Например: одна отправляет письмо на емейл, а другая рисует картинку на экране.

Но если fun во всех случаях выполняет одну и ту же задачу, то такой подход не только оправдан, но и полезен.
Например:

auto character_info = DB::Query(character_id);
auto location_info = DB::Query(location_id);

В обоих случаях аргументы разных типов. что делает возможной перегрузку функций, а значит - возможность принимать разные аргументы и возвращать разные типы данных.

Пользователю же не нужно запоминать 100500 разных методов.

Достаточно запомнить только один. И иметь на руках структуры данных интересных ему запросов, и ответов.

Kartonagnick
> auto character_info = DB::Query(character_id); auto location_info =
> DB::Query(location_id);

В этом случае все ок, потому что character_id и location_id - разные типы. Если бы у них были операторы приведения друг к другу, и еще базовый класс для которого тоже есть Query - был бы ад.

В таком случае предпочитаю QueryCharacter(), QueryLocation()

shekh
> QueryCharacter(), QueryLocation()
Наплодим 100500 Query...

> В этом случае все ок, потому что character_id и location_id - разные типы.
void fun(int); void fun(void*);
В этом случае тоже все ок. Параметры функции - разные типы.

> В таком случае предпочитаю QueryCharacter(), QueryLocation()
И, позволю себе телепатию, ты бы предпочел так
void funInterger(int); void funPointer(void*);

asvp
> void fun(int); void fun(void*);

int и float тоже разные типы? Ну ок.
Нравится писать nullptr или 0.0f - пожалуйста.
Меня устраивает что 0 может быть любым числовым типом (char, bool, pointer, float..)

Rikk
> покажите свои работы.
скриншоты могу показать. Ну или фрагменты кода. Весь показывать стыдно :(

shekh
> int и float тоже разные типы? Ну ок.
> Нравится писать nullptr или 0.0f - пожалуйста.
> Меня устраивает что 0 может быть любым числовым типом (char, bool, pointer,
> float..)
Видимо тему не читали.
Был задан вопрос в топике #18.
Был дан ответ в топике #25.

shekh
> Если бы у них были операторы приведения друг к другу, и еще базовый класс для
> которого тоже есть Query - был бы ад.

Для конкретных типов вызвались бы конкретные перегрузки

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

в чем ад то?

shekh
> int и float тоже разные типы? Ну ок.

хех, конечно разные

> Нравится писать nullptr или 0.0f - пожалуйста.

а это уже из области дизайна класса.
где то удобно не различать например, int и unsigned int
но при этом принципиально различать целые и дробные.

например:

kvakvs
> Классическое правило: Make It Work, Make It Beautiful (Right), Make It Fast
> Первым делом чтоб работало
> Вторым делом чтоб красиво выглядело
> Третьим делом (или никогда) оптимизация

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

Вы чему молодёжь учите? Так можно приобрести плохие привычки, от которых потом сложно избавиться.
Это касается как стиля оформления, так и оптимизации.
Итак, вот советы ещё одного горе-программиста:
1. "Совершенный код" Маконела, правила оформления кода от Google и есть статейка на эту тему по результатам исследования исходников Doom3 на хабре. Найти и прочитать. Попытаться выработать убодные тебе правила форматирования кода. Делать это в процессе создания рабочего кода. Не должно быть такого, что тут у меня открывающая скобка на этой строке, там на второй, тут переменная с малой буквы, там с большой. Такие вещи - очень важный признак говнокодера (даже не знаю, есть ли такие в природе).
2. Оптимизация идёт третьим пунктом, это верно, но некоторые вещи нужно предусматривать заранее. Например, нельзя делать так:

for(size_t i = 0; i < vector.size(); i++) {
}

А нужно делать так:

size_t max = vector.size().
for(size_t i = 0; i < max; i++) {
}

Особенно если vector.size() имеет большой размер.
Ну и так далее)
Правильные вопросы задаёшь.

Идиально красивый код.
Автор kipar

Саша123
> Например, нельзя делать так:
>
> for(size_t i = 0; i < vector.size(); i++) {
> }
> А нужно делать так:
> size_t max = vector.size().
> for(size_t i = 0; i < max; i++) {
> }
Разве нынешние компиляторы с++ не настолько умные чтоб делать это автоматически?

Саша123
> 2. Оптимизация идёт третьим пунктом, это верно, но некоторые вещи нужно
> предусматривать заранее. Например, нельзя делать так:
> for(size_t i = 0; i < vector.size(); i++) {
> }
> А нужно делать так:
> size_t max = vector.size().
> for(size_t i = 0; i < max; i++) {
> }
> Особенно если vector.size() имеет большой размер.
Фу-фу. Говнокодерство.
В Debug да, согласен, будет вызываться vector.size() каждую итерацию. Но на то это и Debug.
И в чем тут оптимизация. Прочитать переменную, сохранить в другую, что бы её читать.

А Release нынешние компиляторы умеют оптимизируют эту штука.