Возникает вопрос: не лучше ли?
Ответ таков: это зависит от обстоятельств, поскольку подобные вещи полностью субъективны. Если только вы не являетесь машиной и не думаете так же.
Да, некоторая проблема согласованности была бы удовлетворительной, если бы мы применяли begin / end для ВСЕХ составных операторов, но там, где окружающие языковые элементы уже обеспечивают естественное вложение, это совершенно излишне.
Рассмотрим оператор CASE:
// "Sensible" syntax
case VALUE of
1: DoSomething;
2: begin
DoSomethingElse;
DoMore;
end;
else
DoForAllOtherValues;
DoMore;
end;
В сравнении с менее разумным, но более последовательным и «логичным»:
case VALUE of
1: DoSomething;
2: begin
DoSomethingElse;
DoMore;
end;
else
begin
DoForAllOtherValues;
DoMore;
end;
end;
Обратите внимание, что последний «конец» - это часть «дела». Без этого не обойтись.
Я почти уверен, что в ранней версии Chrome (которая стала Oxygene, а затем Prism) на самом деле это был необходимый синтаксис для оператора case. Если так, то это уже не так. По-видимому, здравый смысл возобладал.
По моему личному мнению, удовлетворение требований OGoSC (Objective Gods of Syntactic Consistency) вызывает раздражение у, возможно, меньшего, но на самом деле более актуального для вас и меня, SGoHRaC (субъективных богов человеческой читабельности и понимания).
Хотя во многих случаях может показаться иначе, мы, люди, на самом деле не машины. Нам не нужно упрощать и сводить правила к минимально согласованному набору, чтобы можно было анализировать текст и понимать его. Нам нужны некоторые правила, но мы можем обрабатывать больше, поскольку наше большое преимущество перед машинами - это свобода мысли, которая освобождает нас от строгого режима синтаксиса и структуры, особенно там, где такой синтаксис и структура являются посторонними до точки избыточности.
Как в этом случае.
Если вы сделаете ошибку, которую компилятор не может интерпретировать, он сообщит вам об этом каждый раз при компиляции. Но компилятор не будет благодарить вас за то, что вы сделали код «более легким для чтения» (компилятор просто следует заданным правилам - это не облегчает компилятору «чтение» кода путем изменения правила, которым он уже может с радостью следовать).
Если вы вводите произвольные правила, которые затрудняют чтение (не потому, что правила более или менее инвариантны / согласованы, а потому, что вы вводите согласованную структуру, которая сама содержит больше шума и избыточной информации, которую необходимо фильтровать), вы заплатите цена в производительности человека.
Фактически, эти «более простые», более «последовательные» правила могут фактически усложнить задачу ... еще раз рассмотрим оператор CASE.
Чтобы это составное начало / конец имело смысл, мы должны сделать «case» отдельным оператором, а не частью пары case / end, поэтому ВСЕ из них должны быть допустимым синтаксисом:
case VALUE of
1: DoSomething;
2: DoSomethingElse;
case VALUE of
1: DoSomething;
2: DoSomethingElse;
else
DoOther;
case VALUE of
1: DoSomething;
2: begin
DoSomethingElse;
DoMore;
end;
else
DoOther;
case VALUE of
1: DoSomething;
2: begin
DoSomethingElse;
DoMore;
end;
else
begin
DoOther;
DoMoreOther;
end;
case VALUE of
1: DoSomething;
2: begin
DoSomethingElse;
DoMore;
end;
Вы можете не согласиться, но мне кажется, что внезапно этот более последовательный синтаксис на самом деле приводит к МЕНЬШЕЙ непротиворечивости в реальном коде, даже несмотря на то, что правила, которым пишется код, соответствуют большей согласованности.
person
Deltics
schedule
07.01.2011
