Почему “явность” считают Хорошей Вещью?

Явное и неявное - все зависит от того, что вы скрываете и что показываете.

В идеале вы раскрываете концепции, которые либо пользователь заботится или должен заботиться (хотят они того или нет).

Преимущество откровенности в том, что легче отследить и узнать, что происходит, особенно в случае неудачи. Например, если я хочу вести журнал, у меня может быть API, который требует явной инициализации с каталогом для журнала. Или я могу использовать значение по умолчанию.

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

Неявное поведение почти всегда является результатом сокрытия информации от потребителя. Иногда это правильно, например, когда вы знаете, что в вашем окружении есть только один «ответ». Однако лучше знать, когда вы скрываете информацию и почему, и убедитесь, что вы позволяете своим потребителям работать ближе к их уровню намерений и не пытаясь скрыть элементы существенной сложности.

Часто неявное поведение является результат "самонастраивающихся" объектов, которые смотрят на свое окружение и пытаются угадать правильное поведение. Я бы избегал этого шаблона в целом.

Одно правило, которому я, вероятно, следую в целом, заключается в том, что для данного API любая операция должна быть явной или неявной, но никогда не комбинация. Либо сделайте операцию чем-то, что должен делать пользователь, либо сделайте ее чем-то, о чем им не нужно думать. Когда вы смешаете эти два, вы столкнетесь с самыми большими проблемами.

Хорошая абстракция не скрывает сложностей, она принимает решения, которые лучше оставить компилятору не на вашу тарелку.

Рассмотрите сборку мусора: сложности с освобождением ресурсов делегируются сборщику мусора, который (предположительно) лучше подготовлен для принятия решения, чем вы, программист. Он не только избавляет вас от принятия решения, но и принимает лучшее решение, чем вы сами.

Явность (иногда) хороша, потому что она позволяет принимать определенные решения, которые в некоторых случаях лучше оставить программисту. не выполняются автоматически менее квалифицированным агентом. Хороший пример - когда вы объявляете тип данных с плавающей запятой на языке c-type и инициализируете его целым числом:

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

Иногда, хотя каркасы или конструкции скрывают от нас вещи, которые они не должны делать, и это делает вещи менее ясными. Иногда определенная информация или настройки скрыты от нас, и поэтому мы не знаем, что происходит . Делаются предположения, которых мы не понимаем и не можем определить. Поведение случается, что мы не можем предсказать.

Инкапсуляция: хорошо. Скрытие: плохо. Чтобы сделать правильный звонок, нужен опыт. Там, где принадлежит логика, она должна быть явной.

Пример: Однажды я удалил около 90 строк кода из серии из дюжины кодов за страницами; код доступа к данным, бизнес-логика и т. д., которые здесь не принадлежали. Я переместил их на базовые страницы и ключевой бизнес-объект. Это было хорошо (инкапсуляция, разделение задач, организация кода, разделение и т. Д.).

Затем я взволнованно осознал, что могу удалить последнюю строку кода со многих из этих страниц, переместив ее на базовая страница. Это была строка, которая брала параметр из url и передавала его бизнес-объекту. Хорошо право? Ну нет, это было плохо (я скрывался ). Эта логика была здесь, хотя на каждой странице была почти одна и та же строка. Он связывает намерение пользовательского интерфейса с бизнес-объектом. Он должен быть явным . Иначе я прятался, а не инкапсулировал. С этой строкой кто-то, смотрящий на эту страницу, будет знать, что эта страница делает и почему; без него было бы сложно определить, что происходит.

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

Речь идет о выражении намерений. Читатель не может сказать, было ли значение по умолчанию оставлено по ошибке или намеренно. Явность снимает это сомнение.

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

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

Например, в C ++ есть ключевое слово const для переменные, значения которых никогда не должны изменяться. Если программа пытается изменить эти переменные, компилятор может заявить, что код, скорее всего, неправильный.

Фреймворки и т. Д. Могут быть как явными, так и скрывать сложность, предлагая правильные абстракции для выполняемой работы.

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

Скрытие сложности не эквивалентно неявному. Неявность привела бы к тому, что код будет понятен только тому, кто его написал, поскольку попытка понять, что происходит под капотом, в данном случае сродни реверс-инжинирингу.

Явный код теоретически имеет шанс быть верным. В этом отношении неявный код никогда не имеет шансов.

Явный код обслуживается, неявный код - нет - это ссылки на предоставление правильных комментариев и тщательный выбор идентификаторов.

Опора на поведение по умолчанию скрывает важные детали от людей, которые плохо знакомы с языком / фреймворком / чем-то еще.

Подумайте, как трудно понять код Perl, который в значительной степени полагается на сокращение. люди, не знающие Perl.

В некоторых случаях «магия» противоположна - как в «тогда происходит чудо» .

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

Явность желательна в контексте прояснения читателю вашего кода того, что вы собираетесь делать.

Есть много примеров, но все дело в том, чтобы не оставлять сомневаюсь в ваших намерениях.

например, Они не очень явные:

while (condition);

int MyFunction()

bool isActive;         // In C# we know this is initialised to 0 (false)

a = b??c;

double a = 5;

double angle = 1.57;

, но это:

while (condition)
    /* this loop does nothing but wait */ ;

private int MyFunction()

int isActive = false;  // Now you know I really meant this to default to false

if (b != null) a = b; else a = c;

double a = 5.0;

double angleDegrees = 1.57;

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

Целью перемещений фреймворков является удаление дублирования в коде и упрощение редактирования фрагментов без нарушения целостности. Когда у вас есть только один способ сделать что-то, например, сказать SUM (x, y); Мы точно знаем, что это будет делать, нет причин когда-либо его переписывать, а если нужно, то можете, но это маловероятно. Противоположным этому являются языки программирования, такие как .NET, которые предоставляют очень сложные функции, которые вам часто придется переписывать, если вы делаете что-либо, кроме очевидного простого примера.