Горизонтальные линии в комментариях

Question

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

Я нахожу, что постоянно разделяю исходный код на логические группы (через «комментарии») в пределах одного и того же файла. Например:

---

//---------------------------------------------------------------------------- 
#include "..." 
//---------------------------------------------------------------------------- 
#include <...> 
//---------------------------------------------------------------------------- 
#include <boost/...> 
//---------------------------------------------------------------------------- 
#include <os-specific/...> 
//---------------------------------------------------------------------------- 
namespace 
{ 
    void Foo() 
    { 
    } 
} 
//---------------------------------------------------------------------------- 
namespace 
{ 
    void Bar() 
    { 
    } 
} 
//---------------------------------------------------------------------------- 
namespace 
{ 
    void Baz() 
    { 
    } 
} 
//---------------------------------------------------------------------------- 
int main() 
{ 
} 
//---------------------------------------------------------------------------- 
//This file ends with a new-line. 

Или:

//---------------------------------------------------------------------------- 
#ifndef FOO_HEADER_INCLUDED 
#define FOO_HEADER_INCLUDED 
//---------------------------------------------------------------------------- 
#include "..." 
//---------------------------------------------------------------------------- 
namespace Foo 
{ 
    void Bar(); 
} 
//---------------------------------------------------------------------------- 
#endif 
//---------------------------------------------------------------------------- 
//This file ends with a new-line. 

---

Я читал через какой-то чуждого источника в последнее время, и я заметил, что практически не один не делает.

Единственный аргумент, который я мог бы предложить против такого рода «деления», заключается в том, что вы физически печатаете исходный код в портретном режиме, где ваши делители (если длиннее ~ 80 символов) получат обертку. Однако это не проблема в ландшафтном режиме.

Если честно, я даже не знаю, почему и когда я начал это делать. Существуют ли какие-либо другие недостатки для этого ОКР?

Кроме того, для меня такое поведение является языковым агностиком; Я писал сценарий оболочки на днях и заметил тот же самый шаблон поведения.

Answer 1

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

Там несколько причин, которые я бросить это делать:

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

2. Некоторые вещи бросают вызов легкой классификации. Предположим, вы хотите вложить небольшой класс внутри функции. Вы действительно собираетесь добавить такую ​​линию в середине своей функции?

3. Умные редакторы упрощают навигацию по коду. Первоначально они были добрыми знаками земли, прокручивая вверх и вниз по файлу, чтобы найти вещи. Но в Emacs я много пропускаю с инкрементными поисковыми файлами и тегами. И в случаях, когда я использую IDE, он показывает мне фрагменты файла сбоку и позволяет мне прыгать на них щелчком.

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

5. Я последовательно переключился на комментарии Javadoc/Doxygen. Это более описательные, чем случайные горизонтальные линии, и я также пришел к выводу, что они выглядят намного лучше в коде.

Answer 2

Мне кажется, что вы не используете хорошую среду IDE. Например, вы можете использовать #области в VS для группировки вашего кода. И это намного проще, чем ваши методы.

Answer 3

Некоторые из нас действительно используют их, хотя, возможно, не так либерально, как вы. См. Мой ответ this question.

Answer 4

Регионы - это гораздо лучший способ разделить код. У компании, с которой я сейчас работаю, есть политика против «цветокорпуса» (I.E. окружающие вещи с/***** и ****/comments), и я уверен, что она также применяется к горизонтальным барам.

Я бы придерживался регионов, дела обстояли намного лучше.

Answer 5

В исходных файлах C, у меня есть шаблон, который разбивает файлы на разделы, такие как #defines, определения типов, статический (файл-Scope) определение переменного и прототипы функций, общественные функции и статические функции и т.д. (Аналогично для файлов заголовков C). Они ограничены линией '='.

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

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

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