В последних версиях C# появилась возможность статического импорта класса
и последующего вызова статик методов как локальных методов.
Не ухудшит ли это читабельность кода?
В том же Oberon-2 напротив ввели жесткое правило обращаться к процедурам только через имя модуля(можно задавать короткие алиасы)
в отличии от Modula-2 где можно импортировать отдельные функции и вызывать их по частичному имени.

using static System.Console;

WriteLine();

using System;

Console.WriteLine();

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

Р>В последних версиях C# появилась возможность статического импорта класса
Р>и последующего вызова статик методов как локальных методов.
Р>Не ухудшит ли это читабельность кода?
Р>В том же Oberon-2 напротив ввели жесткое правило обращаться к процедурам только через имя модуля(можно задавать короткие алиасы)
Р>в отличии от Modula-2 где можно импортировать отдельные функции и вызывать их по частичному имени.

Р>

Р>using static System.Console;

Р>WriteLine();
Р>

По мне вот так лучше:
Р>

Р>using System;
Р>Console.WriteLine();
Р>

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

По мне так это упрощения, для конкуренции с питонами и прочими.
Понятно, что для чтения проще Console.WriteLine();
Но есть классы которые используются часто, и можно опускать имя класс.
По мне так разницы особой нет.

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

Р>В последних версиях C# появилась возможность статического импорта класса
Р>и последующего вызова статик методов как локальных методов.
Эмм, не то, чтобы совсем в последних. Это — С# 6.0, примерно 8 лет назад. На всякий случай: актуальная версия C# — 11.

Р>Не ухудшит ли это читабельность кода?
Ну, раз за 8 лет не ухудшило, то и дальше не ухудшит.

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

Р>В последних версиях C# появилась возможность статического импорта класса
Р>и последующего вызова статик методов как локальных методов.
Р>Не ухудшит ли это читабельность кода?

Пример: в файлах, где много работы с деревьями выражений (например, System.Linq.Expressions) из делаю:

using static Expression;

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

  internal Expression<Comparison<T>> BuildCompare(ParameterExpression x, ParameterExpression y) {
    var expressions = Expressions.ConvertAll(item => item.AsCompare(this, x, y));
    expressions.Reverse();

    Expression seed = Return(LabelTargetReturn, expressions[0]);
    var expression = expressions.Skip(1).Aggregate(seed, static (acc, value) => IfThenElse(NotEqual(Assign(Compare, value), Zero), ReturnCompare, acc));
    var body = IsValueType
      ? expression
      // if((object)x == (object)y) {
      //   return 0;
      // } else if((object)x == null) {
      //   return -1;
      // } else if((object)y == null) {
      //   return 1;
      // } else {
      //   return expression;
      // }//if
      : IfThenElse(ReferenceEqual(x, y), ReturnZero, IfThenElse(IsNull(x), ReturnMinusOne, IfThenElse(IsNull(y), ReturnOne, expression)));
    var block = Block(CompareVariables, body, LabelZero);
    return Lambda<Comparison<T>>(block, x, y);
  }

отсутствие Expression. мне кажется в таких случаях значительно улучшает понимание того, что делается и как. Информации меньше (но достаточно) — значит и проще.

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

Переменные/функции программист так же может называть почти как хочет и этим тоже можно как упростить понимание и поддержку кода или сильно усложность