Сделайте анализ потока управления работающим в индуктивном случае

Question

Проверки работоспособности, подобные следующим, появляются в моем коде в длинной последовательности:

if (!someCheck() /* dependent on previously assigned variables */) {
    console.log(someMessage);
    return;
}
someVariables = something; // dependent on someCheck being successful

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

Я хотел сократить этот шаблон, чтобы он был менее повторяющимся (не нужно писать if , return, console.log, ..., каждый раз). Я подумал о следующей схеме:

let varOne = null,
    varTwo = null,
    varThree = null;

let checkAssign = [
    [() => true,                     () => { varOne = { prop: "hello" }; varTwo = ["myData"]; }, "msg1"],
    [() => varOne.prop.length === 5, () => { varThree = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; },      "msg2"],
    [() => varTwo[0] === "myData",   () => { /* no assignments here, can be empty */ },          "msg3"],
]

for (let [check, assign, message] of checkAssign) {
    if (check()) assign();
    else {
        console.log(message);
        return;
    }
}

Тем не менее, я предполагаю, что анализу потока слишком сложно понять индуктивный принцип, где псевдоматематически говоря, { assign#1, ..., assign#N-1 } --> variables_for_check#N, и что они только выполнено по порядку. Поэтому, хотя во время компиляции должно быть ясно, будут ли переменные назначаться перед проверкой, я должен был бы добавить проверку во время выполнения, чтобы утверждать проверку типов, что все в порядке (по общему признанию, могут быть некоторые здесь не очень подробные решения, может быть, мне было бы все равно, если оно действительно короткое).

Есть ли способ, чтобы средство проверки типов понимало ситуацию здесь, или другой способ express Ситуация, когда средство проверки типов понимает это, но все же не настолько многословно, как цепочка из многострочных операторов if?

• Функционально-ориентированный подход, где assign#N-1 возвращает все данные для check#N, была бы другой идеей. Тем не менее, мне кажется, не менее сложно заставить проверку типов утверждать, что список #N-1 --> #N (очень похожая проблема imho).

• Не думаю, что это актуально, но для уточнения ситуации: программа анализирует и модифицирует код (например, babel, eslint, ...). Проверки обычно проверяют, имеет ли часть AST, которая просматривается в настоящее время, определенную структуру, при извлечении данных. Примеры пар проверки / назначения:

  • "существует ли X?" перед "readableNameForX = X"
  • "свойство Y именуется идентификатором, а не литералом?" (({ prop: value }) против ({ "prop": value })), до readableNameForY = identifier

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