Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pzz, Вы писали:

Pzz>>Это если ему позволят в дизайн. А если "вот тебе бага, надо починить за два дня", то какой уж там дизайн?
S>Дизайн тоже бывает разного уровня.
S>Ну, то есть code style, действительно, смотреть большого смысла не имеет — его всё равно можно зафорсить тулчейном. Хотя, скажем, если кандидат показывает такое

Автор: Khimik
Дата: 15.06.24

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

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

Безусловно, это был очень полезный человек в команде, и его там очень ценили.

Здравствуйте, Sharov, Вы писали:

S>Что с этим кодом не так, помимо того, что не скомпилируется? Кроме шуток, особых косяков не вижу,
Упс, написал какую-то фигню. Думал одно, писал другое.
Вот "правильный неправильный" код. Сделаем проблему более очевидной:

    public static IEnumerable<int> GetAccumulatingSum(this IEnumerable<int> source)
    {
        if(source == null)
            throw new ArgumentNullException(nameof(source));
        var s = 0;
        foreach(var v in source)
            yield return s += v;

    }

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Что с этим кодом не так, помимо того, что не скомпилируется? Кроме шуток, особых косяков не вижу,
S>Упс, написал какую-то фигню. Думал одно, писал другое.
S>Вот "правильный неправильный" код. Сделаем проблему более очевидной:
S>

S>    public static IEnumerable<int> GetAccumulatingSum(this IEnumerable<int> source)
S>    {
S>        if(source == null)
S>            throw new ArgumentNullException(nameof(source));
S>        var s = 0;
S>        foreach(var v in source)
S>            yield return s += v;

S>    }
S>

Я выше же отписал по возможной проблеме.

Здравствуйте, sergii.p, Вы писали:

SP>слышал одну абстрактную мысль, что если человек не имеет pet проектов, то у него нет страсти к программированию.

Они у меня есть, но они помойка полнейшая, потому что предназначены для одного расчёта как бы, там архитектура нахрен не нужна

Здравствуйте, Sharov, Вы писали:
S>Я выше же отписал по возможной проблеме.
Приведённая вами особенность — чисто стилистическая, я бы её не стал относить к проблемам совсем.
А вот то, что валидация аргументов происходит вовсе не в вызове метода — штука принципиальная. У нас потенциально в стектрейсе вообще может не быть того фрейма, в котором в метод передаётся null, потому что итерировать мы начнём где-то в километрах кода от инициализации.

Здравствуйте, Worminator X, Вы писали:
WX>Код с гитхаба может спионерить кто угодно (либо попросить написать за оплату знакомого студента). Это совершенно ничего не говорит о навыках кандидата.
Это настолько идиотская идея, что её нет смысла обсуждать.
Ну вот спионерил кто-то код с гитхаба или у знакомого студента — дальше-то что? Это поможет дойти до собеседования. В первые 15 минут выяснится, что кандидат соврал, а это поставит крест на дальнейшем трудоустройстве.
Потому что с плохим знанием шарпов ещё можно претендовать на позицию, хоть и джунскую, а с готовностью врать работодателю даже уборщиком не возьмут. Всё, убер-план пал под натиском реальности.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:
S>>Я выше же отписал по возможной проблеме.
S>Приведённая вами особенность — чисто стилистическая, я бы её не стал относить к проблемам совсем.
S>А вот то, что валидация аргументов происходит вовсе не в вызове метода — штука принципиальная. У нас потенциально в стектрейсе вообще может не быть того фрейма, в котором в метод передаётся null, потому что итерировать мы начнём где-то в километрах кода от инициализации.

Я так понял, что речь идет о ленивости, но каким образом мы потеряем нужный(проблемный) фрейм?
Приведенный фрагмент кода лежит в основе как минимум Linq to objects, поэтому не совсем понятно, что с ним не так...

Здравствуйте, sergey2b, Вы писали:

S>Это не работает, проверял много раз
S>Нагло врут с честным выражением лица

Достаточно сказать, что очень не любишь ковыряться в чужом коде и увольняешься с таких мест — сами не захотят брать.

Здравствуйте, undo75, Вы писали:


U>

U>Спасибо за отклик!
U>Прошу, по возможности, прислать примеры вашего актуального кода на C#, чтобы не тратить не это время при созвоне.

U>подмывает ответить этим https://www.youtube.com/watch?v=3t5DB0JRcgA
U>вот реально что они хотят увидеть? накопипастить годного кода я могу. чего им это даст? конкретизировали бы хотябы какая область интересна

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

 private static readonly string resultJsonFileName

кончаешь и понимаешь, что писал-то код жесткий профессионал.

Здравствуйте, Sharov, Вы писали:
S>Я так понял, что речь идет о ленивости, но каким образом мы потеряем нужный(проблемный) фрейм?
Очень просто.
Ошибка — в функции GetAS(). В стектрейсе её нет:

Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'source')
at X.GetAccumulatingSum(IEnumerable`1 source)+MoveNext()
at Program.Print(IEnumerable`1 s)
at Program.Main()

S>Приведенный фрагмент кода лежит в основе как минимум Linq to objects, поэтому не совсем понятно, что с ним не так...
Нет, не лежит.

Однако у MS в code analysis rules (https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview) на этот счёт похоже ничего нет.

Из сторонних анализаторов кода:
https://rules.sonarsource.com/csharp/tag/yield/RSPEC-4456/

Therefore it is recommended to split the method into two: an outer method handling the validation (no longer lazy) and an inner (lazy) method to handle the iteration.

Здравствуйте, m2user, Вы писали:

M>Однако у MS в code analysis rules (https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview) на этот счёт похоже ничего нет.
Ну, я-то простой сибирский парень, программировать учился в поле, а не по отчётам анализаторов.

M>https://rules.sonarsource.com/csharp/tag/yield/RSPEC-4456/
M>

M>Therefore it is recommended to split the method into two: an outer method handling the validation (no longer lazy) and an inner (lazy) method to handle the iteration.

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:
S>>Я так понял, что речь идет о ленивости, но каким образом мы потеряем нужный(проблемный) фрейм?
S>Очень просто.
S>Ошибка — в функции GetAS(). В стектрейсе её нет:
S>

S>Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'source')
S> at X.GetAccumulatingSum(IEnumerable`1 source)+MoveNext()
S> at Program.Print(IEnumerable`1 s)
S> at Program.Main()

Ну да, особенности ленивых вычислений.

S>>Приведенный фрагмент кода лежит в основе как минимум Linq to objects, поэтому не совсем понятно, что с ним не так...
S>Нет, не лежит.

Это не то:
https://github.com/microsoft/referencesource/blob/51cf7850defa8a17d815b4700b67116e3fa283c2/System.Core/System/Linq/Enumerable.cs#L899
https://github.com/microsoft/referencesource/blob/51cf7850defa8a17d815b4700b67116e3fa283c2/System.Core/System/Linq/Enumerable.cs#L1265

Здравствуйте, Sharov, Вы писали:


S>Это не то:
S>https://github.com/microsoft/referencesource/blob/51cf7850defa8a17d815b4700b67116e3fa283c2/System.Core/System/Linq/Enumerable.cs#L899
S>https://github.com/microsoft/referencesource/blob/51cf7850defa8a17d815b4700b67116e3fa283c2/System.Core/System/Linq/Enumerable.cs#L1265
Да, не то. Обратите внимание, что в первом примере указанный вами метод — приватный. Он вызывается из публичного метода, где, собственно, и происходит энергичная проверка аргументов.
Во втором примере опять же указанный метод не является iterator block. Он вызывает iterator block, который снаружи не виден и в нём проверки аргументов не происходит.

Здравствуйте, Sinclair, Вы писали:

S>>Это не то:
S>>https://github.com/microsoft/referencesource/blob/51cf7850defa8a17d815b4700b67116e3fa283c2/System.Core/System/Linq/Enumerable.cs#L899
S>>https://github.com/microsoft/referencesource/blob/51cf7850defa8a17d815b4700b67116e3fa283c2/System.Core/System/Linq/Enumerable.cs#L1265
S>Да, не то. Обратите внимание, что в первом примере указанный вами метод — приватный. Он вызывается из публичного метода, где, собственно, и происходит энергичная проверка аргументов.
S>Во втором примере опять же указанный метод не является iterator block. Он вызывает iterator block, который снаружи не виден и в нём проверки аргументов не происходит.

Верно, подзабыл уже детали из этой статьи:

We’ve just hit a design flaw in C#. Iterator blocks in C# simply don’t work nicely when you want to split execution between "immediate" (usually for validation) and "deferred". Instead, we have to split our implementation into two: a normal method for validation, which then calls the iterator method for the deferred processing:

https://codeblog.jonskeet.uk/2010/09/03/reimplementing-linq-to-objects-part-2-quot-where-quot/