Чего мне часто не хватало (особенно когда нужно было искать источник какого-нибудь старого изменения в системе контроля версий, или объединять бранчи) — это умной утилиты для сравнения файлов, которая могла бы
1. фильтровать несущественные изменения (например, изменения в форматировании кода, или переставленные по порядку методы в классе, или переставленные атрибуты в XML файлах)
2. определять и показывать простые виды рефакторинга (например, переименование метода или переменной)
Существующие утилиты (даже лучшие, как Araxis) обычно показывают слишком много несущественных изменений, и откопать среди них нужное непросто. В общем, найти ничего подходящего мне так и не удалось, и возникло решение разработать такую программу самому. Закавыка здесь конечно в том, что программа должна опознавать и парсить большое количество разных входных форматов (языки программирования и разметки, CSV и так далее), и знать, какие изменения в них важны, а какие нет.
Насколько много людей, которые стали бы покупать такую прогу? (или это только мне одному все время хочется странного? )
Поддержка каких языков нужна в первую очередь?
Здравствуйте, AndreiF, Вы писали:
AF>Существующие утилиты (даже лучшие, как Araxis) обычно показывают слишком много несущественных изменений, и откопать среди них нужное непросто. В общем, найти ничего подходящего мне так и не удалось, и возникло решение разработать такую программу самому. Закавыка здесь конечно в том, что программа должна опознавать и парсить большое количество разных входных форматов (языки программирования и разметки, CSV и так далее)
Все таки сначала получше приглядитесь к арахису.
AF>, и знать, какие изменения в них важны, а какие нет.
Вот это самое интересное
В коде все важно, даже один символ. Ну а если например
не интересны изменения в комментах, так в арахисе их можно отфильтровать при помощи
регулярных выражений.
Здравствуйте, 8bit, Вы писали:
8>В коде все важно, даже один символ.
Далеко не всегда. Например,
if (x>y) {
}
и
if (x > y)
{
}
Когда копаешься в истории, именно такие мелкие изменения больше всего портят кровь. Можно конечно прикрутить к арахису еще и претти-принтер, но это всё — слишком много гемора. Намного лучше, если бы утилита сама умела фильтровать такие вещи.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, 8bit, Вы писали:
8>>В коде все важно, даже один символ.
AF>Далеко не всегда. Например,
AF>
AF>if (x>y) {
AF>}
AF>
AF>и
AF>
AF>if (x > y)
AF>{
AF>}
AF>
AF>Когда копаешься в истории, именно такие мелкие изменения больше всего портят кровь. Можно конечно прикрутить к арахису еще и претти-принтер, но это всё — слишком много гемора. Намного лучше, если бы утилита сама умела фильтровать такие вещи.
Легко ! ставишь галку в опциях Ignore all diference in white space.
Можно отключить разницу между заглавными и маленькими буквами
Можно отключить детализацию, что бы не было пестро, а только целиком строка тебе светиласть,
да еще и цвета можно выставить разные для строк которые были изменены, удалены, не изменены, добавленны.
В арахисе я думаю есть все, разве что уж совсем бредовых идей которые очень экзотичны.
И еще по поводу этого примера.
Во многих проектах прописан стандарт, как программист должен писать код.
И там вполне может быть прописано что пробелы между "x > y" должны быть.
Так что полезено видеть и такие мелочи.
Здравствуйте, AndreiF, Вы писали:
AF>Когда копаешься в истории, именно такие мелкие изменения больше всего портят кровь. Можно конечно прикрутить к арахису еще и претти-принтер, но это всё — слишком много гемора. Намного лучше, если бы утилита сама умела фильтровать такие вещи.
сделать такой дифер можно. я например сделал еще 7 лет назад специализированный дифер для дельфовских сырков (PasDiff Pro). но вначале все уперлось в то что а) нет формальной граматики для дельфи-паскаля б) граматика не сводится к LR(1). пришлось для начала переделать маленько CoCo/R для разбора с возвратами. после этого конечно все сравнительно легко написалось но без граматическго разбора никак. ибо если просто поменяли местами порядок реализации функций — с точки зрения компилятора — порядок не важен. с точки зрения любого текстового дифера — полный кошмар
сказать что это успешный проект я не могу. он конечно себя окупил и продается до сих пор без всякой рекламы и тп с нашей стороны. но это не предмет для суперприбылей. возможно если написать нечто аналогичное для C/C++, VB и C# — может быть оно и пойдет в массы.
AF>Когда копаешься в истории, именно такие мелкие изменения больше всего портят кровь. Можно конечно прикрутить к арахису еще и претти-принтер, но это всё — слишком много гемора. Намного лучше, если бы утилита сама умела фильтровать такие вещи.
"Beyond Compare 2"?
Я пользуюсь программой выше......не частно но в среднем один-два раза в месяц пользуюсь активно.
Она конечно таких вещей как перестановка методов не понимает (хотя если вставлен большой кусок похожего кода можно ручками слинковать метки в файлах), но пробелы, комментарии и прочее может и не показывать либо показывать как несущественные изменения.
Если сделать все что она умеет плюс добавить более интелектуальное распозование некоторых специфических вещей (перестановка методов, перенос описания переменной из середины класса в начала (в яве например) и т.п.) и главное придумать нормальный визуальный трекинг таких вещей, то я бы купил новую программу. НО только при цене порядка доллларов 30.....ибо все же пользуюсь не часто, да и BC меня удолетворяет на 80%.
Здравствуйте, 8bit, Вы писали:
8>Во многих проектах прописан стандарт, как программист должен писать код. 8>И там вполне может быть прописано что пробелы между "x > y" должны быть. 8>Так что полезено видеть и такие мелочи.
Полезно иметь возможность выбирать — видеть такие мелочи или нет
Здравствуйте, AndreiF, Вы писали:
AF>Насколько много людей, которые стали бы покупать такую прогу? (или это только мне одному все время хочется странного? ) AF>Поддержка каких языков нужна в первую очередь?
имхо java, c++, c#, xml...
У тебя стада потенциальных клиентов на расстоянии одного форума ходят , попробуй спросить у них http://gzip.rsdn.ru/forum/?group=tools. У них же можно спросить, чего не хватает в существующих тулах (или наоборот, услышать, что ничего нового там придумать нельзя)
Здравствуйте, Relayer, Вы писали:
R>пару месяцев. как я уже сказал — основная возня была с построением дельфовой граматики и написанием парсера для нее. остальное — фигня
У меня уже есть кое-какие наработки для генерации парсеров, надо только довести генератор до ума. В принципе, я примерно так и оценивал.
Здравствуйте, grigsoft, Вы писали:
G>Можешь подумать в направлении библиотеки, которую могли бы использовать существующие сравнивалки. Я бы такую купил, к своей прикрутить.
Боюсь, на самом деле это не имеет для меня смысла. Такая библиотека — это фактически и есть готовая утилита для сравнения, осталось только прикрутить гуй и продавать.
Здравствуйте, PPA, Вы писали:
PPA>У арксиса есть исключения наа базе регулярных выражений. PPA>имхо этого достаточно.
вы с нормальным дифером не работали. наш например PasDiff сразу говорит что поменялось в интерфейсной части и в реализации. причем мне не надо парить голову — я вижу детальный отчет типа: добавилось поле в классе, изменилась декларация метода, изменилась имплементация и тп тд. клик мышью — я позиционируюсь на код и вижу его до и после изменений.
это все не в плане рекламы, это к тому что дифер может быть гораздо пробвинутее чем мы привыкли видеть. но тогда он обязан понимать как минимум синтаксис текста.
и в догонку — регулярными выражениями можно вырезать коментарии. но вот ситуацию когда изменили порядок слеования двух процедур к примеру ты не обработаешь никак.
Здравствуйте, Relayer, Вы писали:
R>Здравствуйте, PPA, Вы писали:
PPA>>У арксиса есть исключения наа базе регулярных выражений. PPA>>имхо этого достаточно.
R>вы с нормальным дифером не работали. наш например PasDiff сразу говорит что поменялось в интерфейсной части и в реализации. причем мне не надо парить голову — я вижу детальный отчет типа: добавилось поле в классе, изменилась декларация метода, изменилась имплементация и тп тд. клик мышью — я позиционируюсь на код и вижу его до и после изменений.
А на кой это все нужно ? Вы видимо не работали там где применяются дифы/мержевалки по назначению
Здравствуйте, 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 файле. А в некоторых ситуациях, это может быть критично.
Повторюсь и скажу, что подобные "оптимизации" надо иметь возможность настраивать. И наверное, даже не только на уровне всей программы, а и иметь возможность настраивать параметры сравнения для конкретной (сейчас просматриваемой) пары-тройки файлов.
По хорошему, если в парсере XML-документов фиксирован порядок атрибутов (именно атрибутов, а не элементов), в котором они должны идти — то это нарушает стандарт XML. Ну а если по практичному, то опции конечно должны быть
Здравствуйте, AndreiF, Вы писали:
AF>По хорошему, если в парсере XML-документов фиксирован порядок атрибутов (именно атрибутов, а не элементов), в котором они должны идти — то это нарушает стандарт XML. Ну а если по практичному, то опции конечно должны быть
Виноват... Порядок элементов, а не атрибутов, менялся. Но и тут пришлось сделать так, что бы от порядка не зависело.
Настройки — это то чего, по моим понятиям, в инструментарии разработчика много быть не может (исключительно при наличии нормальной документации к инструменту).
)
