Использование синтаксического сахара / встроенная функциональность - PullRequest
Новая
       7

Использование синтаксического сахара / встроенная функциональность

3 голосов
/ 14 мая 2010

Я был занят более глубоким изучением таких вещей, как многопоточность, взаимоблокировка и т. Д. Книга нацелена как на псевдокод, так и на код C, и я был занят поиском реализаций таких вещей, как блокировки Mutex и мониторы.

Это напомнило следующее; в C # и на самом деле .NET у нас есть много синтаксического сахара для ведения дел. Например, (.NET 3.5): 

lock(obj)
{
   body
}

Идентично: 

var temp = obj;

Monitor.Enter(temp);

try 
{ 
   body 
}
finally 
{ 
   Monitor.Exit(temp); 
}

Конечно, есть и другие примеры, такие как конструкция using() {} и т. Д. Мой вопрос состоит в том, когда это более применимо, чтобы «идти в одиночку» и буквально кодировать вещи самостоятельно, чем использовать «синтаксический сахар» в языке? Стоит ли когда-нибудь использовать свои собственные пути, а не людей, которые более опытны в языке, на котором вы кодируете?

Я вспоминаю, что не использовал объект Process в блоке using, чтобы помочь с некоторыми многопоточными проблемами и бесконечным циклом перед этим. Я все еще чувствую себя грязно из-за того, что там нет конструкции с использованием.

Спасибо

Кайл

Ответы [ 4 ]

11 голосов
/ 14 мая 2010

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

Если вам необходимо что-то контролировать вручную (например, манипулировать IEnumerator<T> вместо использования foreach), тогда да, отбросьте синтаксический сахар. В противном случае, быть идиоматичным - это хорошо.

7 голосов
/ 14 мая 2010

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

2 голосов
/ 14 мая 2010

В C # это выражение linq: 

var filteredCities =
    from city in cities
    where city.StartsWith("L") && city.Length < 15
    orderby city
    select city;

является синтаксическим сахаром для (и эквивалентен): 

var filteredCities =
  cities.Where(c => c.StartsWith("L") && c.Length < 15))
    .OrderBy(c => c)
    .Select(c => c);

Если вы хорошо знаете C #, последнюю версию гораздо проще разобрать, чем первую; вы можете точно видеть, что он делает под капотом.

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

1 голос
/ 14 мая 2010

Ваш пример невозможности использования конструкции using - мое самое распространенное отклонение от новых подходов, доступных на языках .Net и в фреймворке. Лишь во многих случаях область видимости объекта IDisposable находится за пределами одной функции.

Однако знание о том, что делают эти ярлыки, все еще важно, как никогда. Я действительно думаю, что многие люди просто не будут распоряжаться объектом, если они не могут обернуть его в using, потому что они не понимают, что он делает и что делает проще.

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

Edit:

Я думал об этом и решил, что считаю using просто вводящим в заблуждение ключевым словом. foreach делает именно то, на что это похоже, тогда как using не означает для меня, что на самом деле происходит. У кого-нибудь есть мысли по этому поводу? Что, если бы они использовали ключевое слово disposing; Как вы думаете, это будет яснее?

...