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

а зачем менять форматирование? если что -то не нравится -всегда можно настроить отображение в редакторе, все регулируется. А форматирование -это часть стандарта. Да и тут же важна читаемость, инструментарий у всех может быть разный и преобразования в деревья выгодней делать на машине разработчика, иначе придется сначала устанавливать инструменты с которыми он поставлялся, а потом перегонять в свои кошерные

а зачем менять форматирование? если что -то не нравится -всегда можно настроить отображение в редакторе, все регулируется. А форматирование -это часть стандарта. Да и тут же важна читаемость, инструментарий у всех может быть разный и преобразования в деревья выгодней делать на машине разработчика, иначе придется сначала устанавливать инструменты с которыми он поставлялся, а потом перегонять в свои кошерные

Да мало-ли причин. Например легаси проект который одумался и решил перенимать нормальные подходы разработки.

Не все средства разработки ориентированы на текст

Да мало-ли причин. Например легаси проект который одумался и решил перенимать нормальные подходы разработки.

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

а зачем менять форматирование? если что -то не нравится -всегда можно настроить отображение в редакторе, все регулируется. А форматирование -это часть стандарта. Да и тут же важна читаемость, инструментарий у всех может быть разный и преобразования в деревья выгодней делать на машине разработчика, иначе придется сначала устанавливать инструменты с которыми он поставлялся, а потом перегонять в свои кошерные

Эх, если бы все было так как вы говорите

стремиться к прекрасному -это совсем не значит что результат не уничтожит мир )

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

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

То, что вы о нем не знаете, не означает, что его нет

стремиться к прекрасному -это совсем не значит что результат не уничтожит мир )

Вы не представляете как вам повезло с вашими стремлениями

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

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

То, что вы о нем не знаете, не означает, что его нет

Эмм. Вопрос не в том, есть он или нет. А в том, используется он или нет.

Эмм. Вопрос не в том, есть он или нет. А в том, используется он или нет.

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

Эмм. Вопрос не в том, есть он или нет. А в том, используется он или нет.

Вам он будет не удобен, поэтому он не используется

Эмм. Вопрос не в том, есть он или нет. А в том, используется он или нет.

https://astexplorer.net/

а переменные заменить хешами, чтобы не спорили о наименовании

а переменные заменить хешами, чтобы не спорили о наименовании

Скопед во vue делает что-то похожее

Эмм. Вопрос не в том, есть он или нет. А в том, используется он или нет.

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

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

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

а лучше идти ещё дальше - конвертить в разные языки, что бы все писали на своем любимом

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

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

а лучше идти ещё дальше - конвертить в разные языки, что бы все писали на своем любимом

ну вот котлин уже и на jvm работает и в js может)

Electron

Cordova, будь она неладна

просто это все персональные требования их не нужно глобализировать. Сама идея шаринга кода же в том, чтобы сделать его доступным. Это все равно что документы начать шарить вместо pdf в чем то сугубо интимном для любой ОС

https://github.com/ccxt/ccxt Топорно сделаны преобразования, канеш, но PHP-python-js

Текст - самая удобная проекция абстракций, универсальная для человека и машины

@ibxth не стоит относиться к коду как к тексту. Он этого не любит

Взять например ларавель: модель - это таблица

И если вам потребуется динамически создавать таблицы, будьте любезны так же динамически создавать и модели к ним

Если вам нужно динамически содавать REST API - пожалуйста, создавайте роуты и контроллеры и будет вам счастье

Взять например ларавель: модель - это таблица

Эт не совсем так. Модель -это абстракция и представляет она сущность в базе, и может быть не только таблицей (при чем разной, поскольку даже табличные бд различаются по типам записей), но например страницей.

Эт не совсем так. Модель -это абстракция и представляет она сущность в базе, и может быть не только таблицей (при чем разной, поскольку даже табличные бд различаются по типам записей), но например страницей.

Эт не совсем так. Модель - это то что мы договорились считать моделью, ни больше ни меньше.

Если в ларавеле модель это таблица то оно так. А у кого-то там доменные модели, у них по другому.

Эт не совсем так. Модель - это то что мы договорились считать моделью, ни больше ни меньше.

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

А где формально определено что это абстракция?

Никакого отношения к договорённости модель не имеет, это соглашение на уровне правил

Каких правил, где они описаны?

Соглашения это и есть договоренности

А где формально определено что это абстракция?

В гугл, это представление модели данных не зависящее от реализации, комон о чем спор то основы же)

Ну вот в ларавеле формально опеределено что модель это класс для таблицы. Везде используется такая терминология.

Соглашения это и есть договоренности

Нет соглашения я понимаю, как строгое правило исключающее работу при нарушении, а договорённость устное в виде рекомедашки, но да это вкусовщина

В yii2 тоже так было

В любом MVC

Ну вот в ларавеле формально опеределено что модель это класс для таблицы. Везде используется такая терминология.

Где везде? Какая может быть таблица если у меня нет табличного отображения вообще

Я хз про договоренности - говорю из личного опыта

В любом MVC

Где в паттерне мвц написано, что Модель это таблица?

Где в паттерне мвц написано, что Модель это таблица?

В свойстве модели table

Где везде? Какая может быть таблица если у меня нет табличного отображения вообще

https://laravel.com/docs/5.7/eloquent#defining-models вот тут везде упоминается как таблица а не как абстракция

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

https://laravel.com/docs/5.7/eloquent#defining-models вот тут везде упоминается как таблица а не как абстракция

Это их проблема, они подразумевают табличную бд, это не корректно. Ларка с любой работать может и понятие таблица во многих не существует

Это не проблема ни разу )

Ну точнее для тех кто отрицает многозначность термина модель - это проблема.

Таблица - это тоже абстракция

Группа выборок

Схожих по каким то признакам

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

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

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

Артем, тут спор о терминах

Я не корректно выразился и это моя вина

Артем, тут спор о терминах

При чем тут термины, таблица в контексте бд это конкретное и формальное понятие очень точно и давно определенное

Ваша sql вьюха может выступать таблицей дляя модели

> таблица в контексте бд это конкретное и формальное понятие Ну вот, а модель в контексте ларавеля это тоже конкретное и формальное понятие )

Модель и это принципиально важно для понимания, именно абстрактное представление данных, хоть в графе, хоть на странице. Это важно, поскольку очень много структур, где таблиц не существует и в общем смысле вносит путанницу

> таблица в контексте бд это конкретное и формальное понятие Ну вот, а модель в контексте ларавеля это тоже конкретное и формальное понятие )

Печалька ?

> абстрактное представление данных Как-то слишком абстрактно звучит ?

Так это именно и должно быть абстрактным, конкретика скрыта за ней в кишках фреймворка

код ревью происходит усилиями девелоперов, статик анализатор не внедрен, мы полагаемся на пхпсторм инспекции, их вполне достаточно в процессе разработки. Слишком много еще легаси кода, чтобы вводить md и cs.

легаси не является причиной не использовать md, а вот пологаться на инспекции шторма - глупое занятие

Так это именно и должно быть абстрактным, конкретика скрыта за ней в кишках фреймворка

Дело в том, что создавая таблицу, без модели не обойтись

легаси не является причиной не использовать md, а вот пологаться на инспекции шторма - глупое занятие

Поддерживаю. Ваще мне шторм не нра в целом.

Дело в том, что создавая таблицу, без модели не обойтись

Дело не в этом, а в том, что Модель это часть паттерна архитектурного, а таблица часть конкретной реализации

Поддерживаю. Ваще мне шторм не нра в целом.

шторм отличный инструмент, а вот его инспекции без других инструментов в команде разработчиков бесполезны

И создать таблицу без модели никто не мешает ?

Ну нам вообще мало кто может чему то помешать в пределах нашего кода )))

Кстати по ссылке выше понятие таблицы используется только потому, что для примера выбранна табличная бд Now, let's look at an example Flight model, which we will use to retrieve and store information from our flights database table

Делал как то модели с маунтами API вместо таблиц - тупейшая система вышла )))

Делал как то модели с маунтами API вместо таблиц - тупейшая система вышла )))

Результат не особо имеет значение, важно что модель отражает структуру данных в коде и задача ее в том числе скрыть реализацию, поскольку это единственный способ изолировать логику от конфигурации и создать переиспользуемую и поддерживаемую систему. И на самом деле эти детали принципиально важно понимать, поскольку в деталях живет истина. Даже наиболее безобидное использование без понимание с именоманием в виде PersonTableRow уже создаст проблему, если база будет завтра колоночная и Person совсем уже не row. Обобщение и стремление избежать привязки к реализации -это очень важно в контексте качественного и поддерживаемого кода.

А где можно почитать как "правильно" делать модели?

Проблема в том и потому меня почти бомбит, что тут 800+ человек и многие кто прочитают так и будут повторять, а потом на собесе будут жаловаться что их отсевают ругая всех и даже не понимая этих деталей, которые принципиально важны.

А где можно почитать как "правильно" делать модели?

в книжках по паттернам проектирования, рефакторинг с использованием шаблонов и подобное

в книжках по паттернам проектирования, рефакторинг с использованием шаблонов и подобное

https://www.ozon.ru/context/detail/id/5497184/ https://www.ozon.ru/context/detail/id/142429922/ такие подойдут?

https://www.ozon.ru/context/detail/id/5497184/ https://www.ozon.ru/context/detail/id/142429922/ такие подойдут?

DDD классная штука, но спецефичная, Чистый код полезен, но мне не нравится, там слишком очевидное. Лучше к ним добавить https://www.ozon.ru/context/detail/id/2909721/ https://www.ozon.ru/context/detail/id/4884925/

DDD классная штука, но спецефичная, Чистый код полезен, но мне не нравится, там слишком очевидное. Лучше к ним добавить https://www.ozon.ru/context/detail/id/2909721/ https://www.ozon.ru/context/detail/id/4884925/

Благодарю

DDD классная штука, но спецефичная, Чистый код полезен, но мне не нравится, там слишком очевидное. Лучше к ним добавить https://www.ozon.ru/context/detail/id/2909721/ https://www.ozon.ru/context/detail/id/4884925/

Про NoDDD слышали?

Ха-ха-ха ха-ха-ха-ха

Про NoDDD слышали?

нет и хз что может быть поводом, поскольку Домены и Аспекты -это обычно части довольно крупных и сложных систем где без них все становится хуже. Или речь о хеш теге в инсте? )

Нет не об инсте

нет и хз что может быть поводом, поскольку Домены и Аспекты -это обычно части довольно крупных и сложных систем где без них все становится хуже. Или речь о хеш теге в инсте? )

Я вам в личку попозже напишу можно? Мне нужна помощь в классификации одной системы.

можно но я не могу всегда гарантировать быстрый ответ)

А вы слышали про NoNoDDD

https://www.ozon.ru/context/detail/id/5497184/ https://www.ozon.ru/context/detail/id/142429922/ такие подойдут?

https://www.ozon.ru/context/detail/id/5497184/ подойдет, там достаточно прочитать про единый язык

можно но я не могу всегда гарантировать быстрый ответ)

Это нормально. Спасибо. На работе все-таки сейчас....

https://www.ozon.ru/context/detail/id/5497184/ подойдет, там достаточно прочитать про единый язык

Я предпочитаю говорить всеобщий

А вы слышали про NoNoDDD

Я первый придумал)))

Я предпочитаю говорить всеобщий

клоун!

https://www.ozon.ru/context/detail/id/5497184/ подойдет, там достаточно прочитать про единый язык

для единого языка целая книга -это тяжко заходит, есть простенький проект где все наглядно (книжка там тоже есть, но за деньги, ее мало кто будет шарить, поскольку она персонализированна) https://refactoring.guru/ru/design-patterns

клоун!

Я тоже тебе рад )

для единого языка целая книга -это тяжко заходит, есть простенький проект где все наглядно (книжка там тоже есть, но за деньги, ее мало кто будет шарить, поскольку она персонализированна) https://refactoring.guru/ru/design-patterns

А мне легко зашло без единой книги. Это очень логичное решение в принципе...

для единого языка целая книга -это тяжко заходит, есть простенький проект где все наглядно (книжка там тоже есть, но за деньги, ее мало кто будет шарить, поскольку она персонализированна) https://refactoring.guru/ru/design-patterns

причем тут паттерны? я тебя не понимаю, а вот ты себя явно понимаешь

причем тут паттерны? я тебя не понимаю, а вот ты себя явно понимаешь

Ну паттерны - это часть подхода, как и всеобщий язык