Класс Powershell: свойство против именования аргументов - PullRequest
Новая
       27

Класс Powershell: свойство против именования аргументов

2 голосов
/ 26 марта 2020

В этом старом Microsoft do c Ричард Сиддавей заявляет

Я использую имена переменных, которые напоминают имя свойства. Эти переменные являются произвольными, и вы можете использовать любое допустимое имя переменной - избегайте имени свойства, хотя!

В результате получается конструктор, который выглядит так: 

RStimezone(
   [int]$idx,
   [string]$desc,
   [string]$tmzn,
   [bool]$crnt
   ){
   $this.Index = $idx
   $this.Description = $desc
   $this.Timezone = $tmzn
   $this.Current = $crnt
}

Но есть не объясняется ПОЧЕМУ это соглашение об именовании предлагается. Насколько я могу судить, проблема с областью действия отсутствует, поэтому использование аргументов с тем же именем, что и у свойств класса, не должно вызывать проблем. И на мой взгляд, это гораздо более читаемый подход. 

RStimezone(
   [int]$index,
   [string]$description,
   [string]$timezone,
   [bool]$current
   ){
   $this.Index = $index
   $this.Description = $description
   $this.Timezone = $timezone
   $this.Current = $current
}

Я что-то здесь упускаю?

1 Ответ

3 голосов
/ 26 марта 2020

Примечание: я лично предпочитаю описательные имена параметров, даже если они сталкиваются с именами свойств - но здесь вопрос не в этом:)

Я, очевидно, не могу говорить за Ричарда Я могу придумать две причины, по которым кто-то решил бы избегать столкновения имен параметров методов с именами свойств:

Как избежать будущего рефакторинга "gotcha!"

Данная статья была написана в сентябре 2016!

Примерно в то же время код Visual Studio все еще находился в зачаточном состоянии, а LSP (Протокол языкового сервера) едва был стандартизирован.

Это означало, что во многих редакторах - панель PowerShell ISE и, возможно, SAPIEN PowerShell Studio - правильная и контекстная «языковая поддержка» для PowerShell была чисто синтаксической и во многих случаях основывалась на ненадежных токенизаторах на основе регулярных выражений.

. NET редакторы на основе может воспользоваться новым API Parser / AST, представленным в PowerShell 3.0, но это было немного сложным делом, так как язык после 3.0 также сделал некоторые синтаксические допуски в отношении неявных аргументов атрибутов, обработки литеральных массивов и т. д. c .

Таким образом, к моменту появления версии 5.0 единственным существенным изменением в языке стало введение определений типа class и enum, очень немногие редакторы быстро реализовали полную поддержку этих типов. новые (и немного сложные) функции - потому что остальная часть языка была практически те же самые и многие синтаксические анализаторы sorta работали.

Какое это имеет отношение к параметрам метода именования и свойствам класса, говорите вы?

Представьте себе, что синтаксический анализатор пытается выполнить операцию переименования переменной для параметра $myString в (допустимом) конструкторе ниже: 

class MyClass
{
    [string]
    $myString

    MyClass([string]$myString)
    {
        $this.myString = $myString
    }
}

Наивный инструмент рефакторинга оставит вас с этим (недопустимым) конструктором: 

class MyClass
{
    [string]
    $renamedString

    MyClass([string]$renamedString)
    {
        $this.myString = $renamedString
    }
}

Car go -culting

Как отмечается в статье, Ричард, уже в 2016 году, проработал в ИТ более 25 лет, и я могу заверить вас, что он потратил значительную часть своей карьеры, работая с C#.

Если я покажу вам эквивалентную схему в C#, может стать очевидным, почему этот конкретный c тип столкновения / перекрытия именования не рекомендуется, с точки зрения читабельности: 

class MyClass
{
  private string myString;

  MyClass(string myString)
  {
    this.myString = myString.Substring(Math.Min(1, myString.Length));
  }

  string SomeMethod()
  {
    return myString;
  }
}

В приведенном выше классе пустой токен myString теперь представляет два различных значения в зависимости от того, на какое тело метода вы смотрите. Если вы думаете, что «это не странно, я могу прочитать это очень хорошо», пройдите тест Тьюринга, потому что вы можете быть компилятором; -)

...