freepascal.ru

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

Во-первых, если во время компиляции найдётся два модуля с одинаковым именем, то использован будет только один, первый встетившийся.
Ну например:

Код: Выделить всё

Main.pas
a\Unit1.pas
b\Unit1.pas


При этом a и b будут в списке путей. Компилятор тогда возьмёт первый встретившийся модуль. Таким образом, если Main использует Unit1, то возьмётся aUnit1.pas.

А если так:

Код: Выделить всё

Main.pas
a\Unit1.pas
b\Unit1.pas
b\Unit2.pas


Если Unit2 использует Unit1, то всё равно возьмётся a\Unit1.pas, хотя по логике должен наверное взяться модуль, который лежит "ближе", то есть, в той же папке, то есть, b\Unit1.pas. Но это не так, я проверял, будет всё равно браться a\Unit1.pas.

К тому же, при компиляции одного проекта все скомпилированные модули выводятся в один каталог. То есть, если будет два Unit1 в разных папках, то при компиляции они никак не разойдутся, так как Unit1.ppu и Unit1.o по идее должны вывестись в одну и ту же папку для вывода, которая в лазарусе по умолчанию в lib... . Даже если компилировать проект в две стадии, то и это не спасёт, так как для компиляции исполняемого файла нужны все .o-файлы, так что, такая штука:

Код: Выделить всё

a\Unit1 + a\Unit2 -> UnitA
b\Unit1 + b\Unit2 -> UnitB
---
UnitA + UnitB -> Main

не пройдёт, ведь для Main.exe понадобятся и Unit1.o и Unit2.o, из обоих папок, а так быть не может потому, что они затрут друг друга.

К какому же выводу это приводит: лучше стараться всегда придумывать уникальные имена для модулей, иначе они могут пересечься, и тогда придётся их переименовывать, чтобы заставить компилироваться вместе. Причём работа по переименованию может оказаться достаточно дорогостоящей, ведь нужно переименовать и файл, и объявление в начале файла: unit Log; например, и все все ссылки на этот модуль: uses Log. Причём пройти автозаменой в этом случае не получится: вдруг где-то есть переменная var Log: TLog, которую переименовывать нельзя...

Таким образом, если в двух библиотеках будет модуль log, то вместе они не уживутся никак. Даже если log используется библиотекой только внутренне самой библиотекой и не входит в её функциональность. Не поэтому ли во всяких библиотеках в начале модуля приписывают префиксы типа gls для GLScene, fpg для fpgui и проч.

Дополнительная проблема, которая может быть вызвана неудачным именем модуля, заключается в следующем: если используется модуль log, то объявить переменную с именем log уже не получится, будет конфликт имён. Я видел, что некоторые приписывают u к названию модуля, типа uLog. Наверное чтобы избежать конфликтов с именами переменных и функций.

А теперь собственно "главная" проблема, в некотором роде: допустим, я решил давать всем модулям уникальные имена. Мне не лень их набирать, так как я хочу сразу избежать двух проблем: конфликтов имён; и так же ещё чтобы потом не пришлось догадываться, что значат сокращения. То есть, вместо gls я пишу GLScene, вместо ctnrs пишу Containers и так далее. Ну и ещё я не хочу чтобы имя модуля совпало когда-нибудь с именем переменной, для этого я приписываю Unit в конце каждого модуля. Что тогда получается: имена модулей у меня получаются примерно такие:

Код: Выделить всё

GLSceneContainerUnit.pas,
GLSceneAbstractContainerUnit.pas
GLSceneNetworkLogWriterUnit.pas
...
GLSceneAbstractDataBaseConnectionProviderUnit.pas


Так вот: то, что имена модулей длинные сами по себе, это не такая уж и проблема. Проблема в другом: в Windows есть интересное ограничение на максимальную длину пути: 260 символов. И не смотря на то, что в NTFS максимальная длина пути вроде бы 32000, и от ограничения в 260 символов хотели как будто бы уйти, так вот, по факту от него никуда не ушли: оно везде лезет. Можно даже попробовать в Windows 8 создать папку с длиной имени 260 символов, и он не даст. Причём ограничение касается не одного файла, а всего пути. То есть, если будет вот так:
C:\1234.....259\a.txt
То файл a.txt окажется недоступным. То есть, если засунуть свою библиотеку с длинными именами файлов в какую-нибудь "жопу" типа
C:\MountedDrive\Storage\Archive\Programming\FreePascal\Libraries\GLScene\Source\GLSceneAbstractDataBaseConnectionProviderUnit.pas
То если таким образом "переборщить", то будет всё очень плохо

Таким образом, остаётся либо делать короткие имена типа connection.pas и рисковать получить 100500 конфликтов
Либо делать сокращения типа uGLSABDConProv.pas и потом вспоминать что же это значит
Либо делать длинные имена файлов и надеяться что полные пути никогда не вылезут за 260 символов. Либо работать только на линуксе, так как там такого ограничения нет.

Ну и воттттъъъъ........ кто-нибудь может что-нибудь посоветовать

Добавлено спустя 7 минут 9 секунд:
ну или вообще что-нибудь изложить по этому поводу

Я следую следующему правилу — все мои собственные модули должны иметь уникальные имена, а для того, чтобы они отличались от других существующих модулей, я добавляю букву D перед ними. Получаются dparser, dbuffer, dmath, dtypes и т.д. Если я столкнусь с тем, что нужно будет использовать чужой модуль с каким-то совпадающим названием у одного из моих модулей, то подумаю о переименовании своего модуля.

Я согласен с тем, что с модулями в fpc всё очень плохо и было бы круто сделать по-другому (в общем-то из обозначенных в первом посте проблем более менее понятно как именно сделать по-другому, чтобы было хорошо).

Все просто, надо оглянуться вокруг и посмотреть как делают другие.
А другие используют систему именования, похожую на адреса сайтов, только наоборот:
org.glscene.vector
org.fpc.rtl.classes
и т.д.
Так уже довольно давно делается в Дельфи, да и FPC, думаю, уже это поддерживает.

org.glscene.vector
org.fpc.rtl.classes

а чем это лучше
orgglscenevector
orgfpcrtlclasses
читаемостью? orgGLSceneVector точно не хуже. или это путь?
По топику я в разное время пробовал по разному, поэтому у меня есть и log.pas и ltwnd.pas и UGDBOpenArrayOfTObjLinkRecord.pas ))
имхо краткость - сестра таланта, хотя во времена fpc 2.0 хапнул горя при попытке скомпилить программу в исходниках которой был свой strings.pas

Про 260 символов пути: subst в помощь. Либо пользоваться путями поближе к корню, вроде C:\Prj\...

Mirage писал(а):Все просто, надо оглянуться вокруг и посмотреть как делают другие.
А другие используют систему именования, похожую на адреса сайтов, только наоборот:
org.glscene.vector
org.fpc.rtl.classes
и т.д.
Так уже довольно давно делается в Дельфи, да и FPC, думаю, уже это поддерживает.

Данный подход отбивает желание раскладывать файлы по директориям, отбивает желание делать много маленьких и простых модулей.

насчёт имён файлов через точку:
нарпример, org.a.b.c
@Дож насколько я понимаю, это как раз и значит, что компилятор будет искать файл в папке org в подпапке a в подпапке b файл и именем c.pas. В Java примерно так же, название пакета должно отражать структуру каталогов.
@Mirage FPC это не поддерживает, по крайней мере стабильный FPC, а вот 2.7.1 - может быть.....
@bormant что-то я не понял, что такое имеется в виду subst

Давно уже бьюсь с этим в разных аспектах, что файлы, имена, обозначения не должны содержать личных привязок к тому, кто их создал, а должны отражать суть того, что они делают и к чему относятся.
Именую модули в таком стиле:
u_basicobject_class
u_group_class
u_helpwindow_form
.и т.д.
Видно, что за файл, что в нем описано и назначение. Хоть в Object Pascal есть свой закрепленный стиль именований, но именование Java удобны в использовании и понятны. Не важно, что и где там поддерживается у FPC, главное, чтобы имя файла при копировании в другую папку не совпало с там имеющимся файлом и отражало суть содержимого.

GLSceneContainerUnit.pas,
GLSceneAbstractContainerUnit.pas
GLSceneNetworkLogWriterUnit.pas
...
GLSceneAbstractDataBaseConnectionProviderUnit.pas

Самозакапывание ручным способом.
Зачем все файлы имеют в начале "GLScene"?
Зачем писать слово Unit в конце и польностью?

Кто мешает создать папки и хранить в них определенные вещи, т.е. формы в папке форм, классы, в папке классов и т.д. Создавать строгую иерархию древовидную не нужно.

Не в программировании сталкивался. Иностранная организация создала папки пронумеровав их от 1 до 18 и папки выглядели вида "16E", "17C", это означало что папка 16 для электриков. Был файл, где была спецификация содержимого файлов и папок.

Вообще у меня вот ещё какая идея есть:
А что если вообще не разбивать библиотеки на отдельные модули, а всё в одном модуле писать? Одна библиотека - один модуль

zub писал(а):а чем это лучше
orgglscenevector
orgfpcrtlclasses
читаемостью? orgGLSceneVector точно не хуже. или это путь?

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

Дож писал(а):Данный подход отбивает желание раскладывать файлы по директориям, отбивает желание делать много маленьких и простых модулей.

Как уже отметили, данный подход как раз способствует раскладыванию по директориям. А с размером модулей вообще никак не связан.

hinst писал(а):@Дож насколько я понимаю, это как раз и значит, что компилятор будет искать файл в папке org в подпапке a в подпапке b файл и именем c.pas. В Java примерно так же, название пакета должно отражать структуру каталогов.

В Java обязательно (хотя есть нюансы), а в FPC нет, хотя никто не мешает так разложить по папкам.

Sharfik писал(а):Именую модули в таком стиле:
u_basicobject_class
u_group_class
u_helpwindow_form
.и т.д.
Видно, что за файл, что в нем описано и назначение.

А что означает префикс "u"? Зачем он?
Как такая система спасет от того, что кто-то может также назвать модуль? Например как в случае с системой журналирования? И там и там же u_log получится. Надо уникальный префикс автора чтоб был.

hinst писал(а):Вообще у меня вот ещё какая идея есть:
А что если вообще не разбивать библиотеки на отдельные модули, а всё в одном модуле писать? Одна библиотека - один модуль

Классная идея! Отказаться от модульности - основного преимущества языка. Не важно даже что исходную проблему это не решает.
Можно развить успех: отказаться от структурирования вообще - фигачить все без процедур, объектов и вообще какой-либо декомпозиции.

Mirage писал(а):Надо уникальный префикс автора чтоб был

19-ричное представление даты рождения любимого хомяка автора?

hinst писал(а):
Sharfik писал(а):Именую модули в таком стиле:
u_basicobject_class

А что означает префикс "u"? Зачем он?
Как такая система спасет от того, что кто-то может также назвать модуль? Например как в случае с системой журналирования? И там и там же u_log получится. Надо уникальный префикс автора чтоб был.

Когда перед вами 20 файлов в одной паке, вы увидите, что означает "u". Если человек сохраняет файлы формы, то у него сохраняется два файла описание формы и ее модуль класса. Если отключено отображение расширения, то фиг отличишь где у тебя что. Гораздо быстрее среди всего содержимого папки выделять глазами надпись начинающуюся с "u_" = Unit. Или вы контролы тоже называете вместо edtUserName как EditUserName?
Подобные сокращения я помнится во всех книжках встречал, которые мне доводилось читать. Нигде, не было идеи - А давайте будет писать километровые названия.

"u_log" - по определению будет непродуманное название и ошибка в общей архитектуре.
- Не отображает содержимое файла, что это такое класс или может быть форму, функции специальные или еще что то.
- Использовано слишком обобщенное название.
Если создается специальный лог работы программы это один класс, если лог выполнения отчетов, это другой класс, если лог ошибок только, третий класс, вы же не будете все их называть TLogList и пытаться научить работать программу с тремя разными видами логов, когда у них одно и тоже название класса? TReporLog - "u_reportlog_class" TErrorLog - "u_errlog_class" и т.д. А вот всем этим приведенным классам может быть родителем класс TBasicLog - "u_basiclog_class", тогда не возникнет такой проблемы как имена вида - "u_basicreportlog_class". Что в случае автора было приведено выше в каком то из названий файлов, где видел слово "Abstract".

Sharfik писал(а):Когда перед вами 20 файлов в одной паке, вы увидите, что означает "u". Если человек сохраняет файлы формы, то у него сохраняется два файла описание формы и ее модуль класса. Если отключено отображение расширения, то фиг отличишь где у тебя что.

Если мне надо видеть в папке из 20-и файлов какой тип у какого файла, то я буду смотреть не в универсальном файловом менеджере, а в специализированном. В IDE, например. Во вменяемом IDE будет видно где юнит, а где форма.
Если же я работаю в обычном проводнике или FAR'e, значит работаю просто как с файлами и мне не интересно юнит там или форма.

Sharfik писал(а):"u_log" - по определению будет непродуманное название и ошибка в общей архитектуре.
- Не отображает содержимое файла, что это такое класс или может быть форму, функции специальные или еще что то.
- Использовано слишком обобщенное название.
Если создается специальный лог работы программы это один класс, если лог выполнения отчетов, это другой класс, если лог ошибок только, третий класс, вы же не будете все их называть TLogList и пытаться научить работать программу с тремя разными видами логов, когда у них одно и тоже название класса? TReporLog - "u_reportlog_class" TErrorLog - "u_errlog_class" и т.д.

Ок, применим немного здравого смысла к "u_reportlog_class", "u_errlog_class" и т.п.
Начнем с конца: Слово "class" в названии также нужно, как и префикс "u_". Что оно должно сказать? Что внутри класс? А если два? u_errlog_class_x2?
Насчет середины - не могу представить за каким хреном системе логирования знать что она логирует. Куда и как да, знать должна. А вот что -- не должна. Максимум у неё есть функции/методы вида LogXXX(), где XXX это Info, Warn, Error и т.п.
Остаётся просто Log.
Или лучше Logger.

Sharfik писал(а):А вот всем этим приведенным классам может быть родителем класс TBasicLog - "u_basiclog_class", тогда не возникнет такой проблемы как имена вида - "u_basicreportlog_class". Что в случае автора было приведено выше в каком то из названий файлов, где видел слово "Abstract".

Ага, т.е. реализовывать один и тот же функционал для логирования работы, отчетов и ошибок не будем, вынесем в базовый. Но тогда он будет называться "u_basiclog_class" везде, где есть базовая система логирования. Т.е. от изначальной проблемы конфликтов имён даже такие длинные и нелепые имена не спасают.
А банальный ru.fpc.logger или myUniqueLib.logger спасает. Еще и короче.

Господа, вот читаю... и, "то ли лыжи не едут, то ли я....очень странный"
Кто-то любит зеленое, кто-то - стриженое...
Спор о чем конкректно??? Хочется всеобщей унификации или ?

"Каждый выбирает по себе..." (с)

@hinst,
http://ru.wikipedia.org/wiki/Subst