[prog] Почему я предпочитаю один стиль оформления кода другому

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

Итак, какое-то время я писал следующим образом:

Образец #1

if( is_valid_trx_id( context_storage.get_current_context(), trx.id(),    user_manager.find( trx.user_id() ) ) ) {    try_enqueue_trx( trx );    start_new_child_process_if_necessary(); }

Открывающая фигурная скобка на предыдущей строке (т.е. на строке, в которой находится if, switch, for, список параметров функции и т.д.) – это красиво и удобно. Но только на маленьких фрагментах кода. Вроде такого:

if( is_valid_trx_id( trx ) ) {    try_enqueue_trx_id( trx );    start_new_child_process_if_necessary(); }

В таких маленьких фрагментах хорошо видно, где именно находится открывающая фигурная скобка (и есть ли она вообще). Но, стоит только условному выражению внутри if-а расположиться на нескольких строках, да еще и содержать 4-5-6 закрывающих круглых скобок перед открывающей фигурной, как обнаружить месторасположение фигурной скобки оказывается уже сложнее.

Еще одна проблема с открывающей фигурной скобкой на предыдущей строке: если условие в if (for, while) занимает несколько строк, а затем еще и в составном операторе находится много кода, то бывает сложно выделить место начала составного оператора:

size_t items_viewed = 0; for( awaiting_trx_container_t::const_iterator it = m_awaiting_trx.begin();    it != m_awaiting_trx.end() && trx_to_process.size() < max_trx_at_once;    ++it, ++items_viewed ) {    log_current_trx( m_logger, m_action_description, *it );    const trx_checking_result_t & checking_result = check_current_trx( *it );    if( checking_result.is_processable_trx() ) {       log_processable_trx( m_logger, m_action_description, *it );       trx_to_process.push_back( *it );       m_awaiting_trx.erase( *it );    }    // Здесь может быть еще несколько строк с какими-то действиями. }

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

size_t items_viewed = 0; for( awaiting_trx_container_t::const_iterator it = m_awaiting_trx.begin();    it != m_awaiting_trx.end() && trx_to_process.size() < max_trx_at_once;    ++it, ++items_viewed ) {    log_current_trx( m_logger, m_action_description, *it );    const trx_checking_result_t & checking_result = check_current_trx( *it );

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

Вот так я пришел к следующему стилю кодирования:

Образец #2

if( is_valid_trx_id( context_storage.get_current_context(), trx.id(),    user_manager.find( trx.user_id() ) ) ) {    try_enqueue_trx( trx );    start_new_child_process_if_necessary(); }

Этот стиль лишен недостатков предыдущего. Но в нем есть проблемы, например, с “частоколом” из if-else-if или внутри switch-а:

if( can_process_trx( trx ) ) {    // Какие-то действия. } else if( can_delay_trx( trx ) ) {    // Еще какие-то действия. } else if( can_reroute_trx_to_another_host( trx ) ) {    // Еще какие-то действия. } else if( can_throw_trx_away( trx ) ) {    // Еще какие-то действия. } else {    // И еще какие-то действия. }

Здесь в крайней левой позиции находится слишком много символов. Хочется видеть только if-else-if, а приходится еще и на фигурные скобки смотреть. В какой-то момент времени я понял, что мне это мешает, а вот GNU-тый стиль кодирования содержит нужное мне решение – отступ для составного оператора. С этим отступом “частокол” if-else-if становится более заметным, на мой взгляд:

if( can_process_trx( trx ) )    {       // Какие-то действия.    } else if( can_delay_trx( trx ) )    {       // Еще какие-то действия.    } else if( can_reroute_trx_to_another_host( trx ) )    {       // Еще какие-то действия.    } else if( can_throw_trx_away( trx ) )    {       // Еще какие-то действия.    } else    {       // И еще какие-то действия.    }

Вот так я пришел к следующему стилю:

Образец #3

if( is_valid_trx_id( context_storage.get_current_context(), trx.id(),    user_manager.find( trx.user_id() ) ) )    {       try_enqueue_trx( trx );       start_new_child_process_if_necessary();    }

Но и здесь оставалась одна закавыка: если действие под if-ом занимало одну строку, а само условие в if-e несколько строк, то было сложно различить где заканчивается условие и начинается действие:

if( is_valid_trx_id( context_storage.get_current_context(),    trx.id(),    user_manager.find( trx.user_id() ) ) )    try_enqueue_trx( trx );

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

if( is_valid_trx_id( context_storage.get_current_context(),       trx.id(),       user_manager.find( trx.user_id() ) ) )    try_enqueue_trx( trx );

Ну а дальше осталось сделать последний шаг – разобраться с тем, как переносить вызовы функций с большим количеством аргументов. Сейчас я поступаю так: если вызов функции умещается на одну строку, то я записываю его в одну строку. Если нет – то каждый аргумент (начиная с первого), записывается на новой строке:

// В одну строку. const ACE_Date_Time finish_at = minimum( trx.finish_at(), default_lifetime ); // В несколько строк. При переносах двойной отступ. so_4::api::send_msg_safely(       so_query_name(),       "msg_next_turn",       new msg_next_turn( current_context ),       m_cfg.m_turn_size );

Вот так я и пришел к своему нынешнему стилю:

Образец #4

if( is_valid_trx_id(       context_storage.get_current_context(),       trx.id(),       user_manager.find( trx.user_id() ) ) )    {       try_enqueue_trx( trx );       start_new_child_process_if_necessary();    }

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

Ну и чтобы два раза не вставать, еще пару моментов.

Во-первых, я использую табуляцию для отступов вместо пробелов. Пришел к табуляции очень-очень давно. Году в 1992-м или 1993-м. Причем сначала причина была вообще очень примитивной и жестокой – C++ные исходники с табуляцией занимали раза в полтора меньше места, чем с пробелами. Во времена 1.2Mb 5-дюймовых дискет и медленных 286-х процессоров это было актуально. Потом добавился еще один бенефит – исходник с табуляциями было легко переформатировать для вставки в курсовые/дипломные работы. Не влезает исходник по ширине в A4 при размере табуляции в 4 пробела – ерунда, выставляем размер в 2 пробела и все помещается :) Кстати говоря, это до сих пор прекрасно работает при подготовке различного рода документации.

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

class db_iface_t    :  private ACE_Copy_Disabled    {    public :       virtual ~db_iface_t();       virtual void       detect_known_and_unknown_packages(          const package_id_list_t & full_id_list,          package_id_list_t & unknown_ids,          package_id_list_t & known_ids ) = 0;       virtual std::auto_ptr< outgoing_message_list_t >       select_outgoing_messages_for_sending(          unsigned int message_count,          const ACE_Date_Time & attempt_timestamp ) = 0;       virtual std::auto_ptr< undelivered_SR_package_info_list_t >       select_undelivered_SR_packages_for_resending(          unsigned int package_count,          const ACE_Date_Time & time_border ) = 0;

---

Disclaimer. Все вышеизложенное, вероятно, не очень актуально для работы с текстом программы исключительно за экраном компьютера. Умные редакторы, которые могут сами устанавливать высоту и размер скобочек, величину отступов и менять шрифты для разных элементов (как это делает, например, SourceInsight) + разные виды folding-а + различные браузеры исходных текстов – все это хорошо, но это только одна сторона медали. Вторая сторона – это распечатанные и/или включенные в документацию фрагменты кода. Мне с этим довольно часто приходится сталкиваться. Поэтому я придерживаюсь такого стиля кодирования, чтобы мой исходник можно было один-в-один вставить в качестве примера в документацию/блог и не думать о переформатировании.