Версия PascalABC.NET 3.4


#41

Если работает, к чему Ваш пост и разговоры про issure? Или речь о украшающих пробельчиках каких-то?


#42

Ну я же так и написал, речь идёт про форматирование.


#43

Какое может быть форматирование внутри литерала? Чтобы потом эти форматирующие пробелы попали на вывод?


#44

Они внутри {}, поэтому они не попадут на вывод. Это выводит True:

begin
  writeln($'---{1+1}---' = $'---{1 + 1}---');
end.

#45

Все, что в одинарных апострофах - это для компилятора литерал, не подлежащий обработке. Исключение - если перед литералом стоит $. В этом случае компилятор должен найти пары фигурных скобок и “раскрутить” их содержимое, как выражение. И Вы хотите, чтобы такую же работу могла делать обычная программка, форматирующая пробелами код “для красоты”?


#46

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


#47

Ну, запишите в Issue. Конечно, это не предмет первой необходимости, поэтому повисит видимо достаточное время


#48

А вот такое

 var s:=$'1+2+{1*2+3*(3-5.5/(2+1/4)-4*(2+2/3))}+2+1';

Вы тоже надеетесь получить в виде

var s := $'1+2+{1 * 2 + 3 * (3 - 5.5 / (2 + 1 / 4) - 4 * (2 + 2 / 3))}+2+1';

или как?

Это делает код IDE все больше, уже и так система стала загружаться почти втрое дольше, чем год назад. А главное - это действительно мало кому нужно. Форматирование, как оно реализовано в выражениях - зло, поскольку делает строку настолько длинной, что ее “заворачивает” в самом неподходящем месте и корежит наглядность кода. Из-за этого я вообще не пользуюсь форматированием.


#49

Не переживайте, в этом нет проблемы. Этот код является синтаксическим сахаром над

begin
var s:=String.Format('1+2+{0}+2+1',1*2+3*(3-5.5/(2+1/4)-4*(2+2/3)));
end.

Попробуйте его отформатировать - там будет всё нормально


#50

Тут понятно, тут форматируется арифметическое выражение, а не внутреннее содержимое литерала. В результате “форматирования” код существенно удлинился, оно уже не поместится даже здесь в строку, а наглядность лучше не стала.

begin
  var s := String.Format('1+2+{0}+2+1', 1 * 2 + 3 * (3 - 5.5 / (2 + 1 / 4) - 4 * (2 + 2 / 3)));
end.

Я считаю, что форматирование в целом сделано не очень удачно. Вот так я пишу код

begin
  var (s,p):=(0,1);
  for var i:=1 to 5 do begin
    s+=i; p*=i
    end;
  Println(s,p)
end.

Визуально структура понятна по отступам: один уровень отступов имеют операторы var, for, Println. В цикле четко просматривается тело и закрывающая его операторная скобка, образующие второй уровень отступов. После форматирования получаем

begin
  var (s, p) := (0, 1);
  for var i := 1 to 5 do 
  begin
    s += i;p *= i
  end;
  Println(s, p)
end.

Код удлинился на строку, операторные скобки, которые фактически являются телом цикла, вылезли на один уровень с заголовком цикла. А в теле цикла два оператора присваивания слиплись. И что, это хорошо?


#51

То что begin ставит на новой строчке и на уровне for это, по моему, стиль в который форматирует. А вот слипание s += i; и p *= i явно не должно происходить, будет #954.


#52

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


#53

Ну да, это там вечная война))

void p1() {
  return
}

и

void p1()
{
  return
}

Но, кстати, заметьте, } тут имеет отступ p1, в отличии от end в вашем примере.

Но как я и сказал, это стиль. По хорошему надо возможность делать расширения для IDE, со своим форматированием, цветам и т.п. А пихать поддержку всех стилей написания вместе - по моему, не лучшая идея. Хотя последние слово, насчёт “считать ли это ошибкой”, конечно, за разработчиками.


#54

Оно сделано как положено, а не “не очень удачно”.


#55

Что-то незаметно.

Нет, код становится читабельнее. Во всех средах так и это даже не обсуждается. А форматировать или нет, это, конечно, ваше право.


#56

Как положено КЕМ? Покажите мне, где указывается КАК ПОЛОЖЕНО.

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


#57

Я думаю, нам надо написать стандарт форматирования, тогда вопросы отпадут.

Похожий документ был в Delphi - мы в своё время многое оттуда брали. Сейчас воспроизвести этот документ к сожалению у меня не представляется возможным.

Должен ещё заметить, что задача форматирования - достаточно сложная, поэтому задать опции на все случаи жизни не получится.

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


#58

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

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.

Вот он же, отформатированный.

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.

На этот раз begin … end по разным строкам не разбежались (слава богу!), а if зачем-то выровняло по else (и предшествующему if), хотя логически этот if выполняется по ветке else, а не является самостоятельным того же уровня, как предшествующий if. Слов не хватает, может быть, на блок-схеме будет яснее.

А вот еще одна метаморфоза форматирования этого же кода.

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.

Теперь форматирование сработало так:

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.

В этот раз форматирование не стало переносить begin на отдельную строку (есть в мире справедливость!), но вот end все равно выдвинуло на уровень if. Визуально if получился как бы завершен этим end, а else выглядит чужим, т.е. как бы совсем не принадлежащим if. И так два раза. Вот за такие штуковины мне форматирование и не нравится. Ты пишешь код, чтобы его отступы со взгляда, мгновенно прорисовывали вложенность операторов, а оно тебе картинку ломает.

Конечно, это сугубо мое мнение. Начинающим программировать (а также лентяям) автоформатирование очень даже полезно.


#59

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


#60

Давайте без этой болтовни про “во всех”. Конкретные примеры листингов, пожалуйста. Не левых, которые пишут кто-то, а от более-менее серьезных авторов.