Оценка стиля кода

@BRcr · Регистрация: 03.02.2011

Студворк — интернет-сервис помощи студентам

Народ, есть предложение. Оцените мой код. Не в смысле функционала - в смысле стиля написания.

Значится, вот тут есть некий код:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
bool __fastcall TForm1::check_condition( void )
{
    for ( t_cells::iterator it( cells.begin( ) ), end( cells.end( ) );
        it != end;
        ++it )
    {
        if ( it->second->charged && it->second->gp == GP_MUST_PASS )
        {
            return false;
        }
    }
    return true;
}
 
// ---------------------------------------------------------------------------
bool __fastcall TForm1::engine_make_step( void )
{
    if ( check_condition( ) )
    {
        return false;
    }
 
    t_neibs accepting_neibs, declinatory_neibs;
    t_cell * receiver;
 
    // bool charge_passed_this_step( false );
 
    for ( t_cells::iterator it( cells.begin( ) ), end( cells.end( ) );
        it != end;
        ++it, accepting_neibs.clear( ), declinatory_neibs.clear( ) )
    {
        t_cell * cell( it->second );
        for ( t_neibs::iterator neib( cell->neibs.begin( ) ), neib_end( cell->neibs.end( ) );
            cell->charged && !cell->just_received && ( neib != neib_end );
            ++neib )
        {
            t_cell * neib_cell( cells[ * neib ] );
            if ( !neib_cell->charged )
            {
                if ( neib_cell->rp == RP_PASS_WANTED )
                {
                    accepting_neibs.push_back( * neib );
                }
                else
                {
                    declinatory_neibs.push_back( * neib );
                }
            }
        }
        if ( accepting_neibs.size( ) > 0 )
        {
            receiver = cells[ accepting_neibs[ std::rand( ) % accepting_neibs.size( ) ] ];
            cell->pass_charge_to( receiver );
            // charge_passed_this_step = true;
        }
        else if ( ( declinatory_neibs.size( ) > 0 ) && ( cell->gp == GP_MUST_PASS ) )
        {
            receiver = cells[ declinatory_neibs[ std::rand( ) % declinatory_neibs.size( ) ] ];
            cell->pass_charge_to( receiver );
            // charge_passed_this_step = true;
        }
    }
    recalc_priorities( );
    // return charge_passed_this_step;
    return true;
}

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

Итак, кто за мою аннигиляцию, как написателя адекватного цпп кода - поднимите руки и скажите свое язвительное слово.

Кто против - тоже не стесняйтесь.

@taras atavin · 26.01.2015, 15:26

Сообщение от Dmitriy_M

Это не стиль. Это оптимизация по созданию временных объектов. Встречается в книгах C++ In-Depth.

Какое отношение временные объекты имеют к трёхстрочному заголовку цикла? Это именно стиль и он дряной.

@Dmitriy_M · 26.01.2015, 15:28

Трехстрочники так же читаемы, если блок выделяется {}

@taras atavin · 26.01.2015, 15:38

C++
1
2
3
4
for (int i=0; i<n; ++i);
{
 a[i]=i;
}

,

C++
1
2
3
4
5
6
for (int i=0;
 i<n;
 ++i)
{
 a[i]=i;
}

. Выделение блока есть в обоих случаях, но второй случай читается легко в простых случаях и как

C++
1
2
3
4
for (...);
{
 a[i]=i;
}

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

C++
1
2
3
4
for (int i=f(fx(x), fy(y), fz(z); i<n(nx(x), ny(y), nz(z); ++i);
{
 a[i]=i;
}

и

C++
1
2
3
4
5
6
for (int i=f(fx(x), fy(y), fz(z);
 i<n(nx(x), ny(y), nz(z);
 ++i)
{
 a[i]=i;
}

. Но в

C++
1
2
3
4
for (...);
{
 a[i]=i;
}

значит цикл с пустым телом и

C++
1
2
3
{
 a[i]=i;
}

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

@Ev_Hyper · 26.01.2015, 16:16

Сообщение от Dmitriy_M

Стив Макконнелл в своём "Совершенный код" не одобряет.

Dmitriy_M, не читал. В двух словах, поясните, что Макконнелл пишет по этому поводу?

Evg · 26.01.2015, 16:22

Сообщение от Dmitriy_M

Это оптимизация по созданию временных объектов

Почти всё, что написано, грубо говоря, в один оператор, любой вменяемый компилятор в состоянии взять и соптимизировать. Поэтому, например, код "a = a * 128" выглядит более читаемым, чем "a = a << 7", когда по смыслу мы имеем именно умножение на 128, а не сдвиг, но в итоговом коде компилятор всё равно поставит сдвиг на 7. Основная масса потуг по оптимизации кода в реальной жизни кроме ухудшения читабельности ничего не приносит. Оптимизировать надо процесс проектирования больших программ, а не мелкие пакости

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

@taras atavin · 26.01.2015, 18:13

Сообщение от Evg

"a = a * 128" выглядит более читаемым, чем "a = a << 7"

Нет. Что такое a=a*128 новичкам приходится объяснять и при этом говорить, что если одна и та же величина встретилась в операторе присваивания справа и слева, то справа у неё старое значение, от результата вычисления не зависящее, а после того как результат вычислен, его можно поместить в ту же переменную и результат от этого не изменится,

C++
1
a<<=7;

есть увеличение a в количество раз, равное степени у которой основание равно основанию внутреннего представления переменной a, а показатель указан в правом операнде, то есть находится справа. Основание известно, это всегда два, а

C++
1
a=a<<7;

страдает тем самым упоминанием величины с обеих сторон + означает увеличение в степень. В зависимости от того, имеет ли новичок ввиду значение 128, или степень с показателем 7, читабельней будет или

C++
1
a*=128;

, или

C++
1
a<<=7;

, для опытного не проблема держать 16 степеней в памяти. А оптимизация

C++
1
a*=128;

и тем более

C++
1
a=a*128;

и

C++
1
a=a<<7;

может зависеть от опций и выбора самого компилятора,

C++
1
a<<=7;

гарантирует оптимизацию, так как она уже выполнена. Разумеется нет нужды на столько всё вылизывать вручную, когда можно задать правильные опции, но есть одно но. Если имелась ввиду именно степень $https://www.cyberforum.ru/cgi-bin/latex.cgi?2^7$ , а не её значение 128, то быстрей написать

C++
1
a<<=7;

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

@BRcr · 28.01.2015, 14:09 **[ТС]**

Благодарю всех за внимание.

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

0x10, Evg, полностью согласен по перегрузке логикой. Постоянно пинаю себя не лениться и дробить код под кусочки с минимумом функционала... Но всегда трудно было уловить грань, на которой следует остановиться. Например, очистка временных контейнеров в шапке цикла. Другое дело, что при разнесении логики по функциям, как сделал 0x10, абсолютно любой цикл будет просто проходом по последовательности без дополнительной лапши. Вот это уже куда проще читается. В общем, с позиций профессионального программирования компоновка кода у меня никуда не годится, это понял, тут есть много чему поучиться.
Но если учесть, что программирование - хобби, а профессиональная деятельность никак не связана даже с IT?

Убежденный, код выдран из контекста и из темы.

Это фикс на новый функционал - поэтому что-то было добавлено, а старое, уже не нужное - закомментировано. Ну, и наименование gp откомментировано в классе. Хотя, согласен - лучше было оставить полное наименование.

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

Evg · 28.01.2015, 14:40

Сообщение от BRcr

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

Вообще если маленький логически законченный кусок кода можно выделить в отдельную функцию БЕЗ УЩЕРБА для логики всей программы - так и нужно поступать. Код состоящий из множества маленьких функций с понятными названиями и именами читается и отлаживается намного проще, чем большая колбаса. И не надо тут бояться какой-то потери производительности из-за накладных расходов на вызов функции - аккуратно написанный код любой современный компилятор соптимизирует так, как будто он написан в виде одой большой функции, а не кучи мелких

@taras atavin · 28.01.2015, 16:51

Функции надо выделять не по минимуму их подзадач, а по минимуму связей с другими частями программы, как горизонтальных, так и с вызывающим кодом.

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

@sourcerer · 28.01.2015, 18:10

Не по теме:

Сообщение от taras atavin

Эйси.

Не первый раз вижу у Вас этот оборот. Что он означает?

@taras atavin · 28.01.2015, 18:55

Сообщение от gru74ik

Не первый раз вижу у Вас этот оборот. Что он означает?

Это значит. A. C.

@_Ivana · 28.01.2015, 23:26

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

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

@taras atavin · 29.01.2015, 16:06

Сообщение от castaway

А эта аббревиатура как расшифровывается?

All complite.

Добавлено через 2 минуты

Сообщение от _Ivana

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

Инлайны ни кто не отменял.

@Тамика · 29.01.2015, 16:18

Сообщение от taras atavin

complite

complete

@castaway · 29.01.2015, 18:16

Сообщение от taras atavin

All complite.

Ну тогда вэдэ.

Новые блоги и статьи Все статьи Все блоги /
Книги по геймдизайну, левел-дизайну, игровым механикам и проектированию игрового опыта 8Observer8 08.11.2026 Содержание блога \| English Version 1. 2003 - 06 - Designing Virtual Worlds (1st Edition) Автор: Richard A. Bartle \| Объем: 768 стр. Ссылки: Amazon . . .	Родители токсичные абьюзеры по отношению к своим детям ругают их оскорбляют не любят zorxor 08.11.2026 Жить в атмосфере постоянных оскорблений, критики и холодности со стороны родителей — это тяжелое и болезненное испытание, которое оставляет глубокие эмоциональные раны. Токсичное и абьюзивное. . .	Как только я захожу к себе в свою комнату я сразу же с себя снимаю свои трусы. Ответ от Джемени ИИ. zorxor 08.11.2026 Джемени, как только я захожу к себе в свою комнату я сразу же с себя снимаю свои трусы. Многие люди, возвращаясь домой, сразу переодеваются в максимально свободную одежду или вовсе предпочитают. . .	Паттерн очереди действий/команд (Action / Command Queue). Система очереди действий и кат-сцен с SDL3 Callbacks, cglm и OpenGL 8Observer8 07.11.2026 Содержание блога \| English Version Руководство для начинающих по реализации паттерна очереди действий/ команд (Action / Command Queue) на C++ (C++20) с использованием официального SDL3 Callbacks. . .
Проверка полного ФИО в типовом справочнике Maks 07.11.2026 Решение реализовано в конфигурации КА2, на примере справочника "КонтактныеЛицаПартнеров". Задача: Запрет инициалов. Не допускаеть использование сокращений вида "И. И. ", "И. И. ", "И И" и. . .	Про "Windows must die!" kumehtar 04.11.2026 Знаете, чет накатило. . . . Когда-то это было почти боевым кличем: мол, нормальный человек сидит на DOS, OS/ 2 или Linux, а вот это вот - Must Die. А теперь человек произносит «мастдай» с усмешкой - и. . .	Красочные поля с номером страницы svg+background-image russiannick 04.11.2026 Красочные поля с номером страницы не менее важны чем в эпоху бумажных книг. Посему спешу представить почтеннейшей публике этот важный инструмент который эти поля и формирует. В процессе разработки. . .	Вступаем в новую фазу генерации favicons, векторную. russiannick 02.11.2026 Теперь нет нужды скрывать что используется простой svg. Исходный код изображения помещаем в поле и жмем кнопку. Исходник преобразуется в вид корректный для помещения в favicon или в url(). Нажатие. . .

@Dmitriy_M 1443 / 1326 / 131 Регистрация: 20.03.2009 Сообщений: 4,689 Записей в блоге: 11
	26.01.2015, 15:28
	Трехстрочники так же читаемы, если блок выделяется {} 0

@BRcr 4043 / 2333 / 292 Регистрация: 03.02.2011 Сообщений: 5,066 Записей в блоге: 10
	28.01.2015, 14:09 [ТС]
	Благодарю всех за внимание. По форматированию отвечу всем сразу, без цитат, а-то это дело растянется надолго. Всем сторонникам ярко выраженной лаконичности могу только пожать плечами. Привычка к обилию фигурных скобок напрямую вытекает из способа написания кода. Почти никогда не пишу финальную версию алгоритма вот так сразу одним проходом. На это у меня банально не хватит опыта - вместо этого сперва делаю базовую версию, костяк, и постепенно добавляю функционал - в этом случае изначальное наличие всех скобок на циклах и условиях облегчает процесс. Плюс, однозначность - не может даже теоретически возникнуть сомнений, что находится в теле цикла, а что нет. Обилие пробелов, переносов строк, скобок - все это работа форматировщика, делается автоматом. Наличие всех закрывающих скобок также контролируется редактором. Так что, когда настраивал всю эту оснастку, просто решил, что пусть все будет визуально отдельно - попробовал, понравилось, а на некоторые нестыковки, как наличие\отсутствие пробела после названия функции или слова for, просто закрыл глаза. Так ли оно важно? Например, предназначение звездочки как оператора умножения или оператора разыменования должно однозначно вытекать из контекста, поэтому пробелы не имеют особого значения. 0x10, Evg, полностью согласен по перегрузке логикой. Постоянно пинаю себя не лениться и дробить код под кусочки с минимумом функционала... Но всегда трудно было уловить грань, на которой следует остановиться. Например, очистка временных контейнеров в шапке цикла. Другое дело, что при разнесении логики по функциям, как сделал 0x10, абсолютно любой цикл будет просто проходом по последовательности без дополнительной лапши. Вот это уже куда проще читается. В общем, с позиций профессионального программирования компоновка кода у меня никуда не годится, это понял, тут есть много чему поучиться. Но если учесть, что программирование - хобби, а профессиональная деятельность никак не связана даже с IT? Убежденный, код выдран из контекста и из темы. Это фикс на новый функционал - поэтому что-то было добавлено, а старое, уже не нужное - закомментировано. Ну, и наименование gp откомментировано в классе. Хотя, согласен - лучше было оставить полное наименование. SatanaXIII, мне тут сказали, что мой код вообще лисп напоминает.)) Неужто инициализация копированием так страшно смотрится? В stl ведь это обычное дело, многое основано на конструкторе копирования и operator(), так почему не использовать это в любой инициализации? Я даже и разницы не заметил, когда отказался от инициализации присваиванием. 0

@taras atavin 4226 / 1799 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	28.01.2015, 16:51
	Функции надо выделять не по минимуму их подзадач, а по минимуму связей с другими частями программы, как горизонтальных, так и с вызывающим кодом. Добавлено через 5 минут То есть так, чтоб любое одиночное изменение где угодно вне функции с наименьшей вероятностью влекло за собой изменения функции, а её изменения с наименьшей вероятностью влекло за собой изменения вне функции, а если уж изменения вне функции влекут за собой изменения в функции и/или наоборот, то влекомые изменения должны быть минимальны. При этом каждая функция должна делать что нибудь осмысленно и при этом всё таки законченное и позволять придумать себе осмысленное имя, описывающее и назначение самой функции, и семантику её параметров. 1

@_Ivana 4949 / 2289 / 287 Регистрация: 01.03.2013 Сообщений: 5,991 Записей в блоге: 32
	28.01.2015, 23:26
	По форматированию - лишние скобки и строчки имхо дурной тон. Однострочники рулят. Не, конечно если у вас вместо монитора проектор на всю стену и сразу одним взглядом можно охватить несколько сотен строк кода - тогда да, можно позволить себе писать как ТС (тоже аббревиатурка, да). А если на моем буке стандартный экран, то меня достает мотать простыни, написанные в подобном стиле. Единственно что можно тут упомянуть - опыт одной знакомой бабки, которая решила в готовом работающем коде заменить часть функций макросами и код перестал работать. Как выяснилось - как раз из-за отсутствия фигурных скобок внутри условий и циклов - функция выполнялась как одно целое, а макрос "рвался". По поводу выноса в функции - если скорость не важна или компилировать с максимальной оптимизацией, то логику конечно упрощает. 1