Добрый день.

Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?

Здравствуйте, stalcer, Вы писали:

S>Добрый день.

S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
S>Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?

Зависит от задач. Например, я пишу (на С++) semantic analyser для некоторого языка. Каждый semantic check суть класс, но т.к. их дофига (порядка 700), то отводить под каждый класс отдельный файл неразумно. Поэтому я группирую классы по файлам исходя из некотрых принципов. Средняя длина файла 1000 — 1500 строк.

Здравствуйте, stalcer, Вы писали:

S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
S>Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?
Насчет функций. В большинстве случаев, не больше экрана. Количество строчек зависит от разрешения. Если больше то начинаю думать как рефакторнуть.
Иногда построить алгоритм значительно легче в одной процедуре (большое количество последовательных действий). Тогда так и пишу. Если есть время (и хотение) то потом уже разбиваю на различные логические части.
Что касается файлов, то как-то не регламентирую. Лишь бы наполнение было логически связано. Есть файлы и по 5 тысяч строк. Если файлы по одному классу. В большинстве случаев — класс-файл более удобно. Особенно в условиях VSS.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Есть файлы и по 5 тысяч строк.

У меня примерно так и получается.

GZ>Если файлы по одному классу. В большинстве случаев — класс-файл более удобно. Особенно в условиях VSS.

А не парит держать открытыми в IDE много маленьких текстов и лазить туда-сюда.

Здравствуйте, stalcer, Вы писали:

GZ>>Если файлы по одному классу. В большинстве случаев — класс-файл более удобно. Особенно в условиях VSS.

S>А не парит держать открытыми в IDE много маленьких текстов и лазить туда-сюда.
Я в VSS лазию через студию, и поэтому удобно. Сразу видишь какие файлы можно уже зачекинить, какие нет. В этом случае — большой плюс получается.
Что касается переключение между файлами, то парит. Но также парит и поиск по файлу. То есть в любом случае парит. Но у меня все таки есть предположение, что переключение между файлами меня лично меньше парит чем Ctrl-F. На Ctrl-TAB уже рука набита.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Что касается переключение между файлами, то парит. Но также парит и поиск по файлу. То есть в любом случае парит. Но у меня все таки есть предположение, что переключение между файлами меня лично меньше парит чем Ctrl-F. На Ctrl-TAB уже рука набита.

Дык, по Ctrl-TAB ты же попадаешь на следующий файл, а не на тот, который тебе нужен.

Здравствуйте, stalcer, Вы писали:

S>Дык, по Ctrl-TAB ты же попадаешь на следующий файл, а не на тот, который тебе нужен.
Нет, на предыдущий который переключался до этого. Обычно работаешь с 2-3 файлами одновременно, и между ними с помощью Ctrl-TAB очень удобно переключаться, несмотря что открыто порядка 20.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

Хорошо. Я понял.

Просто выскажу свое мнение. Лично я пишу большими исходниками:

— Я использую имя исходного текста для логического разбиения групп классов (compiler.h, parseTree.h и т.п.).
— Внутри исходника я также отделяю более мелкие группы комментариями. Для меня важен порядок следования этих групп.
— Для меня также важен порядок следования классов внутри соответствующей группы.

Помоему вся эта прелесть теряется, если использовать один файл на класс, соответственно наблюдая общую структуру проекта через project manager (в отсортированном по алфавиту виде и без комментариев).

Вот интересно, я один такой, или нас таких много .

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, stalcer, Вы писали:

S>>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
S>>Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?
GZ>Насчет функций. В большинстве случаев, не больше экрана. Количество строчек зависит от разрешения. Если больше то начинаю думать как рефакторнуть.
+1

GZ>Иногда построить алгоритм значительно легче в одной процедуре (большое количество последовательных действий). Тогда так и пишу. Если есть время (и хотение) то потом уже разбиваю на различные логические части.
Почти так же, но сложные алгоритмы я пишу сначала на бумаге, а там очень легко получается выделить некоторые фрагменты на отдельные подпрограммы еще перед вводом кода в редакторе

GZ>Что касается файлов, то как-то не регламентирую. Лишь бы наполнение было логически связано. Есть файлы и по 5 тысяч строк. Если файлы по одному классу. В большинстве случаев — класс-файл более удобно.
Очень похоже на мою ситуацию, только я предпочитаю не классами оперировать, а сущностями. Если сущность представляется одним классом, значит один класс на файл (вот так, например). Если больше -- то, как правило, все классы данной сущности идут в один файл (например, вот так). Хотя, если классов сильно много, то я делаю дополнительное деление.

GZ> Особенно в условиях VSS.

А мне, с svn, как-то фиолетово
Не обращаещь на такие вещи внимания.

Здравствуйте, stalcer, Вы писали:
S>- Я использую имя исходного текста для логического разбиения групп классов (compiler.h, parseTree.h и т.п.).
Что касается парсеров, то меня тоже ломает разделять его на файлы. Потенциально слишком много классов получается. Писанины много, а сложности мало.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Что касается парсеров, то меня тоже ломает разделять его на файлы. Потенциально слишком много классов получается. Писанины много, а сложности мало.

Ну а структура бизнес системы: с бизнес объектами, логикой, формами всякими и отчетами. Например, я бы все бизнес объекты какой-либо подсистемы ("зарплата", например) запихал в один исходник, всю логику в другой (а может и в тот-же).
Меня, например, бесит в Delphi каждую форму в отдельном юните делать.

Здравствуйте, stalcer

1) Если для описания типа "А" нужен тип "Б", а для описания типа "Б" нужен тип "А" (кроссылка, цикл), то типы "А" и "Б" должны быть описаны в одном модуле. Аналогично для случая нескольких типов, когда они циклически ссылаются друг на друга (завязаны друг на друге, "круговая порука", граф связей между ними имеет циклы).

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

Сергей Губанов wrote:

> 1) Если для описания типа "А" нужен тип "Б", а для описания типа "Б"
> нужен тип "А" (кроссылка, цикл), то типы "А" и "Б" должны быть описаны
> в одном модуле. Аналогично для случая нескольких типов, когда они
> циклически ссылаются друг на друга (завязаны друг на друге, "круговая
> порука", граф связей между ними имеет циклы).

А что, в Обероне нет опережающих описаний (forward declarations)?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Сергей Губанов, Вы писали:

СГ>1) Если для описания типа "А" нужен тип "Б", а для описания типа "Б" нужен тип "А" (кроссылка, цикл), то типы "А" и "Б" должны быть описаны в одном модуле. Аналогично для случая нескольких типов, когда они циклически ссылаются друг на друга (завязаны друг на друге, "круговая порука", граф связей между ними имеет циклы).

Зависит от языка. В моем случае такой проблемы вообще нет.

Здравствуйте, stalcer, Вы писали:

S>Добрый день.

S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?

Как правило, у меня исходники маленького размера. Общее правило — 1 класс = 1 файл. Средняя длина файла — 100-200 строк. Есит конечно исключения в видк файла в 1000-2000 строк, но это редкость.

Для выбора файла в редактор в проектную модель не смотрю никогда. Всегда ищу конкретный класс по имени, или по навигации из его usage'а

Здравствуйте, stalcer, Вы писали:

S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
S>Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?

Скажу крамольную фразу. Размер отдельных исходных файлов и количество типов в одном файле обратно пропорционален классу программиста.

Ну, а теперь попробую обосновать. Дело в том, что единственная цель ради которой стоит разбивать исходники на отдельные файлы — это логическая организация кода и прощение навигации по нему. Если в одном файле навалено несколько классов и куча функций, то о простоте навигации уже говорить трудно. Лично я пользуюсь соглашениями о форматировании RSDN в которых четко указано, что не вложененые: классы, структуры и перечисления должны находиться в отдельных файлах, а имена файлов должны соотвествовать именам классов. Это за одно позволяет структурировать классы путем размещения их классов в отдельных директориях.

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

Здравствуйте, VladD2, Вы писали:

VD>Ну, а теперь попробую обосновать. Дело в том, что единственная цель ради которой стоит разбивать исходники на отдельные файлы — это логическая организация кода и упрощение навигации по нему.

Имхо, именно для этого классы и объединяются в исходники по несколько.

VD>Конечно современные средства навигации позволяют находить классы и методы даже если они хаотически разбросаны по проектам...

Ну, никто же не говорит про "хаотически разбросаны".

Здравствуйте, stalcer, Вы писали:

S>Имхо, именно для этого классы и объединяются в исходники по несколько.

Это вряд ли. Если нужно объединить несколько классов проще создать для них отдельную папочку, а не лепить все в один файл. Более того — ограничение C# первой версии на размещение класса в одном файле во второй версии убрано совсем не зря.

Здравствуйте, stalcer, Вы писали:

S>Зависит от языка. В моем случае такой проблемы вообще нет.

Я что-то не понял, какой проблемы?

Здравствуйте, Cyberax, Вы писали:

C>А что, в Обероне нет опережающих описаний (forward declarations)?

Не понимаю, при чем тут Оберон, но если Вас это так сильно интересует, то для описания типов циклически ссылающихся друг на друга предварительные объявления не требуются:

A = POINTER TO RECORD
      b: B
    END;

B = POINTER TO RECORD
      a: A
    END;