Множественный вывод ошибок компиляции


#1

Может, стоит перейти на систему отображения всех найденных ошибок при компиляции, нежели отображения их по одной? Пользователям будет легче - им будет предоставляться список всех ошибок, которые надо исправить, в каком порядке это делать - будут решать они. На данный момент неудобно то, что приходится несколько раз перекомпилировать проект, чтобы отыскать все ошибки компиляции. PascalABC.Net не Visual Studio, в которой без перекомпиляции будут появляться подсказки, указывающие где ошибки. Это, в первую очередь, трата личного времени пользователей. Я, конечно, понимаю, что могут опять прозвучать аргументы в стиле «и без этого жить можно», но, все-же, хочу обратить внимание на то, что это предложение выдвинуто ради повышения удобства пользования IDE PascalABC.Net целевой аудиторией.

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

Желаете ли Вы, чтобы это было реализовано?

  • Да
  • Нет
  • Нейтральная точка зрения

0 голосов

В случае поддержки моего предложения придётся добавить третий пункт «Все ошибки» в «Показывать ошибки»:

Имелось ввиду добавление данной возможности, а не удаление отображения «по одной ошибке».


#2

Это неверное по своей сути предложение. Известно, как приходится мучиться новичкам, когда они видят листинг из 100 ошибок в простой программе C++. А всё потому что какая-то переменная не описана


#3

Это было актуально на ЭВМ 2-3 поколения, когда задания, заранее подготовленные на перфокартах, запускались оператором или шли в пакете. Надо было получить результат за минимум прогонов, поэтому компилятор выдавал любые ошибки и сообщения, которые только мог выловить.


#4

Имеет смысл с остановом на первой критической ошибке, а так больше похоже на аналитическое задание нашим студентам: “Здесь минимум 12 ошибок – исправляй!”


#5

Я тоже хотел об этом написать, но потом прочитал внимательно:

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


#6

Да, согласен, что это не должно быть так по умолчанию. Это сможет быть включено по желанию пользователя. То есть, он сам будет выбирать как ему удобней. Так, PascalABC.Net, используется различной аудиторией - от новичков до продвинутых пользователей. Первой группе, как правильно заметил @NRA, будет лучше показывать по одной ошибке. Второй - по несколько.


#7

Вот простенький пример с С++

Summary
#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) на месте закрывающей квадратной скобки занесли фигурную. И вот, что по этому поводу написал компилятор:

Неужели именно это нужно “продвинутому пользователю” и ради вот такого разработчики станут вносить множественные изменения в компилятор?

Категорически против.


#8

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

Пример на C#:

namespace Test
{	
	interface I1
	{
		void P();
	}
	
	class T1 : I1
	{
	}
	
	class T2 : I1
	{
	}
	
	class Program
	{	
		public static void Main(string[] args)
		{
		}
	}
}

В данном случае полезно видеть все ошибки. Отображение всех ошибок в данном случае даёт возможность пользователю выбирать какую первой из них исправлять. Следует также обратить внимание на то, что ошибки независимы.


#9

Вы себе сейчас противоречите. Сначала утверждаете, что пользователь продвинутый (т.е. достаточно искушенный в вопросах программирования), а затем приводите пример с множественными логическими (!) ошибками, которых продвинутый пользователь обычно не допускает. Как раз для продвинутого пользователя более характерны не логические ошибки, а механические описки.


#10

Нет противоречий. Это очень упрощенный пример. Реальный код, конечно, таким не будет. Но, общая идея такая.

В большом проекте трудно за всем уследить. Поэтому и могут возникать такие нелепые ошибки.


#11

Если трудно, значит неверно спроектировано. Попытайтесь поверить опыту человека, много и очень долго работающего даже с очень большими проектами.


#12

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


#13

Безусловно! Но ради этого перелопачивать код работающего компилятора я бы лично не стал. Собственно, разработчики уже высказались:


#14

Пускай опрос пока повисит открытым. Закрою позже. Хотелось бы, чтобы больше участников приняло участие в беседе.


#15

Это Ваше право, как автора топика. Я лишь высказал свое мнение, чтобы не быть “голословным отрицаловом”.

Таким, как Портос в "Трех мушкетерах: “А я дерусь… потому что я дерусь!”


#16

Только они высказывались в контексте программирования новичков:

Известно, как приходится мучиться новичкам, когда они видят листинг из 100 ошибок в простой программе C++.

:slight_smile:


#17

Потому что, как никто другой, они сознают, с какими целями создавали PascalABC.NЕТ и что случаи разработки в нем средних и больших проектов будут носить скорее единичных характер.


#18

Да, ниша программирования PascalABC.Net - обучение. Но, не всегда в ней пишут только новички. К сожалению, очень мало человек участвует в беседе… И сделать какие-то выводы на этой основе не удастся. Очень печально, что малому количеству людей интересен PascalABC.Net как инструмент профессионального программирования. Надеюсь, что эта ситуация со временем исправится.


#19

Печально, да. Но причины этого известны. В мэйнстриме Паскаль умер. Делать на нем коммерческий проект под заказ сейчас не позволит ни один нормальный менеджер. Сравните уровень поддержки С++/С# и PascalABC.NЕТ. Если в PascalABC.NET что-то неверно работает (а выяснить это можно только при массовой эксплуатации программ), что дальше делать? Проект, в котором постоянно висит сотня issure - ставить под промышленное использование? Это же почти самоубийство! Проект без документации, без руководства по языку. Вы о чем?


#20

Я, как и Вы, надеюсь, что ситуация с сотней Issue исправится.

Она есть, только местами не совпадает с действительностью… Мы в этом уже не раз убеждались. Думаю, что @Sun_Serega был прав, сказав, что её надо переделать полностью.