Может, стоит перейти на систему отображения всех найденных ошибок при компиляции, нежели отображения их по одной? Пользователям будет легче - им будет предоставляться список всех ошибок, которые надо исправить, в каком порядке это делать - будут решать они. На данный момент неудобно то, что приходится несколько раз перекомпилировать проект, чтобы отыскать все ошибки компиляции. PascalABC.Net не Visual Studio, в которой без перекомпиляции будут появляться подсказки, указывающие где ошибки. Это, в первую очередь, трата личного времени пользователей. Я, конечно, понимаю, что могут опять прозвучать аргументы в стиле «и без этого жить можно», но, все-же, хочу обратить внимание на то, что это предложение выдвинуто ради повышения удобства пользования IDE PascalABC.Net целевой аудиторией.
Я не требую сиюминутной реализации этой возможности. Я понимаю, что это, возможно, будет трудно реализовать. Я предлагаю сначала её обсудить, затем, если разработчики будут согласны, создать Issue.
Желаете ли Вы, чтобы это было реализовано?
Да
Нет
Нейтральная точка зрения
0голосов
В случае поддержки моего предложения придётся добавить третий пункт «Все ошибки» в «Показывать ошибки»:
Это неверное по своей сути предложение. Известно, как приходится мучиться новичкам, когда они видят листинг из 100 ошибок в простой программе C++. А всё потому что какая-то переменная не описана
Это было актуально на ЭВМ 2-3 поколения, когда задания, заранее подготовленные на перфокартах, запускались оператором или шли в пакете. Надо было получить результат за минимум прогонов, поэтому компилятор выдавал любые ошибки и сообщения, которые только мог выловить.
Имеет смысл с остановом на первой критической ошибке, а так больше похоже на аналитическое задание нашим студентам: “Здесь минимум 12 ошибок – исправляй!”
Да, согласен, что это не должно быть так по умолчанию. Это сможет быть включено по желанию пользователя. То есть, он сам будет выбирать как ему удобней. Так, PascalABC.Net, используется различной аудиторией - от новичков до продвинутых пользователей. Первой группе, как правильно заметил @NRA, будет лучше показывать по одной ошибке. Второй - по несколько.
#include <iostream>
using namespace std;
int main()
{
const int n = 10;
int a[n];
int min, max, imin, imax;
srand(time(0));
for (int i = 0; i < n; i++)
{
a[i]=rand() % 5 +1;
cout << a[i] << " ";
}
cout <<"\n";
min = a[0];
imin = 0;
imax = 0;
max = a[0];
for (int i = 1; i < n; i++)
{
if (a[i}<min)
{
min = a[i];
imin = i;
}
if (a[i]>=max)
{
max = a[i];
imax = i;
}
}
a[imin] = max;
a[imax] = min;
for (int i = 0; i < n; i++)
{
cout << a[i] << " ";
}
cout <<"\n";
return 0;
}
Тут всего лишь при наборе текста случайно зацепили Shift и в операторе if (a[i}<min) на месте закрывающей квадратной скобки занесли фигурную.
И вот, что по этому поводу написал компилятор:
Конечно, Вы правы в том, что из-за опечатки может возникнуть гора ошибок. Но, не все ошибки происходят из-за этого. Есть также и логические ошибки (пример ниже).
Пример на C#:
namespace Test
{
interface I1
{
void P();
}
class T1 : I1
{
}
class T2 : I1
{
}
class Program
{
public static void Main(string[] args)
{
}
}
}
В данном случае полезно видеть все ошибки. Отображение всех ошибок в данном случае даёт возможность пользователю выбирать какую первой из них исправлять. Следует также обратить внимание на то, что ошибки независимы.
Вы себе сейчас противоречите. Сначала утверждаете, что пользователь продвинутый (т.е. достаточно искушенный в вопросах программирования), а затем приводите пример с множественными логическими (!) ошибками, которых продвинутый пользователь обычно не допускает. Как раз для продвинутого пользователя более характерны не логические ошибки, а механические описки.
Не всегда. Тут еще не стоит забывать про человеческий фактор. То, что у профессионалов вероятность логических ошибок меньше, чем у начинающих - да, это так. Но, полностью исключать вероятность возникновения логических ошибок у профессионалов тоже нельзя.
Потому что, как никто другой, они сознают, с какими целями создавали PascalABC.NЕТ и что случаи разработки в нем средних и больших проектов будут носить скорее единичных характер.
Да, ниша программирования PascalABC.Net - обучение. Но, не всегда в ней пишут только новички. К сожалению, очень мало человек участвует в беседе… И сделать какие-то выводы на этой основе не удастся. Очень печально, что малому количеству людей интересен PascalABC.Net как инструмент профессионального программирования. Надеюсь, что эта ситуация со временем исправится.
Печально, да. Но причины этого известны. В мэйнстриме Паскаль умер. Делать на нем коммерческий проект под заказ сейчас не позволит ни один нормальный менеджер. Сравните уровень поддержки С++/С# и PascalABC.NЕТ. Если в PascalABC.NET что-то неверно работает (а выяснить это можно только при массовой эксплуатации программ), что дальше делать? Проект, в котором постоянно висит сотня issure - ставить под промышленное использование? Это же почти самоубийство! Проект без документации, без руководства по языку. Вы о чем?
Я, как и Вы, надеюсь, что ситуация с сотней Issue исправится.
Она есть, только местами не совпадает с действительностью… Мы в этом уже не раз убеждались. Думаю, что @Sun_Serega был прав, сказав, что её надо переделать полностью.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021