Руководство по кодированию: методы не должны содержать более 7 операторов?

Я просматривал Рекомендации по кодированию AvSol для C #, и я согласен почти со всем, но мне действительно интересно посмотреть, что другие думают об одном конкретном правиле.

AV1500

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

Следуют ли большинство из вас этому правилу? Даже если мало что можно спасти от создания нового метода (ваш код все еще СУХОЙ ), кроме значительного повышения читабельности? И ваш номер по-прежнему всего 7? Я хотел бы больше к 10.

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

Я действительно просто хочу знать, что все думают о том, что НИКОГДА не нарушать это правило (это «1» в стандарте кодирования, то есть НИКОГДА не делать этого) Но я думаю, что у вас будут проблемы с поиском кодовой базы, которая этого не делает.

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

Обычно хорошая идея разбить материал на маленькие методы. Но важно разделить вещи там, где это имеет смысл.

Если нет смысла разделять, то не разделяйте. Это часто имеет место для некоторых процедур или кода GUI.

Стив Макконнелл заявил в Code Complete, что вы не всегда более продуктивны при использовании коротких методов. Если вы разделяете, когда это не имеет смысла, вы добавляете сложность в код без какой-либо выгоды.

Как и в случае с руководящими принципами, полезно помнить, почему существуют ограничения, чтобы вы могли узнать, когда они не применяются. В большинстве кода методы будут короткими, или у вас, вероятно, есть проблема с СУХОЙ или разделением проблем . Но если это не так, тогда хорошо.

Это следует рассматривать как правило.

Такие вещи, как «Не более 80 (100 120) столбцов текста», «одна точка выхода на метод», «Не более 2 уровней вложенности», - это то, что я бы назвал пороговыми значениями для индикаторов запаха кода. Если вы нарушаете их время от времени, это не обязательно означает, что код плохой. Если вы обнаружите, что нарушаете их последовательно, то в коде что-то пахнет, и вы можете сделать паузу и пересмотреть свой подход.

Для меня наиболее важными критериями являются: «Этот код понятен?», «Повторяется ли он?», «Разбивается ли он в логических местах?», «Является ли он слабосвязанным?» Есть еще несколько, но я думаю, что основную идею можно подытожить, вспомнив совет Дональда Кнута: «Программы предназначены для чтения людьми и только для выполнения компьютерами».

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

Это приблизительно

Такие правила не следует воспринимать слишком буквально. Они могли бы сказать, что « методы должны быть короткими ». Тем не менее, некоторые люди интерпретировали бы это как «менее 1 страницы», а другие как «максимум 2 строки».

Я предположил бы, что они сказали «7 утверждений», чтобы дать вам грубую идею (хотя я думаю, что они должны были сказать «около 7»). Если вам нужно время от времени 9, не переживайте. Но если вы наберете 20, вы поймете, что не подходите для этого правила.

7 - абсолютно произвольное число, абсолютно не имеющее значения.

Цикломатическая сложность - это большая проблема, чем количество утверждений. Я видел код с сотнями операторов в одном методе (который мне показался ужасным), но он имел цикломатическую сложность 1, и он действительно делал только 1 вещь. Было только много шагов. Мы обсуждали разделение его на более мелкие методы, но эти методы будут вызываться только одним этим методом.

Хотя это довольно экстремальный случай, дело в том, что вам нужно сохранять код СУХИМЫМ и иметь низкую цикломатическую сложность. Это важнее, чем количество строк в методе.

Возьмите, например, оператор switch / case. Если у вас есть более 7 возможных значений, вам нужно разбить оценку на несколько методов? Конечно нет, это было бы глупо.

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

Принцип должен быть следующим: Каждый метод должен делать одну вещь и держать ваш код СУХИМ.

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

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

Представьте себе метод, foo()который делает 7 вещей. Вы можете утверждать, что 7 вещей это слишком много. Может быть, во многих случаях вы правы. С другой стороны, эти 7 вещей могут быть тесно связаны; логика может течь плавно и читаться как проза; у вас могут быть проблемы с пониманием, когда вам это действительно нужно. Что может оказаться намного хуже, так это распределить эти 7 вещей по большому дереву исходников, так что если вы посмотрите на них, foo()вы не поймете, что они делают, не глядя в 7 разных местах.

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

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

Хитрость заключается в том, чтобы НЕ разбивать его по вертикали (просто ущипните метод в одной точке и начните новый). Хитрость, как и в модульном тестировании, заключается в том, чтобы с самого начала помнить такое правило, чтобы вы на самом деле лучше проектировали, передавая 3 или 4 оператора mid-метода другому методу, потому что вызов метода описывает то, что вы делаете лучше, чем эти 3 или 4 утверждения в середине вашего кода.

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

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

Резюме? Если сравнить запах проекта «Использовать менее 7 операторов» с запахом кода «Я использовал более 7 операторов», я бы предпочел устранить запах кода.

Вау! Я никогда не ожидал найти такую ​​интенсивную дискуссию по простому руководству, которое примерно говорит о том, что ваши методы должны быть очень маленькими. Поскольку они всегда разработчики, которые хотят, чтобы их рекомендации были явными, я выбрал 7, потому что это звучало как хороший порог.

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

Я также никогда не претендовал на звание эксперта. Но я в этой профессии уже 15 лет, с 4 годами опыта C ++ и 11 годами опыта C #. Первоначально он был основан на Industrial Strength C ++, но с тех пор я дорабатывал его при участии сообщества.

Независимо от того, что я пытался поднять, вы должны продолжать думать самостоятельно. Если вы считаете, что правило из 7 утверждений бесполезно, просто сделайте его длиннее. Черт, я даже нарушаю это правило время от времени. Я просто нарушаю это серьезно и принимаю последствия.

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

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

Я согласен с утверждением выше меня. Это просто руководство, и в идеальном мире все было бы объектами, повторно используемыми в каждой программе, и мир был бы прекрасным местом. Это не всегда так, и иногда это приводит к большим накладным расходам или потере ресурсов. Вы должны также помнить это.

Довольно глупо, когда вы добавляете обработку исключений в смесь.

После «попробуй, поймай, наконец» у вас останется четыре утверждения на метод!

Также рассмотрите метод validateForm для формы из 20 полей, даже если вы обрабатываете все отдельные проверки в отдельных методах, у вас все еще есть 20 методов проверки полей, которые нужно вызвать. В соответствии с этими рекомендациями вы получите бессмысленное разделение, например «validateTopOfScreen», «validateMiddleOfScreen» и «validateBottomOfScreen».

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

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

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

Я согласен с комментариями выше. 7 для меня является произвольным и может быть полезным в некоторых языках, где ruby, но для таких языков, как C #, Java, C ++, я сомневаюсь в этом соглашении «7 строк». Позвольте привести пример. В моем текущем приложении 22 текстовых поля, и я выполняю проверку на стороне сервера. Метод называется validateInput (), и я предпочитаю проверять все поля в одном методе, если только у меня нет проверки чего-то сложного, такого как checkEmailFormat (). Так что в основном мой код метода validateInput состоит из 108 строк со случайными вызовами сложной проверки.

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

Что я действительно делаю, чтобы сделать мой код понятным, так это предоставить чистые комментарии, которые в основном говорят о том, что эти 4 строки делают ex -

validateInput (пользователь UserObj) {

// Подтвердите имя ....... ......

// подтвердить фамилию ...... ......

// проверка электронной почты ..... // слишком сложный, чтобы проверить формат электронной почты обычное выражение checkEmailFormat (); .... .....

и так далее.. }

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

Строки кода - это произвольный счет сложности. С помощью методов расширения я могу создать код

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

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

В настоящее время я смотрю на метод из 550 строк кода с множеством операторов if else, продолжением и вложением в него. Это дерьмо. Если бы программист был вынужден думать только о том, что он делал ...