Я подумал, почему же все таки свойства, и понял вот что:
В отладке это действительно важно, и это частая ситуация, когда вам нужно посмотреть, где происходит присвоение. Под "залазит в код" я имел ввиду его изменение. Сторонний, очень условно, это ваш коллега, который использует, но не пишет, эту библиотеку.
Вот о чем я не написал, не здесь, ни в посте, так это о единообразии. Может быть, это вкусовщина, или даже мания, но меня бесит когда его нет. Когда в одном месте свойства, в другом поля. Или хуже того в одном классе и то и другое. Может быть это мое личное, но не порядочек.
Есть все таки семантическая разница, между полем и свойством. Чисто с технической точки зрения ее нет (если property Name: string read FName write FName), но она как суслик - есть.
Вам со стороны виднее, спорить не буду. По фактической стороне:
Нет, я пишу не один, совсем даже не один. Вот этот рефакторинг (только рефакторинг) делает аж цельных три человека. Просто на мне большая нагрузка, это да. А в целом, над продуктом работает несколько десятков человек, и это только разработчиков, не считая тестирования и прочего...
Поверьте, я менял технологический стек, и у меня в багаже много всего разного, и очень древнего, и не слишком, в том числе и модного, молодежного. Тут вы ошиблись.
Мне это тоже интересно. Я вот думаю, может тут дело в том, что они добавят это в базовую оконную систему винды. Как сейчас есть: просто окна (SDI) и MDI, будет ещё TDI. Тогда хоть как-то понятно, почему это стоит обсуждать.
Вот тут я бы поспорил, смотреть результаты запроса в отладчике - то ещё удовольствие. SQL вы всегда можете запустить в какой-нибудь консоли и играться с ним сколько угодно. Кроме того, обратывать ручками вы себе можете позволить только если точно знаете сколько у вас данных и их совсем немного.
Я совсем не дизайнер, вообще бекендер, но вот разве это хорошо, так писать: "Изменить стиль заголовка карточки с 24 на 28 px"? Как то очень декларативно.
Например это глобальный стиль для всех элементов определенного стиля, и тогда где-то в css уже есть: global-style {padding: 28px;}
Хоть коротко, надо давать ремарку "почему". Я так думаю.
Может я что-то не понял, с SAP не знаком, но вы серьезно считаете, что выполнить 1 + А запросов лучше чем 1? А если есть В, то вообще жесть. Про Г я молчу. Или в САПе какой то другой SQL?
Все БД вовсе не используют плавающую запятую (возможность такая есть, обычно, но я не встречал в реальной жизни). У нас в системе приложены титанические усилия, что бы все вычисления проводились над типами с фиксированной точностью - ибо финансовые вычисления, и флоаты для них смерть. Вот и причина.
Не буду, я лучше буду мечтать о том времени, когда мои мутные мысли наконец приобретут чу́дную ясность, и я наконец придумаю ЯП на котором можно будет просто, лаконично и однозначно объяснить тупой железяке что же я от нее хочу, и более не писать, из года в год, тонны очень похожего кода 😥
Не читал, но осуждаю! Да, я не пробовал Copilot, и не буду. Дело в том, что по моему не скромному мнению, этот самый ИИ, совсем не ИИ - термин выбран не удачно. Всё-таки, то что сейчас называют ИИ не более чем система распознавания образов. И так как в ней нет интеллекта, ничего она за вас не напишет, максимум предложит набор некоторых самых распространенных в интернете вариантов (если не ошибётся).
Для пояснения мысли, представим что все сели за копилот, идут годы, он обучается на собственных результатах, какой будет результат? Сможет он развиваться, привносить что-то новое? Нет. Т.ч. проблема в самой идее, в лучшем случае - это интересный вариант автокомплита, не более.
Статья уж больно короткая, выглядит как "ни о чём". Потому и поняли не правильно, т.к. тема не модная уже бог знает сколько лет. Лет 25 назад было море книжек, в которых диаграммы, их виды, были описаны несколько лучше, дана соответствующая тер.база. Ну и IDEF надо было бы упомянуть, как более распространенную альтернативу.
Я тоже про технические, но эти эйчары, они такие эйчары... Приходится объяснять не про ""эпитет" система на рынке", а про реальность, зачастую довольно скучную, и конкретные технические аспекты.
Все собеседования разные, зависит от вакантной позиции, культуры принятой в организации... Тут приведен неплохой набор советов общего характера, и тем не менее, есть то, что на мой взгляд пропущено и с чего я всегда начинаю собеседование:
Первым делом я рассказываю о компании, о позиции, о требованиях и условиях, о перспективах. Иногда на этом собеседование заканчивается, мы оба экономим время.
Основные концепции языков программирования. Р. У. Себеста.
За исключением триграфоф всё тоже самое относится к большинству ЯП. Т.ч. наименование книги можно обобщить: типовые ошибки новичков.
Я так и не понял - это шутка или серьёзно. Я не знаю, я не умею, я не понимаю, мне подсказали...
Вот уж не думал, что тема свойств будет так обсуждаться. Проходная совершенно. Забавно.
Про паттерны, я же не написал что не надо их использовать. Весь пост про умеренность.
Рефактоинги - я писал: пользуйтесь. У меня, лично, не зашло. Про Replace спорить не буду, сомнительный путь, но работает иногда.
Про MESSAGE FATAL не знал, спасибо!
Exit(Result) - это если у вас, семерки нет в списке совместимостей ;)
Я подумал, почему же все таки свойства, и понял вот что:
В отладке это действительно важно, и это частая ситуация, когда вам нужно посмотреть, где происходит присвоение. Под "залазит в код" я имел ввиду его изменение. Сторонний, очень условно, это ваш коллега, который использует, но не пишет, эту библиотеку.
Вот о чем я не написал, не здесь, ни в посте, так это о единообразии. Может быть, это вкусовщина, или даже мания, но меня бесит когда его нет. Когда в одном месте свойства, в другом поля. Или хуже того в одном классе и то и другое. Может быть это мое личное, но не порядочек.
Есть все таки семантическая разница, между полем и свойством. Чисто с технической точки зрения ее нет (если
property Name: string read FName write FName), но она как суслик - есть.Вам со стороны виднее, спорить не буду. По фактической стороне:
Нет, я пишу не один, совсем даже не один. Вот этот рефакторинг (только рефакторинг) делает аж цельных три человека. Просто на мне большая нагрузка, это да. А в целом, над продуктом работает несколько десятков человек, и это только разработчиков, не считая тестирования и прочего...
Поверьте, я менял технологический стек, и у меня в багаже много всего разного, и очень древнего, и не слишком, в том числе и модного, молодежного. Тут вы ошиблись.
А затем, что бы другому разработчику не надо было лазить в ваш код.Написали название с типом и Ctrl+Shift+C, все готово. Вам, что жалко?
Про паттерны, я все таки про что-то более крупное, мне не приходило в голову, что пропертю можно обозвать паттерном, хотя наверное можно.
Мне это тоже интересно. Я вот думаю, может тут дело в том, что они добавят это в базовую оконную систему винды. Как сейчас есть: просто окна (SDI) и MDI, будет ещё TDI. Тогда хоть как-то понятно, почему это стоит обсуждать.
Как страшно жить, сочувствую
Вот тут я бы поспорил, смотреть результаты запроса в отладчике - то ещё удовольствие. SQL вы всегда можете запустить в какой-нибудь консоли и играться с ним сколько угодно. Кроме того, обратывать ручками вы себе можете позволить только если точно знаете сколько у вас данных и их совсем немного.
Я совсем не дизайнер, вообще бекендер, но вот разве это хорошо, так писать: "Изменить стиль заголовка карточки с 24 на 28 px"? Как то очень декларативно.
Например это глобальный стиль для всех элементов определенного стиля, и тогда где-то в css уже есть: global-style {padding: 28px;}
Хоть коротко, надо давать ремарку "почему". Я так думаю.
Может я что-то не понял, с SAP не знаком, но вы серьезно считаете, что выполнить 1 + А запросов лучше чем 1? А если есть В, то вообще жесть. Про Г я молчу. Или в САПе какой то другой SQL?
Детский сад какой-то
Все БД вовсе не используют плавающую запятую (возможность такая есть, обычно, но я не встречал в реальной жизни). У нас в системе приложены титанические усилия, что бы все вычисления проводились над типами с фиксированной точностью - ибо финансовые вычисления, и флоаты для них смерть. Вот и причина.
Не буду, я лучше буду мечтать о том времени, когда мои мутные мысли наконец приобретут чу́дную ясность, и я наконец придумаю ЯП на котором можно будет просто, лаконично и однозначно объяснить тупой железяке что же я от нее хочу, и более не писать, из года в год, тонны очень похожего кода 😥
Не читал, но осуждаю! Да, я не пробовал Copilot, и не буду. Дело в том, что по моему не скромному мнению, этот самый ИИ, совсем не ИИ - термин выбран не удачно. Всё-таки, то что сейчас называют ИИ не более чем система распознавания образов. И так как в ней нет интеллекта, ничего она за вас не напишет, максимум предложит набор некоторых самых распространенных в интернете вариантов (если не ошибётся).
Для пояснения мысли, представим что все сели за копилот, идут годы, он обучается на собственных результатах, какой будет результат? Сможет он развиваться, привносить что-то новое? Нет. Т.ч. проблема в самой идее, в лучшем случае - это интересный вариант автокомплита, не более.
А статья говно.
Статья уж больно короткая, выглядит как "ни о чём". Потому и поняли не правильно, т.к. тема не модная уже бог знает сколько лет. Лет 25 назад было море книжек, в которых диаграммы, их виды, были описаны несколько лучше, дана соответствующая тер.база. Ну и IDEF надо было бы упомянуть, как более распространенную альтернативу.
Я тоже про технические, но эти эйчары, они такие эйчары... Приходится объяснять не про ""эпитет" система на рынке", а про реальность, зачастую довольно скучную, и конкретные технические аспекты.
Все собеседования разные, зависит от вакантной позиции, культуры принятой в организации... Тут приведен неплохой набор советов общего характера, и тем не менее, есть то, что на мой взгляд пропущено и с чего я всегда начинаю собеседование:
Первым делом я рассказываю о компании, о позиции, о требованиях и условиях, о перспективах. Иногда на этом собеседование заканчивается, мы оба экономим время.