Здравствуйте, 8bit, Вы писали:

8>Здравствуйте, Relayer, Вы писали:

R>>Здравствуйте, PPA, Вы писали:

PPA>>>У арксиса есть исключения наа базе регулярных выражений.
PPA>>>имхо этого достаточно.

R>>вы с нормальным дифером не работали. наш например PasDiff сразу говорит что поменялось в интерфейсной части и в реализации. причем мне не надо парить голову — я вижу детальный отчет типа: добавилось поле в классе, изменилась декларация метода, изменилась имплементация и тп тд. клик мышью — я позиционируюсь на код и вижу его до и после изменений.

8>А на кой это все нужно ? Вы видимо не работали там где применяются дифы/мержевалки по назначению

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

Здравствуйте, 8bit, Вы писали:

8>А на кой это все нужно ? Вы видимо не работали там где применяются дифы/мержевалки по назначению

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

Здравствуйте, AndreiF, Вы писали:

AF>Здравствуйте, 8bit, Вы писали:

8>>Во многих проектах прописан стандарт, как программист должен писать код.
8>>И там вполне может быть прописано что пробелы между "x > y" должны быть.
8>>Так что полезено видеть и такие мелочи.

AF>Полезно иметь возможность выбирать — видеть такие мелочи или нет

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

Здравствуйте, AndreiF, Вы писали:

AF>1. фильтровать несущественные изменения (например, изменения в форматировании кода, или переставленные по порядку методы в классе, или переставленные атрибуты в XML файлах)

При работе с reflection'ами, в Java (не скажу точно, но в C#, вроде тоже), порядок методов "может оказать влияние на работу программы". Это связанно с тем, что при получении набора методов класса, они получаются в виде массива, в котором содержатся в порядке объявленния в классе. Лично мне, пришлось на днях писать сериализатор на java, результатом работы которого был, как можно догадаться, xml-файл. И при изменении порядка методов в классе сериализуемого объекта, менялся и порядок атрибутов в XML файле. А в некоторых ситуациях, это может быть критично.

Повторюсь и скажу, что подобные "оптимизации" надо иметь возможность настраивать. И наверное, даже не только на уровне всей программы, а и иметь возможность настраивать параметры сравнения для конкретной (сейчас просматриваемой) пары-тройки файлов.

Здравствуйте, spbAngel, Вы писали:

По хорошему, если в парсере XML-документов фиксирован порядок атрибутов (именно атрибутов, а не элементов), в котором они должны идти — то это нарушает стандарт XML. Ну а если по практичному, то опции конечно должны быть

Здравствуйте, AndreiF, Вы писали:

AF>По хорошему, если в парсере XML-документов фиксирован порядок атрибутов (именно атрибутов, а не элементов), в котором они должны идти — то это нарушает стандарт XML. Ну а если по практичному, то опции конечно должны быть

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

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