Daemon

Ну хорошо, слегка передернул.
Мне приходилось просматривать массу исходников.
Просто я никогда не забывал о том, что код писался конкретными людьми с определенными привычками и симпатиями для достижения конкретных целей, а не как учебное пособие.
Может тут есть такие, что и комментируют все подряд?
Бо лично у меня просмотр даже своего кода после некоторого перерыва (месяц и больше) начинается с: а это ишо шо за фигня, ага - понял, а это…

Daemon
Спасибо, правда не знаю что и сказать, помогло мне знание о наличии этого инструмента (depends.exe) или наоборот, т.е. ещё больше озадачило. Первое впечатление: "Лучше б я не знал об этой программке", надеюсь первое впечатление обманчиво! Странно что в MSDN 2004 об этой утилите есть информация, а в Visual Studio 2003 .NET этой утилиты нет (неужеле она такая новая), но я её нашёл в Visual Studio 2005 Pro, правда ещё придётся потратить не мало времени на ознокомление с программой. Кстати как можно отличить готовый проэкт (*.exe) например Win32 от MFC, эта утилита в этом деле лучший товарищ? Например в проэкте Win32 в первой строке (depends.exe) написанно USER32.DLL, а в проэкте MFC, MFC71.DLL, это и есть отличительные признаки и стоит ли этому доверять? Теперь я начинаю больше понимать о том, как взламывают чужие exe-шки, ведь даже вполне легальные программы выдают всю поднаготную готового, откомпилированного проэкта, я уже не говорю об дизассемблерах и других "хитроумных" программах.

Угу. Как минимум public и protected члены. Плюс еще про code coverage не забываем. Скажем, вот простой метод по переводу HEX строгового представления цвета в структуру System.Drawing.Color:



А вот тесты для этого метода:



Взглянув на этот stuff уже не возникает никаких вопросов, как ты выражаешься "а это ишо шо за фигня"
Добавлено спустя 12 минут, 29 секунд
-=alex-forewer=- Как пользователь Total Commander могу тебе посоветовать просто встать на DLL или EXE и нажать F3. Далее закладка Dll Dependency. Приятно удивись. А MFC приложение таки да, должно сслылать на что-то вроде MFC42.DLL и т.д. Первая там строка или вторая не имеет никакого значения. MFC сам USER32.DLL дергает.

eisernWolf
Не сказка. Над большим проектом иначе просто невозможно работать - он развалится по кускам. будет куча заплаток, затычек, временных решений, которые, конечно же, потом переделаются, но не переделываются никогда
_SGK
Дай только человеку возможность объявить процедуру общего назначания, которая, по его мнению очень нужна, так он туда еще и десяток переменных запихнет. Я вполне серьезно.

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

На кой черт мне нужно разбираться, кто и зачем в файл misc.cs напихал десяток функций, при чем сразу видно, что писали разные люди. Оно мне нужно с этим разбраться? Я уже не говорю за полное отсутствие комментариев, безграмотное название, такое же оформление
Если полочки собираются добавляться, то лучше сразу ту часть шкафа, где эти полочки будут стоять, пересмотреть. Иначе оно же и рухнуть может. И даже задавить кого-нибудь.
По поводу комментариев. Я очень не любил комментировать код. Но со временем это прошло. Когда я залажу в код, который писал год назад, я сразу понимаю, что это, зачем нужно и как работает. Есть еще один момент. Над проектом работает много людей. И часто другим людям приходится смотреть код. И уж пусть лучше они сами там все прочитают, чем будут меня дергать с вопросами типа "а шо это?". Верно и обратное.
Да и вообще, нифига это не сказки. Это суровая реальность разработки более-менее крупного проекта. Более того, я еще большой приверженец ведения полной документации по проекту. Пусть побегает девочка, день меня тупыми вопросами подостает, зато потом будет лежать большой талмуд, в котором концепция проекта расписана досконально, вплоть до того, что известно кто какие части реализовывал

http://www.silicontaiga.ru/home.asp?artId=4888

Ну и книги по теме:

Addison Wesley - eXtreme .NET. Introducing eXtreme Programming Techniques to .NET Developers - 2004.chm
MS Press - Extreme Programming Adventures in CSharp - 2004.chm
Питер - Экстремальное программиование. Разработка через тестирование - 2003.pdf
Питер - Экстремальное программирование - 2003.pdf
O'Reilly - Unit Test Frameworks - 2004.chm
The Pragmatic Programmers - Pragmatic Unit Testing in C# with NUnit.pdf

Большинство ищется на natahaus.ru. Остальное через emule.

P.S. Да, еще про парное программирование не забываем Сам на практике не применял, возможности такой не было...

eisernWolf
Это все, конечно, очень хорошо. С принципами экстремального программирования я так же знаком. НО, с очень многими моментами я не согласен. Я не видел ни одного коллектива, которых бы на практике продолжительное время применял эти принципы. Возможно, у нас просто не та область, чтобы применять эти методы, но эффективности в них я не вижу.

--Vel-- Эффективность чувствуется, когда видение заказчиком проекта изменяется каждую неделю...

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

--Vel-- А причем тут заглушки? Речь идет о том, что иногда приходится вносить такие изменения, которые плохо ложатся на существующий дизайн. Уточню: дизайн нынешний продумывался _заранее_, но исходя из тех, предыдущих требований. А конфликтовать там ничего не будет, если головой думать, а не дебуггером, да и тесты не дадут.

eisernWolf
Если видение проекта заказчиком кардинально изменяется каждую неделю, то имеем две ситуации:
1. быстро пишем/дописываем/правим. В итоге, через 3-4 месяца такой работы текст проекта превращается в сплошную кашу в любом случае, даже при очень грамотном программировании. В итоге заказчик все равно остается недовольным, т.к. на самом деле сам не знает, чего хочет
2. Составляется абсолютно точная спецификация проекта с возможностью мелких изменений/крупных добавлений. Если же после этого заказчик все же меняет свое видение не раз и не два, то такой заказчик посылается очень далеко.
Наоборот, при грамотном изначальном проектировании мы себе оставляем довольно много простора для манервов и изменений. При написании "в лоб" через какое-то время проще все выкинуть и начать переписывать с нуля. Это уже проходили и не раз

Предусмотреть всего невозможно. А излишне расширяемая архитектура с легкостью позволит утонуть при ее поддержке (тех же изменениях).



Точно. Поэтому я и обратился к XP.

P.S. Никогда я не любил эти пустые идеологические споры... Я практик. Работать надо. Завязываю.

Согласен.

Т.е ты предлогаешь держать балланс ?
Вопрос 1: Разве не всё в мире так устроено ?
Вопрос 2: Как найти золотую середину ?

eisernWolf

Не, ну я не про это говорил.


Мысль понял, если смотреть с точки зрения: "заставь дурака богу молится…" то да.

--Vel--

Прям страшилки какие-то, чес. слово.


Относительно комментариев я специально спросил:

Безусловно, что-то комментируется, назначение класса там, определенные моменты интерфейса, но не более.
Пример: класс содержит два десятка полей данных (переменных), столько же методов, часть которых составляют свойства и события, все это дело реализовано примерно в 2000 строках.
Естественно, что все корме интерфейса (свойства, события, некоторые public методы при наличии оных) инкапсулировано и комментировать это, к примеру для вас, я не вижу никакой необходимости.
Потому как это готовый РАБОЧИЙ класс, а не учебное пособие.
Есть интерфейс класса вот и пользуйтесь им, есть желание разобраться во всем глубже – милости просим, код перед вами.
Также есть нормы и рекомендации относительно определенных моментов реализации.
К примеру C# позволяет создавать события любого типа, однако для совместимости с .NET Framework Microsoft требует, чтобы обработчики события имели два параметра (ссылка на объект и инфа для обработчика).
Если парни мутят что-то свое, то - мдя…

Когда я писал:

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

_SGK
Это хороший рабочий класс до тех пор, пока не случится одно из следующих:
1. он перестал стабильно работать
2. он требует необратимых улучшений. другими словами, его нужно неслабо дополнить или модернизировать
Поэтому у меня сейчас за правило выступает следующее: на класс - комментарий зачем оно нужно. На значимые данные - комментарии, зачем оно нужно, служебки пропускаются. На методы, свойства, события - комментарии с той же целью. Далее, сам код класса - названия всех функций как минимум удобочитаемые (тот же комментарий, своего рода) + особо тяжело читаемые куски кода или же с закрученной логикой - как можно более полный комментарий. Плюс, если получается так, что логически завершенные куски кода приходится лепить в одну фукнцию, то опять же комментариями с пояснениями отделять друг от друга.
Муторно написал? Куча лишних телодвижений в тот момент, когда "мысля прет"? Угу, не спорю. До тех пор, пока это просто не станет хорошей привычкой и просто сам не замечаешь, что руки комментарий пишут. Главное заставить себя приучиться к этому. Самому же потом легче будет.

Это не страшилки, а реальные последствия одного очень запущенного случая. Чаще всего, конечно же, до этого не доходит. Но лучше же все пресекать на корню, правильно

--Vel--

Это типа как? Я в шоке...
Не, ну я, конечно, могу понять как пришедший на вызов сантехник после пары "капель" , принятых на грудь, во время очередного перекура перестает стабильно работать.
Но, чтобы класс ранее нормально использовавшийся, вдруг заглючил...

Да, тут варианты есть.


Ага, хотя ИМХО кто платит - тот и заказывает музыку.


Видать и впрямь у всех все впереди…

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

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

--Vel--

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


Обработка исключительных ситуаций – самое оно.
Если необходимо, то и повторное генерирование (throw) для перехвата внешней catch-инструкцией.
А уж если чел не сном, не духом какие исключения у него в классе могут возникнуть, то ИМХО это уже тяжелый случай.
У вас в штате не хватает программера – параноика ну или тестера - аналитика на худой конец.

_SGK
Все у нас есть . Наверное просто не смог объяснить нормально. Может такой пример будет понятнее - у класса есть n-ная функциональность. Она протестирована. Реально же используется только часть функциональности. И вот в один прекрасный момент понадобилось использовать все. Класс работает, программа ошибок не выдает, но сам класс выполняет не совсем адекватные действия и на выходе дает немного не то, чего бы хотелось. Бывает такое. Какая бы прямая реализвация не была, но такое есть. Ну или я ничего в программировании не понимаю. Одно из двух

--Vel-- Чисто с теоретической точки зрения я с тобой не соглашусь, потому как тут существует 2 аспетка:
1. Если процедура могла бы быть в глобальном пространстве имен, но ее упаковали в класс, в виду отсутсвия глобального пространства имен. Получается, что в этом случае мы под принципом инкапсуляции понимаем только data hiding, что есть не верно (если судить по Бутчу).
2. Если требуется глобальная переменная, но пришлось ее допустим упаковать в класс (в качестве статической переменной) и уже к ней обращатся, то в этом случаи получаем нарушение инкапсуляции. Как минимум это плохой стиль, максимум ведет к серьезным последствиям

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

_SGK Ты кошмарный сон багфиксера В крупных компаниях существуют свои правила по оформлению кода, его комментированию, или же они пользуются общеизвестными (mozila + doxygen нынче очень популярен).

Я достаточный параноик?

Daemon
Согласен по обоим пунктам, особенно по второму. Но, ведь кроме плюсов сузествуют и минусы. И их не мало. Хотя, если действителньо грамотно спроектировать такой неймспейс, то все же плюсы перевешивают