Невнимание Слепота — Отсутствие очевидного

Синтаксический шум

По словам Мартина Фаулера , синтаксический шум это:

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

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

Тем не менее, эта статья о SourceForge указывает на то, что синтаксический шум, частично вводимый сложным синтаксисом, сокращает оба пути:

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

Давайте посмотрим на пример «шумного» PHP. Это было изменено из исходного примера Java, используемого Полом В. Гомером:

 public function calcIndex() 
{ 
    $weightedSum = 0; $bondCount = 0; $status = false;
    for ($i = 0; $i < count($this->bonds); $i++) {
        $status = $this->yieldCalc($this->bondInfo, self::YIELD, true,
            $this->bondFacts);
        if ($status != true) {
            throw new YieldCalculationException(
                $this->getCalcError()); 
        } 
        $weightedSum += $this->calcWeight($this->bondFacts,
            Weight::NORMAL); 
        $bondCount++;
    } 
    return $weightedSum / $bondCount; 
}

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

 $weightedSum = 0.0; $bondCount = 0; $status = false;

Здесь мы инициализируем три переменные: $weightedSum$bondCount$status Возможно, будет понятнее, если мы инициализируем их по отдельности в отдельных строках.

 for ($i = 0; i < count($this->bonds); $i++) {

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

Вместо этого может быть более простой подход: foreach

 foreach ($this->bonds as $item) {

Намерение гораздо понятнее, и вводить ошибки труднее.

 $weightedSum += $this->calcWeight($this->bondFacts, Weight::NORMAL);
$bondCount++;

Здесь мы имеем компактный подход к присваиванию переменных ( +=++ Да, это занимает меньше места, но обязательно ли это понятно или показательно? Это зависит от вас, но, может быть, следующее будет яснее:

 $weightedSum = ($weightedSum + $this->calcWeight($this->bondFacts,
    Weight::NORMAL)); 
$bondCount = ($bondCount + 1);

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

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

Пробелы — вертикальные и горизонтальные

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

 public function __construct( 
    DbAdapter $zendDb, $tableName = null, 
    $identityColumn = null, $credentialColumn = null, 
    $credentialTreatment = null) 
{ 
    $this->zendDb = $zendDb; 

    if (null !== $tableName) { 
        $this->setTableName($tableName); 
    } 

    if (null !== $identityColumn) { 
        $this->setIdentityColumn($identityColumn); 
    } 

    if (null !== $credentialColumn) { 
        $this->setCredentialColumn($credentialColumn); 
    } 

    if (null !== $credentialTreatment) { 
        $this->setCredentialTreatment($credentialTreatment); 
    } 
}

При правильном использовании вертикальных пробелов мы можем видеть, какой код логически связан. Мы можем легко идентифицировать различные условия на основе $tableName$identityColumn$credentialColumn$credentialTreatment Кроме того, правильное использование кода горизонтального пробела (отступа) дает коду очень логичную и понятную структуру.

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

Представьте, что все это объединено без группировки, отступов или общего порядка. Будет ли это так легко понять?

Вывод

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

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

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

• Невнимательная слепота — Википедия
• Что делает код трудным для понимания?
• Невнимание Слепота — Пользовательский опыт и дизайнеры интерфейса — Enchant
• Невнимательная слепота: отсутствует на виду — CodeProject

Изображение Дэйва Стоукса через Flickr