Как стать автором
Обновить
1
0.1

.NET программист

Отправить сообщение

Принято начинать имя функции с глагола. Иначе получение указателя на функцию начинает странно смотреться.

myDocument.CanEdit

Выглядит абсурдно, если подразумевается редактируемость самого myDocument. Префикс тут если будет, то в виде isEditable. И тут речь про состояние myDocument, а не про пермишны редактирующего. А там уже будет user.canEdit..., разумеется.

сразу же вопрос "Кто что Can?" - это сам объект "can" что-то?

На этот вопрос обычно отвечает контекст, к примеру:

  • user.canDo...

  • validateUserPermissions() { bool canDo... = ...; }

Почему просто не именовать так: canEdit -> Editable

Сам по себе объект редактируемый или кем-то?
Вы предлагаете префикс заменять на суффикс, те же профильные яйца)

Нет проверки инварианта равенства всех сторон.

у Stream могут быть интерфейсы: ..., которые могут быть по-разному скомбинированы.

Справедливости ради, там только три вариации, на которые бросается NotSupportedException: CanRead, CanWrite, CanSeek. То есть интерфейсов будет здесь всего три: IReadable, IWritable, ISeekable.

реально уродство

Вы не видите проблемы с огромным Stream с мешаниной функционала, который еше и опционален, так почему просто список интерфейсов вас огорчает?

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

Технически это можно решить сделав общий интерфейс, объединяющий необходимое (interface IGodStream: IReadable, IWritable, ISeekable {}) и оно будет работать так, как ожидается - недостаток функциональности будет алармить на этапе компиляции.

Другое дело - какой практический смысл иметь перегрузки для совершенно разного функционала? Разве такие методы могут иметь одинаковое имя?

Куда проще просто один if внутри функции воткнуть.

Не проще, т.к. поддержка механизации этой вариативности ложится на наследников, да и на ровном месте рождается абстрактный класс с этими if внутри. Далеко ходить не надо, можно оценить, как это устроено в дотнете.

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

Чем плохо "лепить отдельные интерфейсы"? Ошибки компиляции всегда лучше исключений.

Речь про первый комментарий треда - автор уравнивает минусы с токсичностью. Отсутствие токсичности в данном случае я назвал уважением, как неким базовым отношением к случайному человеку в интернете.

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

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

То есть это уже какой-то неправильный опенсорс? Ок, но он же серьезно портит статистику, на которую опирается ваша статья.

прям так схоже с созданием чего то своего

Решение бизнес-задачи - свое по авторству. А желание рулить проектом - это про любовь к работе PMа, а не про программирование.

решение который придумал ты , а не дядя

Дядя мейнтейнер может отклонить твой PR, если не сойдетесь во взглядах на развитие проекта.

ЗЫ Заходы с "дядями" и свободолюбием уж очень похожи на инфоцыган с "работой на себя, а не на дядю".

Было бы неплохо раскрасить статью прямыми ссылками на эти отчеты и статистики, на которые она ссылается.

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

Это которые с горящими глазами после работы пишут опенсорс или те, которые на каторге изо дня в день за зарплату пишут тот же опенсорс в интересах работодателя? Как отличить одних от других?

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

Тогда нужно идти до конца и запускать софтину под dotnet watch, чтобы там же и код писать.

Далее идет работа с Git, что уже является правильным и нормальным вариантом.

А как между собой связаны dotnet run и Git? И в статье, и в комментарии указываете на некую взаимосвязь между ними.

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

Есть согласованный стандарт и стиль кода команды

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

какая-то вкусовщина

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

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

начались мелкие придирки и постоянные вопросы к реализации.

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

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

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

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

А других не завезли, полноценная поддержка в языке только у него.

Пожалуй, в каждом первом учебнике по Rust его преимущества описываются через недостатки C++. В Java//C# GC и сложность доступа к указателям закрывают все вопросики.
С передачей владения умными указателями и мутабельным алиасингом можно смело продолжать косячить.

Почему-то в C# есть один тип строк.

Теперь голову ломают как вкорячить UTF-8.

программисты на C# не работают с разными кодировками?

Конвертациями в православный UTF-16 и сырым byte[], который валидной строкой быть не обязан.

1
23 ...

Информация

В рейтинге
3 341-й
Зарегистрирован
Активность

Специализация

Software Developer, Fullstack Developer
Senior
C#
Rust