Форматирование сделано хорошо. Так сделано во всех языках, но претензии к нему, судя по всему, только у Вас. Лично мне читать Ваш код было тяжело, мягко выражаясь.
Давайте без этой болтовни про “во всех”. Конкретные примеры листингов, пожалуйста. Не левых, которые пишут кто-то, а от более-менее серьезных авторов.
Дело не в авторах, а в форматировании кода IDE. Вам в пример все C-подобные(и не только) языки в VisualStudio. Даже в веб-средах разработки(cpp shell) такое форматирование.
Опять “все…”
И что именно Вас смущает?
Я боюсь, что да. Вот наш стандарт форматирования вложенных if
for var i := 0 to n - 1 do
if a[i, i] < 0 then
begin
sn += a[i, i];
pn *= a[i, i]
end
else if a[i, i] > 0 then
begin
sp += a[i, i];
pp *= a[i, i]
end;
В том документе о стандарте форматирования Delphi - что-то близкое.
Begin в конце строчки как стандарт - это ужасно.
Кстати, может, автоформатированием это обеспечить трудно - там не контекстный алгоритм - он по-моему не запоминает вложенные if.
1 лайк
Я пока что пришел к выводу, что мне более импонирует компромиссный стиль и программа должна выглядеть так:
begin
var n := ReadInteger('n=');
var a := MatrRandom(n, n, -50, 60); a.Println;
var (sp, sn, pp, pn) := (0, 0, int64(1), int64(1));
for var i := 0 to n-1 do
if a[i, i] < 0 then
begin sn += a[i, i]; pn *= a[i, i] end
else
if a[i, i] > 0 then
begin sp += a[i, i]; pp *= a[i, i] end;
Println(sn, pn, sp, pp)
end.
Возможно, если обсуждение продолжится, появятся еще какие-то вариации. Ну не хочет так форматировать IDE - напишу свой маленький препроцессор)))
И, конечно же, если в операторных скобках будет хотя бы 3-4 оператора, end уйдет в отдельную строку под begin.
Видите - на вкус и цвет. Мы конечно делали форматирование для ленивых школьников
3 лайка
Согласен. Если begin-end находятся под друг другом код легче воспринимается, нежели когда begin на отдельной строке.
1 лайк
А в С++ и подобных языках совершенно нормально писать
if (a>b) {
c=2.5;
d=-3.51;
}
где как раз { - тот же begin, } - end.
А причём тут C++? Паскалеподобные и C-подобные языки - это абсолютно разные синтаксисы. Можно сколь угодно долго говорить о схожести, например, PascalABC.NET и C#, но это всё-же разные языки. Ваше сравнение некорректно.
1 лайк
Речь о том, что хорошо, когда форматирование отражает блочную структуру. И неважно, как записывается начало блока - скобкой или словом, важно, в каком месте стоит этот ограничитель. Нельзя привязываться к языку, если речь идет о записи алгоритма, а ведь хорошо оформленная программа - это самодокументируемая запись алгоритма на алгоритмическом языке, понятном и человеку, и компилятору.
Тоже ненормально. Почитайте Макконелла
А в Java?
На мой взгляд, если речь об одном символе {, то не страшно его оставлять на предыдущей строке. begin нельзя оставлять, потому что это 5/80 строки. Хотя может у меня просто профдеформация из-за частой работы из консоли.
Константа вычисляется в какой-то момент в программе и потом гарантируется, что она будет неизменна при использовании.
Но тогда почему нельзя так:
type
t1=class
class function f1 := 0;
end;
const
c1=t1.f1;
begin end.
А там - мы это уже обсуждали - есть какие-то ограничения, накладываемые грамматикой.
Вообще, константным выражением называется выражение, которое может стоять в инициализаторе константы. Это не может. Значит, не константное.
Почитайте стандарты форматирования на разных языках.
В конкретной фирме эти стандарты могут меняться - лишь бы все писали одинаково - даже несогласные.
Но вы же там написали что им можно и не константное присваивать:
Но при создании можно любым выражением - это ничего не нарушает
Почитал, прежде чем писать. Перечитал еще раз. Вот два скрина с одной страницы (один аналогичный пример с case выбросил в середине страницы, чтобы было не так мелко):
Вот страница целиком, чтобы никто не заподозрил в подлоге 
Шаблонные типы не даёт напрямую приводить к записям:
type
r1 = record end;
procedure p1<T>(o:T);
begin
//var a1 := r1(o);//Ошибка
var a2 := r1(object(o));//А так позволяет
end;
begin
p1(new r1);
end.
Так и задумано ведь?
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021