И даже если у тебя в команде условный PSR-12, то нет никаких гарантий что на код-ревью не прилетит страйк за то что аннотация не так как у него в PHPStorm отформатирована, хотя явно это не регламентируется.
Это уже не к PHPStorm вопрос, а к договоренностям в команде и культуре код-ревью. Если вдруг оказалось, что команда хочет следовать тому или иному стилю в коде, то это стоит внести в линтер и явным образом проверять в CI. Чтобы избежать препираний в код-ревью.
огромный процент PHP-шников в принципе не понимает разницу между ошибкой в стиле кодирования и подсказкой, что можно сделать лучше — если IDE говорит, значит надо делать.
Это опять же не проблема IDE. И не проблема PHP. А проблема конкретной команды и конкретных людей. Вы могли бы попытаться поднять этот вопрос на уровень дискуссии и попытаться найти компромисс.
Насколько мне известно, развитие PHP не являлось прямой обязанностью Никиты во время его работы в PHP.
Я, разумеется, не читал контракт Никиты, но, судя по всему, свой вклад в PHP он таки делал в обычные рабочие часы. И это нормально. У нас в компании тоже уделяется время и внимание опенсорсу.
Но даже если я неправ, то все отношение JetBrains к PHP — это стрижка профита с PHPStorm.
Как будто это что-то плохое для обеих сторон. Одна сторона (бизнес) получила профит. Другая сторона (сообщество) получило улучшения используемого языка. Win-win — нет?
Она только на словах. Вот например наша с вами дискуссия: вы искренне не видите или не хотите видеть, что я вижу.
Я думаю, что я понимаю, о чем вы. Другое дело, что я почему-то не сталкиваюсь в своей практике с описываемыми вами проблемами.
Вы стремитесь доказать, что я неправ.
Скорее я пытаюсь раскрыть вам глаза на тот факт, что описываемые вами проблемы не являются нерешаемыми.
Потому что ваша IDE могла бы использовать другие сниппеты, подсказки как сделать лучше, и в итоге это бы все вылезало на кодревью, усложняя работу с теми у кого PHPStorm.
Ну… в диффе в PR подсказок IDE нет ни у кого (если, конечно, не пользоваться плагинами, которые позволяют делать ревью в IDE, но это отдельный разговор). А стягивать к себе код и ревьюить изменения локально — это, прямо скажем, делает далеко не каждый.
Но даже если так сошлись звёзды, и коллега открыл ваш код в IDE, увидел подсказки от IDE и предложил эти изменения в PR, то что такого? Это плохо? При ревью в PR могут быть 3 варианта развития событий:
Вы согласны
Вам не принципиально
Вы не согласны (или как минимум не понимаете важность запрошенных изменений)
На первых двух случаях останавливаться не будем — там всё ясно, вносим изменения и готово.
Поэтому сразу 3-й случай. Почему бы не попросить коллегу мотивировать свой запрос развернуто? И если таки это сугубо вкусовщина (но с ней согласна бóльшая часть команды), то, как я написал выше, заносите это в правила своего линтера в CI и всё.
Вы же сами пишете ниже, что PHPStorm имеет собственный линтер показывающий нечто, что не под силам этим инструментам.
Где я это написал?
Да, я считаю плохо, когда коммерческая компания диктует де-факто стандарт как должен писаться код на языке, к которому она не имеет никакого отношения.
Откуда такой вывод? Стандарты определяют мейнтейнеры проекта (ну или не определяют и пишут кто как попало). PHPStorm лишь помогает придерживаться тех стандартов, которые определены в проекте.
Да, PHPStorm может подсказывать по коду что-то сверх настроенных линтеров (хотя я об этом не писал), но
во-первых, это отключаемо,
во-вторых, программист волен им следовать или не следовать,
в-третьих, JetBrains "немного" имеет к PHP отношение — погуглите кто такой Никита Попов (Никита, правда, уже не работает в JetBrains, но его вклад в развитие php непереоценим).
И уж точно в дополнительных подсказках от IDE нет никакого криминала.
И тем не менее вы неявно намекаете, что PHPStorm лучший вариант.
Для меня — да. Но для вас может быть по-другому. Это нормально. Свобода выбора и всё такое.
Если бы мы работали удаленно в одной команде, я бы, возможно, так и не узнал, какой IDE вы пользуетесь. Вот у меня сейчас в команде 5 человек. Я понятия не имею, кто из них каким IDE пользуется. Зачем мне это знать?
А так да, есть psalm и phpstan и codesniffer, но большая часть сидит в пыхосторме.
То, что есть PHPStorm умеет интегрироваться с данными инструментами, это типа что-то плохое?
Производительность была одинаковая, но за мной стойко ходили слухи, что я не осилил IDE.
Это бессмысленные холивары. Если вам удобно работать в VSCode, работайте там.
Тем не менее у постоянной подсветки недочетов и ошибок есть один, на мой взгляд, плюс. Он корректирует стиль кодинга. В конечном итоге линтеры и статик-анализаторы всё меньше будут ловить недостатков в вашем коде. А значит вы будете по итогу чуть быстрее работать. Но на это нужно время. Сразу ничего не бывает.
Лично я пользуюсь продукцией JetBrains просто потому, что там удобнее делать рефакторинг, лучше сделана индексация кода и, соответственно, навигация по коду получается быстрее. Но тут действительно нужно освоить предлагаемый функционал. Иначе разницы между VSCode и PHPStorm действительно не будет заметно.
А ещё нельзя сделать вот так: https://go.dev/play/p/Wi1Kq3JV8aS. Т.е. у вас может быть дженерик, объединяющий map[int]any и []any, но вы не можете по нему итерироваться, ибо "cannot range over t (variable of type P constrained by ~map[int]T|~[]T) (P has no core type)".
Порядок, разумеется, можно получить. Но, скажем, получать первых 1000 элементов вы как будете? По одному будете вычитывать из hashmap? Какова будет эффективность такого кода?
И да, если вам надо отрезать кусок от массива с начала. Вы в хвосте массива имена элементов будете переименовывать? Или где-то хранить значение наименьшего индекса?
В целом, что-то близкое к обычному ООП наследованию можно сделать через интерфейсы и встраивание, но опять же реализация будет труднее.
В go встроенная структура не имеет ни знаний о том, куда она встроена, ни доступа к встраивающей её структуре. Это, соответственно, делает невозможным абстрактные функции. Это так же делает невозможной работу с обрамляющей структурой во встроенной (т.е. вы не сможете встроить структуру и её методы применять не к ней самой, а к обрамляющей структуре).
P.S. Да, можно заранее предусмотреть во встроенной структуре механизмы — типа переменных с типом функции, куда вы будете присваивать свои функции, меняя тем самым поведение. Вы можете также передавать во встроенную структуру указатель на обрамляющую. Но как-то это уже сильно много возни. О хрупкости и избыточной связности такого кода уже и говорить не приходится. Да и на ООП это уже как-то не очень похоже будет.
если любой массив php воспринимать как хешмпапу и забыть о существовании массивов в принципе, то может быть и нормально.
Как только вы такое принимаете к сведению, вы делаете невозможным (или затруднительным) решение ряда задач, где важен порядок элементов в массиве (ибо в классической hashmap порядок не гарантирован).
Начиная с PHP 8.1 есть функция array_is_list. Она может проверить тип вашего массива. В своем коде вы можете делать валидацию данных и действовать соответственно. Да, это при неаккуратной работе с данными может привести к ошибкам, но на то уже есть тесты и код-ревью. Возможно, в будущем добавят более строгий массив. А пока как есть.
Мой последний проект на ПХП был пару лет назад, на 6000 EUR (тогда евро был в несколько лучшей форме). Скорее всего, я получал больше любого коллеги-программиста в той конторе на тот момент.
На самом деле я туда собеседовался на go, но в последний момент меня переуговорили на php. Мол, у нас надо повышать культуру и качество разработки. Я почесал репу, согласился.
Проработал там год. За год избавился от некоторой части легаси. Перевел разработку на докер (что привело к если не полному, то значительному прогрессу, с решением извечной проблемы "у меня локально работает"). Сделал автотесты и автодеплой в k8s (до этого тесты никто не писал, а деплой делался ручками админом на физический сервер). Ввел стандарты разработки. Написал новый проект с нуля (который одновременно ввёл новый функционал и заменил старый совсем уж лапшевидный легаси). Перевёл пых на последнюю на тот момент релиз-версию.
К концу моей работы там мне стало достаточно скучно, и я попытался получить себе немного больше полномочий и соответствующую компенсацию в организации. Увы, это не встретило понимания у техдира. На этом и распрощались.
Сейчас я таки работаю на go и за значительно бóльший рейт. Но дело не в языке программирования, как вы, наверное, понимаете.
Для себя какие-то мелочи я по-прежнему пишу на php, потому что на нём уже так много написано, что вместо решения каких-то фундаментальных вопросов (а-ля транспорт, форматы данных, спецификация АПИ и прочее, прочее, прочее) я могу решать исключительно свою прикладную задачу. Не то, чтобы на go всё это нельзя было написать, но кода пришлось бы написать больше.
Впрочем, на go тоже кое-что пишу для себя, но по большей части это какие-то мелкие прикладные утильки.
У меня так ограничили услуги в одной конторе в одной из стран ЕС. Без оглядки на то, что я гражданин той самой страны. Официально сослались на место рождения.
Интересно получается. Гитхаб рекомендует (если мне память не изменяет) не заниматься мультиаккаунтингом и использовать один и тот же аккаунт для личных и рабочих целей. И получается, если вам "повезло" оказаться сотрудником компании, на которую позднее наложили санкции, то хана вашему персональному аккаунту? Теперь я начинаю понимать смысл того, зачем некоторые коллеги заводят для работы отдельный акк.
"Your Legacy subscription transition has been delayed
Due to the crisis in Ukraine, we understand you may not be in a position to transition to Google Workspace at this time. We are therefore postponing the deadline to transition until further notice. We will notify you in advance when we reinstate this requirement."
У меня 2 домена. Один ru, один не ru. На первом вот эта надпись. На втором такой надписи нет, но в биллинге оба домена на G Suite legacy, оба Free plan/free edition (no charge). Вот теперь думаю, мне надо беспокоиться на счет ru-домена (чтобы исчезла эта плашка) или пока забить.
Там, правда, маленькая ошибка в коде есть, из-за чего соединение рвётся, но суть ясна. Однако, так не сделаешь VPN. Но было бы любопытно увидеть websocket-based впн :)
в связи со сложившимися обстоятельствами, Google приостанавливает оформление новых подписок для Google Workspace в России, также любые модификации подписок недоступны для санкционных стран.
Возможно, в этом и причина. Потому что у меня, например, аккаунты не в России. Хотя, как они их различают — я не знаю. Может достаточно страну поменять где-то в настройках.
А, вы про sail. Я было подумал про Sails.js.
sails — обертка вокруг докера? Это как?
Это уже не к PHPStorm вопрос, а к договоренностям в команде и культуре код-ревью. Если вдруг оказалось, что команда хочет следовать тому или иному стилю в коде, то это стоит внести в линтер и явным образом проверять в CI. Чтобы избежать препираний в код-ревью.
Это опять же не проблема IDE. И не проблема PHP. А проблема конкретной команды и конкретных людей. Вы могли бы попытаться поднять этот вопрос на уровень дискуссии и попытаться найти компромисс.
Я, разумеется, не читал контракт Никиты, но, судя по всему, свой вклад в PHP он таки делал в обычные рабочие часы. И это нормально. У нас в компании тоже уделяется время и внимание опенсорсу.
Как будто это что-то плохое для обеих сторон. Одна сторона (бизнес) получила профит. Другая сторона (сообщество) получило улучшения используемого языка. Win-win — нет?
Я думаю, что я понимаю, о чем вы. Другое дело, что я почему-то не сталкиваюсь в своей практике с описываемыми вами проблемами.
Скорее я пытаюсь раскрыть вам глаза на тот факт, что описываемые вами проблемы не являются нерешаемыми.
Ну… в диффе в PR подсказок IDE нет ни у кого (если, конечно, не пользоваться плагинами, которые позволяют делать ревью в IDE, но это отдельный разговор). А стягивать к себе код и ревьюить изменения локально — это, прямо скажем, делает далеко не каждый.
Но даже если так сошлись звёзды, и коллега открыл ваш код в IDE, увидел подсказки от IDE и предложил эти изменения в PR, то что такого? Это плохо? При ревью в PR могут быть 3 варианта развития событий:
На первых двух случаях останавливаться не будем — там всё ясно, вносим изменения и готово.
Поэтому сразу 3-й случай. Почему бы не попросить коллегу мотивировать свой запрос развернуто? И если таки это сугубо вкусовщина (но с ней согласна бóльшая часть команды), то, как я написал выше, заносите это в правила своего линтера в CI и всё.
P.S. И вам спасибо.
Где я это написал?
Откуда такой вывод? Стандарты определяют мейнтейнеры проекта (ну или не определяют и пишут кто как попало). PHPStorm лишь помогает придерживаться тех стандартов, которые определены в проекте.
Да, PHPStorm может подсказывать по коду что-то сверх настроенных линтеров (хотя я об этом не писал), но
И уж точно в дополнительных подсказках от IDE нет никакого криминала.
Для меня — да. Но для вас может быть по-другому. Это нормально. Свобода выбора и всё такое.
Если бы мы работали удаленно в одной команде, я бы, возможно, так и не узнал, какой IDE вы пользуетесь. Вот у меня сейчас в команде 5 человек. Я понятия не имею, кто из них каким IDE пользуется. Зачем мне это знать?
То, что есть PHPStorm умеет интегрироваться с данными инструментами, это типа что-то плохое?
Это бессмысленные холивары. Если вам удобно работать в VSCode, работайте там.
Тем не менее у постоянной подсветки недочетов и ошибок есть один, на мой взгляд, плюс. Он корректирует стиль кодинга. В конечном итоге линтеры и статик-анализаторы всё меньше будут ловить недостатков в вашем коде. А значит вы будете по итогу чуть быстрее работать. Но на это нужно время. Сразу ничего не бывает.
Лично я пользуюсь продукцией JetBrains просто потому, что там удобнее делать рефакторинг, лучше сделана индексация кода и, соответственно, навигация по коду получается быстрее. Но тут действительно нужно освоить предлагаемый функционал. Иначе разницы между VSCode и PHPStorm действительно не будет заметно.
А дженерики-то недозавезли в go. Скажем, дженерики нельзя использовать в методах структур: https://go.dev/play/p/Xp6BDMgMkum.
А ещё нельзя сделать вот так: https://go.dev/play/p/Wi1Kq3JV8aS. Т.е. у вас может быть дженерик, объединяющий map[int]any и []any, но вы не можете по нему итерироваться, ибо "cannot range over t (variable of type P constrained by ~map[int]T|~[]T) (P has no core type)".
Порядок, разумеется, можно получить. Но, скажем, получать первых 1000 элементов вы как будете? По одному будете вычитывать из hashmap? Какова будет эффективность такого кода?
И да, если вам надо отрезать кусок от массива с начала. Вы в хвосте массива имена элементов будете переименовывать? Или где-то хранить значение наименьшего индекса?
Погодите, как Psalm связан с PHPStorm?
Ниже можно не читать. Уже дали пример, не заметил.
Если вы хотите гарантировать, что вы получите на вход инты (или любой другой тип), вы можете сделать функцию с вариадическими аргументами:
Вызывать эту функцию так:
Да, это несколько не то, чего хотелось бы от языка. Но технически возможность имеется. Без посторонних средств.
В go встроенная структура не имеет ни знаний о том, куда она встроена, ни доступа к встраивающей её структуре. Это, соответственно, делает невозможным абстрактные функции. Это так же делает невозможной работу с обрамляющей структурой во встроенной (т.е. вы не сможете встроить структуру и её методы применять не к ней самой, а к обрамляющей структуре).
P.S. Да, можно заранее предусмотреть во встроенной структуре механизмы — типа переменных с типом функции, куда вы будете присваивать свои функции, меняя тем самым поведение. Вы можете также передавать во встроенную структуру указатель на обрамляющую. Но как-то это уже сильно много возни. О хрупкости и избыточной связности такого кода уже и говорить не приходится. Да и на ООП это уже как-то не очень похоже будет.
Как только вы такое принимаете к сведению, вы делаете невозможным (или затруднительным) решение ряда задач, где важен порядок элементов в массиве (ибо в классической hashmap порядок не гарантирован).
Начиная с PHP 8.1 есть функция
array_is_list. Она может проверить тип вашего массива. В своем коде вы можете делать валидацию данных и действовать соответственно. Да, это при неаккуратной работе с данными может привести к ошибкам, но на то уже есть тесты и код-ревью. Возможно, в будущем добавят более строгий массив. А пока как есть.Мой последний проект на ПХП был пару лет назад, на 6000 EUR (тогда евро был в несколько лучшей форме). Скорее всего, я получал больше любого коллеги-программиста в той конторе на тот момент.
На самом деле я туда собеседовался на go, но в последний момент меня переуговорили на php. Мол, у нас надо повышать культуру и качество разработки. Я почесал репу, согласился.
Проработал там год. За год избавился от некоторой части легаси. Перевел разработку на докер (что привело к если не полному, то значительному прогрессу, с решением извечной проблемы "у меня локально работает"). Сделал автотесты и автодеплой в k8s (до этого тесты никто не писал, а деплой делался ручками админом на физический сервер). Ввел стандарты разработки. Написал новый проект с нуля (который одновременно ввёл новый функционал и заменил старый совсем уж лапшевидный легаси). Перевёл пых на последнюю на тот момент релиз-версию.
К концу моей работы там мне стало достаточно скучно, и я попытался получить себе немного больше полномочий и соответствующую компенсацию в организации. Увы, это не встретило понимания у техдира. На этом и распрощались.
Сейчас я таки работаю на go и за значительно бóльший рейт. Но дело не в языке программирования, как вы, наверное, понимаете.
Для себя какие-то мелочи я по-прежнему пишу на php, потому что на нём уже так много написано, что вместо решения каких-то фундаментальных вопросов (а-ля транспорт, форматы данных, спецификация АПИ и прочее, прочее, прочее) я могу решать исключительно свою прикладную задачу. Не то, чтобы на go всё это нельзя было написать, но кода пришлось бы написать больше.
Впрочем, на go тоже кое-что пишу для себя, но по большей части это какие-то мелкие прикладные утильки.
У меня так ограничили услуги в одной конторе в одной из стран ЕС. Без оглядки на то, что я гражданин той самой страны. Официально сослались на место рождения.
Интересно получается. Гитхаб рекомендует (если мне память не изменяет) не заниматься мультиаккаунтингом и использовать один и тот же аккаунт для личных и рабочих целей. И получается, если вам "повезло" оказаться сотрудником компании, на которую позднее наложили санкции, то хана вашему персональному аккаунту? Теперь я начинаю понимать смысл того, зачем некоторые коллеги заводят для работы отдельный акк.
У меня сейчас так написано:
"Your Legacy subscription transition has been delayed
Due to the crisis in Ukraine, we understand you may not be in a position to transition to Google Workspace at this time. We are therefore postponing the deadline to transition until further notice. We will notify you in advance when we reinstate this requirement."
У меня 2 домена. Один ru, один не ru. На первом вот эта надпись. На втором такой надписи нет, но в биллинге оба домена на G Suite legacy, оба Free plan/free edition (no charge). Вот теперь думаю, мне надо беспокоиться на счет ru-домена (чтобы исчезла эта плашка) или пока забить.
В худшем случае в городе можно дойти пешком. Или "зайцем" прокатиться на общественном транспорте.
О, даже кредитки удаленно оформляют? С каким лимитом? И где?
Оказывается, я видел этот проект (судя по цвету ссылки), но забыл. Спасибо.
Даже делал такое намедни. Вот пример (не мой) как это сделать: https://github.com/leihaiyong/MiniWebSSHServer
Там, правда, маленькая ошибка в коде есть, из-за чего соединение рвётся, но суть ясна. Однако, так не сделаешь VPN. Но было бы любопытно увидеть websocket-based впн :)
Возможно, в этом и причина. Потому что у меня, например, аккаунты не в России. Хотя, как они их различают — я не знаю. Может достаточно страну поменять где-то в настройках.