Инсталляция из исходников с Github.com

[LutsenkoDenis]

Сейчас меня опять обвинят в наезде

Конечно обвиним, припёрся тут... на святыни покушаешься

Я уже отвечал на этот вопрос. Дополню лишь, что если будет документ, описывающий стандарты написания кода, то будет проще им следовать.

Вот тут эта тема поднималась пару лет назад, однако воз и ныне там.

Сейчас все модули, которые не относятся к ядру системы, выделяются в отдельные приложения и выносятся из проекта в маркет. Для примера: RussianPost, YandexWeather, Network UPS Tools и.т.д. Соответственно у них есть описание в вики и на гитхабе приложения. У тех модулей, которые еще не вынесены или не могут быть вынесены в маркет описание можно и нужно добавить. Описание модулей все же лучше делать в вике а не в файле в каталоге с модулем. Там можно пример с картинкой привести и т.д. А в файле...ну хз... мне инфа в файле мало чем поможет.

[igk1972]

Меня же волнуют два вопроса:
- после моих изменений, продолжится ли написание сумбурного кода?

Я уже отвечал на этот вопрос. Дополню лишь, что если будет документ, описывающий стандарты написания кода, то будет проще им следовать.

Пока нет документа со стандартами по коду, вот Вам минимум из нужного:
- Отступ = 2 пробела.
- Весь код (любой) проекта должен быть с отступами (и не табуляции).
- Все встроенные функции/команды самого php только строчными буквами.
- При запуске консольных скриптов php из самого php - узнайте и используйте константу PHP_BINARY.
- Забудьте про функцию chdir - все только с указанием ROOT и относительно этой константы.
- Забудьте про html-атрибут style - это зло для проекта в век css.
- Не объявляте новых констант без супер-реальной надобности.
- Между тегами head и body НЕ может быть ничего.
- DOC_TYPE в наш век теперь только один: html
- Не называйте файл ...class.php если в нем нет класса.
- Не располагайте классы и функции в одном файле.
- Не делайте вот такое /objects/index.php и в папке только один файл - лучше сделайте objects.php и для него строку в routing.
- Не кладите в корень проекта папки продуктов третьих сторон - лучше выделить для этого одну подпапку vendor.
- Все файлы проекта должны быть локально, все всключая шрифты, js для ie6-8, прочее.
- Не храните в проекте zip-файлы с кодом.
- Изучите документацию по bat/cmd файлам на предмет linux аналогов, например этого $0.

Добавлено:
- НЕ используйте "\n" - используте константу PHP_EOL.
- mkdir всегда вызывать с 3-мя параметрами - третий параметр true (аналог mkdir -p)

[sergejey]

Ок, спасибо, полезная шпаргалка.

[LutsenkoDenis]

Пока нет документа со стандартами по коду, вот Вам минимум из нужного

Тут маленькое лукавство Документы такие есть, список внизу поста. Нет конкретно в нашем проекте. Еще раз предлагаю взять что-то за основу и/или составить свой документ. В 2013 году я предлагал за основу взять RSDN стиль оформления. Тем более что он очень хорошо описан.

Отступ = 2 пробела.

Почему 2 пробела а не 3 или 4?
Я например использую три пробела. (Два слишком маленький отступ, четыре слишком большой)
В psr-2 говорится: Indenting - Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting., т.е. 4 пробела, без табов.
ZendFramework: Для отступа используйте 4 пробела. Не используйте символ табуляции. Т.е. соответствует PSR-2

Все функции/команды самого php только строчными буквами.

Немного не понял о чем речь... Функции, они же методы, обычно пишут верблюжьим стилем т.е. getSomethingFromDb или GetSomethingFromDb (в зависимости от того, как договорено в команде). Писать имена методов полностью строчными буквами это зло. Команды самого php пишутся так, как эти команды написаны самими разработчиками php.

Еще можно почитать:
1. Стандарты оформления кода PHP на русском языке.
2. Рекомендации к стандартам оформления кода на PHP
3. Соглашения по оформлению кода команды RSDN
4. PHP Framework Interop Group (PSR)

[igk1972]

Пока нет документа со стандартами по коду, вот Вам минимум из нужного

Тут маленькое лукавство Документы такие есть, список внизу поста. Нет конкретно в нашем проекте. Еще раз предлагаю взять что-то за основу и/или составить свой документ.

Именно так. Документом я считаю информацию опубликованую на сайте. Но лучше сделать wiki на github, а на сайте только ссылку.

Отступ = 2 пробела.

Почему 2 пробела а не 3 или 4?

Не принципиально.
Предложил два пробела, на основании разборок кода.
Но точно не надо 3.

Все функции/команды самого php только строчными буквами.

Немного не понял о чем речь... Функции, они же методы, обычно пишут верблюжьим стилем т.е. getSomethingFromDb или GetSomethingFromDb (в зависимости от того, как договорено в команде).

Да, Вы не допоняли )))
Речь о встроенных функциях/командах самого php. То есть сейчас по коду разбросаны Define, когда вернее define. Ну и так далее.
СamelCase никто не призывает отменять )))
Поправил шпаргалку выше.

[igk1972]

Еще важное:
- Не плодить такие папки как /pdw/, /blockly/, /jpgraph/ - все это должно лежать в /vendor/, но с условием соблюдения следующего пункта.
- Если необходим продукт третьей стороны (php/js/css), то кладем его неизменным в отдельную подпапку в папке /vendor/, а в проекте ссылаемся на него, либо делаем еще php-файл, который конфигурирует/использует продукт третьей стороны.

[LutsenkoDenis]

Не принципиально.
Предложил два пробела, на основании разборок кода.
Но точно не надо 3.

1. Не нужно на основании разборок кода. ) Если уж рефакторить, то взять за основу что-то более менее вменяемое. Родить на базе этой основы свой документ. И уже следуя этому документу рефакторить код.
2. Если не принципиально, тогда почему "точно не надо три пробела"?

Да, Вы не допоняли )))

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

Предлагаю маленький план действий:
1. Давайте уже родим какой-то минимальный набор правил оформления кода. Берем например за основу PSR, перерабатываем его под наш проект.
2. Если по каким-то пунктам мнения разойдутся, то устроим голосование.
3. По результатам создадим документ и занесем его в wiki, github
4. Начнем постепенно приводить код в соответствии с документом.

[igk1972]

Не принципиально.
Предложил два пробела, на основании разборок кода.
Но точно не надо 3.

1. Не нужно на основании разборок кода. ) Если уж рефакторить, то взять за основу что-то более менее вменяемое. Родить на базе этой основы свой документ. И уже следуя этому документу рефакторить код.
2. Если не принципиально, тогда почему "точно не надо три пробела"?

Сами же сослалий на документы PSR )))
К тому же 4 это half-tab (8). Так что уж думаю сойдемся на 4-х пробелах;

Да, Вы не допоняли )))

Можно на ты? Я конечно безмерно уважаю всех присутствующих на форуме и могу долго и обстоятельно общаться со всеми на Вы, но это как-то...[/quote]Можете писать как Вам угодно, но я продолжу как пишу.

Предлагаю маленький план действий:
1. Давайте уже родим какой-то минимальный набор правил оформления кода. Берем например за основу PSR, перерабатываем его под наш проект.
2. Если по каким-то пунктам мнения разойдутся, то устроим голосование.
3. По результатам создадим документ и занесем его в wiki, github
4. Начнем постепенно приводить код в соответствии с документом.

1) Да, но после публикации моей версии. То есть ближе к началу июня.
2) голосования обычно заканчиваются демогогией, или кучей споров, увы, но это так. К тому же уровень опыта/знаний/перфекционизма разный.
4) Да.
4) см. пункт 1.


Понимаете ли, кроме PSR, еще есть такие (например) банальности как указание двойных кавычек у атрибутов тегов. И долго удивляешься, когда в одном файле (строк на 50-100), в одном месте есть двойные кавычки у атрибутов, а через несколько строк - нет.
Или строки http-адресов указаные прям в коде, неоднократно в рамках одного класса. Что мешало сделать через единую константу - непонятно. (((((
(риторически)

[LutsenkoDenis]

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

Ну, демагогию разводить точно не будем.

Понимаете ли, кроме PSR, еще есть такие (например) банальности как указание двойных кавычек у атрибутов тегов. И долго удивляешься, когда в одном файле (строк на 50-100), в одном месте есть двойные кавычки у атрибутов, а через несколько строк - нет.

На PSR я сослался для того, чтобы не изобретать велосипед, так как там вкратце расписаны основные вещи. Более подробно и детально расписано например в RSDN, но я совсем не уверен что его кто-то вообще сможет прочитать. Тем более не вижу смысла сразу впадать в такие крайности. Тонкостям и банальностям я уже давно не удивляюсь. Просто достаточно один раз эти "тонкости" исправить и написать записать в документ что ТАК делать нельзя, и привести пример как правильно(для наглядности).

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

[igk1972]

И я не вижу тут проблемы.

Тоже не вижу проблемы.