Сергей Силкинdonkey80 Методы длиной в несколько тысяч (!) строк...У меня лично целый список требований к исходному коду – как к его функционалу, так и оформлению. В частности, одно из требований – чтобы объём функции (метода) не превышал одного экрана исходного кода (разумеется, один оператор на одной строке). Пусть народ с малолетства приучается не только как следует кодировать, но и проектировать приложение. Аргументы типа «вот эту функцию нельзя разместить на одном экране» не принимаются в ультимативной форме. Разбить и грамотно структурировать всегда можно (если, конечно, ты не чайник). Предпочтительно конечно же разбивать части по функциональному назначению; но на крайняк можно и чисто механически – просто кусками. Но в любом случае каждая функция (метод) должна быть не то что простая, а очень простая – так, чтобы её можно было окинуть одним взглядом (т.е. быть не больше одного экрана), логика работы должна быть абсолютно понятна не только автору, а и новому человеку, и соответственно чтобы её можно было модернизировать, в том числе и другим людям.

...А если вовремя не обломать некоторых, то рано или поздно вполне можно увидеть такое: весь проект состоит из одной огромной функции main (ну или WinMain или типа того – в общем, точки входа в программу), а дальше... сплошной набор операторов без единой определённой разработчиком функции, да ещё «нормальных» управляющих конструкций почти нет, зато есть куча операторов goto. Хотя программа работает, а разработчик божится, что по-другому никак было сделать нельзя...

Если кто-то не видал такие программы - считаем, что ему крупно повезло. А если такие программы ему ещё не давали модернизировать - ему очень крупно повезло вдвойне...

я вот не против такого в случае, когда речь идет о string.Substring(). Но часто неважно , что весь проект состоит из одной огромной функции main, важно, что это работает так ,как того хотел потребитель проекта, которму абсолютно неважно, что исполнитель убил все свое время на представление функции размером не больше экрана. Говорю как разработчик, как внедренец и хэлпдеск - прошел все стадии жизни проекта (и не одного) , включая модернизацию, вплоть до его смерти. Для сопровождения проги важно описание хедеров ф-ий и знание условий , на которых это писалось ранее и теперь, алгоритмы иногда попадались такие, что понимать их начинаешь не сразу по просмотру кода, а только после прочтения соответств литературы, о которой в тот момент и не подозреваешь.Теперь как сопровожденец и модернизатор кода поясню,что знание условий , на которых это писалось ранее и теперь. Если ранее этот продукт был коробочным вариантом - извиняйте ,хлопци - это запросто может быть одной ф-ией main, если OEM - другое дело. И модернизировать в первом случае надо начинать не словами - какой м...ль это писал, а вопросом - вы точно хотите модернизировать это боксовое решение?

ShSergeЯ всегда пишу очень кривой, на ламерский взгляд, код, но простой и эффективный. Чужой код (!) никогда не правлю, а всегда переписываю с нуля. Ну, не весь, а хотя бы функционально законченные куски.
Это начальный уровень кодера с амбициями. Говнокодом творение назовут, когда код начнет править другой такой же кодер.
Заявляю отвественно, что даже хелловорд -очень эффективный код :-)

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

а если 2 человека код правят, и один взял, и всё переписал, тогда что?
а если code owner и тот кто исправил код это разные люди?
это полный пипец, про двух человек -особенно,
проходили уже.

mikola1982qazaqкачество нужно, но без фанатизма. Так же как в нормализованных таблицах нужна иногда денормализация данных)))))
Убить неделю на написание указивок как правильно называть локальную переменную или запрещение использовать самописки- методы, потом еще неделю на составление приказа и взятие под подпись , если на написание проги нужна неделя с самописной функцией типа String.Substring() не кажется даже академически оправданным.
если потом это будет использоваться для других проектов то почему бы и не заморочится на это.
Мне кажется все нужно в меру. если проект разовый простой, команда собралась что бы его написать и разбежаться то тут хватит и словесной договоренности, а если ваша компания занимается разработкой софта, то тут сам Бог велел создавать такие указиловки, но опять же мера нужна, необходимо оставлять свободный маневр для программиста ведь они по большом счету люди творческие и шибко обижаются когда их в жесткие рамки загоняешь.
среднестатная жизнь проекта до его полной переработки 3 года - стоит ли овчинка выделки?

softwarerqazaqсреднестатная жизнь проекта до его полной переработки 3 года - стоит ли овчинка выделки?
Это с учётом тех проектов, которые навернулись через неделю после начала работ, и сваливая в одну кучу ERP-системы и сайты персональных страничек?

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

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

Сергей Силкин6275Один экран - это сколько строк?Чтобы взглядом можно было охватить. В прямом смысле слова - один экран. Если несколько (а уж тем более много) экранов - это же в коде почти гарантированно никто не разберётся, кроме автора! Ну разве что вундеркинд какой-нибудь. Но, во-первых, где найти столько вундеркиндов? Или гениев. В подавляющем большинстве народ - это "рабочие лошадки" - в самом хорошем смысле слова (уж тем более не в обиду), но уж никак не гении и не вундеркинды.
Произошла типичная подмена понятий - за гения тут считают не опытного бойца, так сказать - ветерана боевых действий, а долбодятла с амбициями, страдающего аутизмом, неспособным сосредоточиться и удержать тему при прокрутке экрана, поэтому неудивительно, что есть специфические требования , учитывающие эту проблему

онолитегqazaqсреднестатная жизнь проекта до его полной переработки 3 года - стоит ли овчинка выделки?
смотря какого проекта, *nix'ы живут уже десятки лет. единственная "качественная переработка" -- Plan 9 так и не пошла в "продакшн"/широкие-массы
ну если каждый вышенаписавший имеет в своем активе проекты такого класса-беру свои слова обратно.(притом что знаю,в германии и дос-проекты живут, но это - от их жлобства)

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

а зачем им иметь такие проекты? философия юникс (да и ее история) достаточно хорошо показывает, что при продуманном протоколе взаимодействия можно писать маленькие простые программы, а потом эффективно их комбинировать. та же ls весьма простая программа, а используется до сих пор, так же как и куча других стандартный никсовых утилит, которая каждая сама по себе может и тянет максимум на лабораторную работу студента, но в правильной среде они "могут делать чудеса" =)

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