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

@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.

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

Новые блоги и статьи Все статьи Все блоги /
Поиск всех путей на ориентированном графе. Linux dcc0 02.07.2026 Переработка старого кода из моей статьи. Через несколько переработок от PHP кода к C89 (надеюсь, 89). Но довольно запутанно получилось. Код для Linux. Но если убрать time и то, что с ним. . .	Сам себя обучал rest api anaschu 02.07.2026 Педагогический лайфхак: Почему чистый REST API для ученика намного круче, чем готовые библиотеки Когда мы отказались от капризного JAR-файла AnyLogic и переписали код на стандартный HttpClient,. . .	rest api anylogic - выполнение модели на своём русском сайте anaschu 02.07.2026 Как подружиться с AnyLogic Cloud API, победить провайдеров и развернуться Java-бэкенд в Docker на бесплатном хостинге: Двухдневный лог борьбы Всем привет! Хочу поделиться свежим (и довольно. . .	Где деньги лежат kumehtar 02.07.2026 Это - японская подводная лодка I-52 (тип C2, кодовое имя Momi) вышла из Японии в марте 1944 года с миссией в оккупированную немцами Францию (Лорьян). Это была одна из «Янаги»-миссий по обмену. . .
Krabik для WoW 3.3.5a, многоязычный AmbA 02.07.2026 Допилил бота, думаю что окончательно. Изменения: - добавлена многоязычность - добавлено снятие скриншотов - добавлено поддержание бафов хождения по воде (для жреца, дк и шамана) - и так, по. . .	Алиса нашла кучу ошибок компиляции и запуска в проекте, который без проблем компилировался и запускался))) anaschu 30.06.2026 Я пока посмеюся, но завтра проверю. А вообще интерсно. Дал алисе файл, в котором точно нет ошибок компиляции и запуска, и попросил их найти. Нашла кучу))) Критические ошибки, мешающие компиляции и. . .	сукцессия 16. Общий обзор, в основном что бы другие ии поняли anaschu 29.06.2026 # Передаточный документ: модель микоризной сукцессии (для нового чата) Этот документ предназначен для того, чтобы новый чат Claude мог продолжить работу без необходимости заново разбираться в. . .	сукцессия 15 неявная схема anaschu 29.06.2026 Алиса Калибровка параметров симбиотической модели: технический обзор Содержание: Введение Постановка проблемы Технические аспекты реализации Процесс внедрения изменений

@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 / 1796 / 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