Здравствуйте, IT, Вы писали:
VD>>Вроде как включается и отключается через .editorconfig IT>Можешь не пробовать. В общем, достаточно забить на эти предупреждения и всё будет нормально компилироваться. К тому же IDE0055 — это не только "if(", а вообще любое форматирование, включая, например, лишние пробелы при табличном форматировании
Ага, так "форматирование портится" из-за табличного форматирования? Ре-шарпер же пробовал это как-то решить, вы его не используете или не работает как нужно?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
IT>>Не, это сразу в сад. Мне такого счастья не надо. Я уже задолбался реджектить пул-реквесты, в которых 80% изменений — это случайное форматирование чужого кода. Я уж лучше с "if(" поживу.
_FR>А тут интересно — почему так получается? Если есть .editorconfig со всему нужными для форматирования настройками, как так получается, что кто-то случайно портит форматирование?
Во-первых, есть умолчательные настройки студии, которые могут тебе отформатировать весь метод, если ты где-то в середине поставил '}' или ';'. И этим настройкам чихать на .editorconfig.
Во-вторых, есть код, которые появился на свет, когда .editorconfig ещё не появился даже как идея.
_FR>В любом слуйчае исправления форматирования должны идти отдельно и "случайно" попадать в пул реквест не должны (ну должны же люди смотреть, что они коммитят и что получвается в пулреквесте).
Некоторые люди даже не знают как посмотреть, что они коммитят. Случайные исправления форматирования не должны попадать в код, это так. Но насчёт умышленных исправлений — большой вопрос. Тут у нас выбор, либо вообще этих изменений не делать, т.к. никто для этого специальный PR делать не будет, либо что-то исправлять по ходу дела. Выбор в том хочешь ли ты бесконечно накапливать всякое говнище или усложнять ревью и портить историю.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, _FRED_, Вы писали:
_FR>Ага, так "форматирование портится" из-за табличного форматирования? Ре-шарпер же пробовал это как-то решить, вы его не используете или не работает как нужно?
Форматированием занимаются студия по её настройкам, она же по настройкам .editorconfig, решарпер, исходя из своих соображений, некоторые расширения студии. Периодически это конфликтует и глючит.
Короче, всё это здорово, существует так много классных возможностей и замечательных идей. Но один небольшой макрос решил бы мою проблему гораздо эффективнее и в точности так, как мне нужно. Можно было бы даже ошибку выдать адресную, конкретно этому челу типа "Паша, сцуко, поставь пробел после 'if'"
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Но это же не значит, что ты не можешь использовать табличное форматирование в своём собственном коде?
В проекте где работают десятки программистов собственного кода нет. Старый код, что я написал в табличном стиле остается таковым, но новый пишу без табличного форматирования, как это не было противно.
В немерловом коде везде табличное форматирование но мы там с Хардкейсом практически только вдвоём код пишем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, hi_octane, Вы писали:
S>>> Мне например понравилось https://github.com/dotnet/runtime/issues/81741 _>>Чёт мне после таких PR, того как легко через рефлексию залазят в приватные поля, и т.д., кажется что вся идея с Member Visibility на уровне CLR провалилась, и её надо уверенно отламывать. В итоге на уровне CLR все поля и свойства изначально должны быть public, а проверки на видимость должны делаться на уровне компилятора. Собственно они уже начали уползать в компилятор (file class это оно). S> Ну вот иногда нужен доступ к внутренностям. Это бывает нечасто, раз в пятилетку. Приходится через рефлексию. S>Это может быть и ошибки при невозможности поменять версию или всевозможные хаки.
В ди изначально по дефолту все члены публичные и нормально получилось.
питон жс вообще без модификаторов живут и ничего.
Здравствуйте, vaa, Вы писали:
S>> Ну вот иногда нужен доступ к внутренностям. Это бывает нечасто, раз в пятилетку. Приходится через рефлексию. S>>Это может быть и ошибки при невозможности поменять версию или всевозможные хаки. vaa>В ди изначально по дефолту все члены публичные и нормально получилось. vaa>питон жс вообще без модификаторов живут и ничего.
Ну для примера ненужно показывать ненужные методы в интеллисенсе.
Разные защиты для тех же readonly. Но иногда когда нельзя, но ооочень хочется, то можно!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Ну для примера ненужно показывать ненужные методы в интеллисенсе.
Как всегда, все придумано до нас https://lispmethods.com/libraries.html#accessing-symbols-in-other-packages
Мне кажется организация в пакеты/модули и импорт/экспорт вполне могут с этим справится.
S>> Ну для примера ненужно показывать ненужные методы в интеллисенсе. vaa>Как всегда, все придумано до нас vaa>https://lispmethods.com/libraries.html#accessing-symbols-in-other-packages vaa>Мне кажется организация в пакеты/модули и импорт/экспорт вполне могут с этим справится.
По мне так область видимости интереснее. Как говорится про вкус и цвет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, hi_octane, Вы писали:
_>Я дико извиняюсь, но, например, async/await, yield return, foreach и using это всё макросы. И даже '.' (точка) это тоже макрос — её смысл радикально меняется в зависимости от того, какие сущности она разделяет. Просто создатели компилятора сделали эти макросы ковыряясь ручками в кишках компилятора. А могли бы за то же время сделать вменяемое API для макросов, и затем всё самое полезное просто "само" появилось бы в nuget.
15 лет приходится объяснять одно и тоже. Источник "макросов" типа async один, центральный. И на собеседовании, к примеру, я могу спросить как этот async устроен и что, собственно, он делает. И если не получу внятного ответа и понимания — смело можно чуваку отказывать.
А вот если вместо async будет hi_octane_name_macro, то с вероятностью 99.99% я ничего вразумительного от собеседуемого не получу.
А теперь представляем что таких макросов в проекте десятки и понимаем, что зефирно-немерлевые замки могут работать либо при одном разработчике, лимбо при сверхстабильной команде, у которой состав не меняется годами. Во всех остальных случаях произойдет строго то, что произошло с Nitra.
Здравствуйте, VladD2, Вы писали:
VD>Код выражает некоторую мысль (алгоритм, структуру данных, понятие и т.п.). Если в языке нет достаточных средств для удобного их выражения, то начинаются выразительные проблемы. Мы получаем больше плохого кода. Его трудно читать из-за того, что он рассредоточен, или многословен, или не выразителен. У нас может не быть возможности провести проверки во время компиляции и проверки уезжают в рантайм или вообще отсутствуют. В итоге код становится говном. VD>Если макрос (расширение языка) позволяет избежать этих проблем, код с их использованием становится лучше. Его становится проще читать, писать и поддерживать.
Лежат заключённые на нарах, после отбоя. Вдруг, из одного угла слышится: 14.
Вся камера начинает заливисто смеяться.
Из другого угла: 37.
Камера опять ржёт.
Новенький арестант спрашивает у лежащего рядом старожила:
— А че это за цифры из-за которых все в камере смеются?
Старый отвечает:
— Понимаешь, кореш, давно тут сидим, все анекдоты уже рассказали и, чтобы не повторять каждый раз, присвоили им номера. Называет кто-то номер анекдота, а все остальные вспоминают и смеются.
Новенький на всю камеру: 19!
Тишина, никто не смеётся.
Он опять к старожилу:
— А что анекдот под №19 не смешной?
Старожил:
— Понимаешь, анекдот то смешной, просто есть люди которые умеют анекдоты рассказывать, а есть те которые не умеют!
Здравствуйте, IT, Вы писали: IT>ЗЫ. У нас в команде есть один девелопер, который упорно не ставит пробел между 'if' и '('. Любые воздействия и задушевные беседы бесполезны. Один единственный макрос решил бы эту проблему раз и навсегда.
а зачем этот пробел нужен?
если это корпоративный стандарт, то есть форматтеры
С Core тоже свое веселье — версии очень быстро протухают, совсем Кумары рехнулись. Так-то переход нужный — обратно совсем не тянет.
Visual 2019 уже на помойку — .NET 5 уже ушел из поддержки и куча пакетов его забыла, а более поздних рантаймов на него не завезли.
2022 на помойку отправиться в 2024 видимо — 6 и 7 версии протухнут, а 8 — которой еще нет по-любому будет привязана к новой студии.
По поводу билд сервера — а зачем там студия? вроде можно без нее все собирать голым SDK нужной версии.
Optimized ThreadStatic field access for GC-type
Field accesses that are marked as ThreadStaticLocal are now optimized for primitive types. With PR#85619, we have optimized reference type field access as well. These changes have led some really good improvements in a number of benchmarks: (133 on windows/arm64, 23 on windows/x64, 16, 13, 11 improvements).
Arm64
Preview 5 also brings a number of few peephole optimizations:
With PR#85032, we enabled peephole optimization to replace str pair with stp.
With PR#85657, we enabled peephole optimization of replacing pair of ldr/str with ldp/stp inside prolog.
General optimizations
Our team has released a number of general optimizations that include:
x64 instructions such as movzx, movsx and movsxd have been optimized in PR#85780, which slightly improved code-gen by eliminating more redundant mov instructions.
PR#86318 improved constant folding for some frozen objects (non-GC objects). It reduced the size of the generated code by almost 10 times (e.g., 424 bytes to 41 byte).
AVX-512
PR#85389 enabled AVX-512 for block unrollings, which increases ranges where it previously used to fallback to memcpy/memset and reduced the execution time by half.
Various integer intrinsics are enabled for AVX512F, AVX512BW and AVX512CD, PR#85833.