18 июн. 2007 г.

Средства автоматического форматирования

Надо сказать, что основным моим средством разработки является Borland Delphi for Win32.

Мое первое знакомство со средствами автоматического форматирования кода состоялось в среде Eclipse поддерживаемой компанией IBM. Используя метод погружения в изучении новой среды разработки и привыкая к несколько отличной аннотации Object Pascal и Java в справочнике по Eclipse нашел упоминание о возможности автоматического форматирования. С этого момента дело пошло несколько проще. Хотя среда весьма на высоком уровне поддерживает уровень шаблонов иногда в совсем уже патовых ситуациях при сложных конструкциях помогало магическое сочетание клавиш Ctrl+Alt+F и все становилось на свои места.

Естественно, что ко всему хорошему привыкаешь очень быстро. Это очень прискорбно но среда Borland Delphi вплоть до версии BDS 4.0(Delphi 2006) не обладает встроенными средствами форматирования кода. Поддержка шаблонов языковых конструкций не в счет.

Основными фаворитами после недолгого поиска среди свободно распространяемых продуктов стали GExpert CodeFormatter и JEDI JCF. Первый находился в экспериментальной стадии и заметно проигрывал второму в количестве настроек. Хотя вполне мог бы удовлетворить потребности менее притязательного пользователя нежели я.

JCF заслуживает более пристального внимания.

Надо сразу отметить, что JCF работает только при условии установленной библиотеки JEDI



Jedy code format by Ralf Steinhaeusser

http://jedicodeformat.sourceforge.net/

Форматирование кода

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

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

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

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

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

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

Код достаточно изменчивая субстанция и естественно его документирование не успевает за его изменчивостью, зачастую и просто является более затратной чем само его написание. Причины кроются в потребности человека, который бы занимался его документированием. Затраты на прочтение и коммуникации с кодировщиками значительно повышают затраты времени на поддержание документации кода в актуальном состоянии. Опять же документатору кода необходимо его читать и разбирать. Снова наталкиваемся на проблему с читабельностью кода.

Читабельность кода зависит от документирования, а документирование от читабельности. Решением согласования такой неоднозначности являться самодокументируемость кода. Тоесть код становиться единственным источником документации. Кроме случаев автоматического построение отчетов и диаграмм сторонними средствами на основе программного кода. Например: диаграмма классов, метрики, файлы справки в различных форматах.

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

Ситуация первая:

единый стиль кодирования не соблюдается и документация на код отсутствует

Действия программиста:

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

Ситуация вторая:

единый стиль кодирования соблюдается всеми, документация на код отсутствует

Действия программиста.

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

Вторая ситуация довольно оптимистична и может встречаться разве, что в достаточно «притертой» команде. В наше изменчивое время такое встречается довольно редко. Другим вариантом может быть жесткая тоталитарная политика ведущего программиста. Ручная сортировка названий модулей в разделе импорта, насильное упорядочивание автоматически сгенерированных средой методов, принципиальное использования функция замены текста вместо специализированных методов рефакторинга и т.д. В общем фобия автоматизации и каменный век.

Несколько разбавить ситуация может использование инструментов автоматического форматирования кода. Выгоды от использования таких инструментов очевидны.

Формат кода не зависит от стиля присущего каждой личности участвующей в его создании. В любой момент времени код может быть приведен к общепринятому стандарту или же отформатирован согласно нововведениям в существующем стандарте.

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

Экономия времени и сил ведущего программиста в процессе слежения за соблюдением стандартов всеми членам команды в том числе и им самим.


Польза стандартов

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

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

15 июн. 2007 г.

Король умер, да здравствует король!!!

Вот к сожалению накрылся мой платный хостинг. Не то, чтобы очень сильно по карману бил, а просто весьма неудобно покупать вебмани или заводить себе карточки интернет денег. Все время забывал проплатить. Ну в общем это уже в прошлом. Админы позволили скачать архив и на том им огромное спасибо. Вот тут я и открыл для себя гугль(спасибо Николаю Войнову :-) Привет, Коля!). Как оказалось все, что нужно для нормального блога у гугля уже есть. Небольшой проблемой оказалось место для хранения прикрепленных файлов, относящихся к статьям, но и в этом случае у гугля нашлось решение.


Заходим на http://code.google.com/ дальше в меню Project Hosting и создаем себе новый проект Create a new project


В результате мы получаем страницу под проект, хранилище для файлов, WIKI, багтрекер и хранилище кода под управлением SVN.


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

Первым жителем нового проекта стал небольшой гайд по Apache Derby. Продолжение следует.

В общем добро пожаловать! Я к вам и буду у вас жить.


Пособия для "чайников"

По дороге на работу зашел в супермаркет. Уже стоя в очереди в кассу увидел занимательную книгу "Бизнес-планы "для чайников".

Жаль не было с собой телефона, чтобы сфотографировать.

Нашел ссылку на сайте издательства "Диалектика"
Книга будет полезна как начинающим предпринимателям, так и бизнесменам с опытом, тем, кто ведет свое дело самостоятельно, и тем, кто руководит большой корпорацией.

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


Возникают два философских вопроса.


Почему есть книги подобного рода, а так же «Delphi за 24 дня», «Java для «чайников»?

Почему нету книг «Фортепиано для чайников» или «Скрипка за 24 часа»?


Заплачу 10$ тому, кто укажет мне книжку «Написание технических заданий за 36 часов»