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

Здравствуйте, AndrewVK, Вы писали:
AVK>А можно посмотреть на твой собственный код?
публичных репозиториев моих нет. я тут выкладывал как-то код брутфорсера паролей, но он уже 8милетней давности и мне сейчас кажется корявенько сделанным.
да мне не сложно написать код для конкретного примера. вот IT уперся, что мое решение его не устраивает.
я могу раскрыть свой пойнт на любой другой ф-ии, если есть желание. давайте ссылку на код, я покажу, как я считаю нужным написать. можно даже проголосовать кто за, кто против.

Здравствуйте, gardener, Вы писали:
G>А вот интересно зачем ты такой говнокод в своем посте развел.
G>Куча левого текста, пунктуация кривая, предложения не выделяются, мыслей нет.
G>И нет, это не придирки к грамматическим ошибкам. Мне прсто удивительно как человек так болеющий по поводу говнокода и при этом так ужасно оформляет свою письменную речь. Это компенсация?
это ровно то, что я сказал бы в личном разговоре. именно поэтому я не выделяю начало предложений большими буквами, так как в разговоре мы тоже прекрасно без этого обходимся. логично же!

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

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

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

__>ну не работает, так не работает.

Пусть не работает. Главное, чтобы было 10 строк.

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

__>так и прогрммист со своими функциями-спагетями это нечто среднее между маленькой девочкой с мешком картошки и фашистом с гранатой



Настоящая история про фашиста с гранатой.

Был у нас на одном проекте в IBM архитектор, любитель паттернов и мелких недо функций. Потребовалось нам как-то реализовать простенький отчёт на одну страницу, полей на 30-ть. Задача простая — есть набор входных данных, простых, набор полей без списков, нужно сформировать текст вида

@"
First Name: {0}
Last Name: {1}
"

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

Понять как этот говнокод работал было решительно невозможно. Соответственно, баги, проблемы расширения и сопровождения, задержки сроков и т.п.

Happy End:

Через пару месяцев по совокупности содеянного чувака разжаловали в девелоперы. Больше визиторов и недо функций на проекте не видели. Команда сдала проект в срок с опережением графика и выиграла в капиталистическом соревновании.

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

__>да мне не сложно написать код для конкретного примера. вот IT уперся, что мое решение его не устраивает.

Ещё раз объясняю. Твоё решение сначала не работает, а уже потом не устраивает.

Здравствуйте, IT, Вы писали:
IT>Прямого кода в одну функцию строк на двести с проверками. Чувак не нашёл какой здесь паттерн можно применить, а так как у него по-умолчанию, если не могу применить никакого паттерна, то применяю визитор, именно его бодрячком и применил. В результате образовалось 77 классов, в каждом по одному-два мелких метода.
стыдно признаться, но никогда в жизни не писал визиторов, фасадов, абстактгых фабрик и прочей дребедени
смысл современного проектирования в том, что код должен быть минимальным, удовлетворяющим требованиям.
работал я с человеком, который тоже наплодил всяких паттернов не в тему. было это в 2003ем году по-моему. думали, удивить меня чем-то чтоли?
невнеразумительные спагетти с ничего не говорящими названиями тоже ничего хорошего из себя не представляют. это просто другой сорт одного и того же. нет, честно, я так тоже писал. в 9ом-10ом классе школы строчил ф-ии строк по 200-300 шириной в два экрана. с тех пор, правда, за 18 лет, понял, что есть способы получше. это не то, что я типа такой мегамодный, просидел штанами стул и постиг просветление, а про то, что я полностью в курсе всех плюсов и минусов обсуждаемых тут подходов и удивлен, что кое-кто застрял в прошлом в плане проектирования, когда пора бы уже сказать лапше нет и сделать левелап

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

__>а про то, что я полностью в курсе всех плюсов и минусов обсуждаемых тут подходов и удивлен, что кое-кто застрял в прошлом в плане проектирования, когда пора бы уже сказать лапше нет и сделать левелап

Дык, мы вроде как тут ждём, когда ты перепишешь тот пример от IT хотя бы на 30 строк, чтобы мы поучились и получили левелап?...
(Ну и это... один маленький момент... еще надо чтобы код работал, сорри конечно за придирки...)

Здравствуйте, MozgC, Вы писали:
MC>Дык, мы вроде как тут ждём, когда ты перепишешь тот пример от IT хотя бы на 30 строк, чтобы мы поучились и получили левелап?...
MC>(Ну и это... один маленький момент... еще надо чтобы код работал, сорри конечно за придирки...)
не, ну если прямо совсем не понятны предлагаемые мною изменения, то, к сожалению, обьяснять придется очень долго, начиная с самых основ, там, что такое дерево, его обход, префиксный там, постфиксный, что такое рекурсия, потом мне понадобится выкачать все исходники, собрать, переписать несколько классов, написать тесты, проверить. разумеется, я этого делать не буду. я думал мы тут обсуждаем все-таки архитектуру и мне не нужно разжевывать такие элементарные вещи. и более того, мне лично с этого ничего не надо. не понятно, что я имею в виду и ладно, я не против.

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

__> не понятно, что я имею в виду и ладно, я не против.

Ну вот... а я хотел левелап...

А если серьезно, я пару-тройку лет назад пробовал подход Мартина (микро-функции), и, честно скажу, мне даже в чем-то это понравилось, — код с одной стороны действительно становился понятнее. Но:
1) Иногда функцию просто не стоит уменьшать, с ней и так всё в порядке, даже если её размер противоречит Теории Мартина-Кота2 (превышает 5-30 строк).
2) С одной стороны код становился понятнее; с другой стороны, при чтении кода приходилось прыгать по куче функций, чтобы понять, что происходит. Так же часто приходилось пользоваться решарперовским Find Usages, чтобы посмотреть откуда вызывается эта микро-функция, только чтобы увидеть, что вызывается она из одного места. При отладке тоже не нравилось прыгать по куче микро-функций. Не конец света, конечно, но не айс.

В результате я как-то забросил подход с микро-функциями и все эти субъективные лимиты (в 5-10 строк, полэкрана, 1 экран, 2 экрана, 30 строк и т.д.) и тупо продолжил писать по ситуации: вижу что лучше сделать extract method — делаю, если функция на 1-2 экрана отлично читается линейно или её сложно уменьшить — оставляю как есть.

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

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

__>это не то, что я типа такой мегамодный

Мегамодный? Я бы назвал это старомодный, но рука не поднимается. Это дремучая затхлость из тех пещерных веков, когда экраны были по 80 символов в ширину и 25 в высоту и для задействования горизонтального скролинга нужно было восемь пальцев. Тогда 30 строк было не просто много, а очень много. Сейчас такое можно воспроизвести только на мобилке. Ты не на мобилке случайно программируешь? Тогда твоё увлечение микро функциями будет понятно.

Здравствуйте, MozgC, Вы писали:
MC>1) Иногда функцию просто не стоит уменьшать, с ней и так всё в порядке, даже если её размер противоречит Теории Мартина-Кота2 (превышает 5-30 строк).
я против измерения сложности ф-ии строками. просто одна ф-ия занимается одним делом. бывают такие ф-ии по 30 строк, которые неразумно бить на части, но их очень мало в общем кол-ве. абсолютное большинство безо всяких усилий укладывается в 10 строк. никто не заставляет запихивать ф-ию в 10 строк, это делается совершенно ествественно, просто даже добавить в нее нечего. например, мы открываем файл, проверяем статус, передвигаемся на его конец, возвращаем позицию. все. любая другая операция тут будет лишней.

MC>2) С одной стороны код становился понятнее; с другой стороны, при чтении кода приходилось прыгать по куче функций, чтобы понять, что происходит. Так же часто приходилось пользоваться решарперовским Find Usages, чтобы посмотреть откуда вызывается эта микро-функция, только чтобы увидеть, что вызывается она из одного места. При отладке тоже не нравилось прыгать по куче микро-функций. Не конец света, конечно, но не айс.
маленькие ф-ии это еще полдела. они должны быть названы так, чтобы по названию было понятно, что она делает, не заглядывая внутрь. и сами классы тоже должны быть маленькими и называться не datahelper, а так, чтобы вы могли понять что делает этот класс, не заглядывая в него. так, например, ф-ия работы с временной зоной не должна находиться внутри utils.cs и являться частью класса datetimehelper, она должна называться timezone и находиться в модуле timezone или хотя бы datetime и вам не придется никуда прыгать по коду, так как класс timezone описывает временную зону и странно ожидать там что-то другое

MC>В результате я как-то забросил подход с микро-функциями и все эти субъективные лимиты (в 5-10 строк, полэкрана, 1 экран, 2 экрана, 30 строк и т.д.) и тупо продолжил писать по ситуации: вижу что лучше сделать extract method — делаю, если функция на 1-2 экрана отлично читается линейно или её сложно уменьшить — оставляю как есть.
а тесты?

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

Здравствуйте, IT, Вы писали:
IT>Мегамодный? Я бы назвал это старомодный, но рука не поднимается. Это дремучая затхлость из тех пещерных веков, когда экраны были по 80 символов в ширину и 25 в высоту и для задействования горизонтального скролинга нужно было восемь пальцев. Тогда 30 строк было не просто много, а очень много. Сейчас такое можно воспроизвести только на мобилке. Ты не на мобилке случайно программируешь? Тогда твоё увлечение микро функциями будет понятно.
если что-то куда-то влазит, то совсем не обязательно это туда запихивать. это еще из физиологии известно
человек он не мегагений, не надо ему голову морочить, заставляя по строчкам исследовать код, как древние письмена, пытаясь по набору разрозненных вещей составить целую картину. картина должна быть ясна сразу, буквально по названиям классов, что, зачем, как делается.

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

__>потом мне понадобится выкачать все исходники, собрать, переписать несколько классов,

Ты очень невнимательный. Я тебе уже говорил, что Expressions — это часть .NET Framework. Выкачать его исходники ты сейчас сможешь и даже собрать. Но вот переписать несколько классов тебе вряд ли кто-нибудь позволит из Microsoft. По крайней мере до тех пор пока ты не научишься писать компилируемый код.

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

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

Всё так. Только при чём тут 'микро функции рулят'?

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

__>существует старый старперский подход, и я тоже когда-то так писал и новый сильно более современный, который для старпера будет непонятен в силу отсутсвия у того навыков хорошего именования

в мемориз

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

D>Тогда вопрос: А как же накладные расходы на вызов функции?

А еще не нужно давать объектам, используемым в программе, длинные имена. Накладные расходы на печатание увеличиваются. При компиляции память занимают.

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

AVK>>Скажи, а тут, на rsdn, есть для тебя кто то авторитетный, или все застряли в начале 2000-х?
__>тут много грамотного народа.

Например?

__>они сами признались, что спагетти это нормально

Ты неверно понимаешь что такое спагетти.

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

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

D>>Тогда вопрос: А как же накладные расходы на вызов функции?

P>А еще не нужно давать объектам, используемым в программе, длинные имена. Накладные расходы на печатание увеличиваются. При компиляции память занимают.

Вот только Вас с Вашими шутками тут и ждали. Дождались!!! Все, можно закрывать тему!