Я говорю между 1 и 5 строками. Более того, вы должны обосновать это с помощью электронной почты остальной части вашей команды разработчиков. Это помогает повторное использование, создает хорошие методы именования и пары.Какой хороший средний размер метода?
Есть комментарии?
Благодаря
Немного экстремальный, я думаю, что cyclometric сложность 5 или менее разумная мера, а не количество строк. Разрыв кода до менее чем 5 строк может означать, что он нечитабелен и трудоемкий. Я знаю, что по этому поводу будут разные мысли, поэтому эта тема должна быть закрыта как субъективная.
1 и 5 линий кажутся слишком маленькими для меня. Если вы объединяете упрощенные бизнес-приложения, которые не выполняют много обработки, то это кажется правильным, но если есть какие-либо алгоритмы или процессы, часто гораздо читабельнее (и поддерживается), чтобы писать шаги обработки последовательно, а не распространяться по нескольким методам или классов - даже если это логично для целей инкапсуляции, валидации и т. д.
5 строк во многих случаях недостаточно даже для проверки параметров и итерации по коллекции.
Я бы предложил «о странице»; От 20 до 30 линий идеальны.
Например: это, кажется, действует на меня, но ты не стал бы рассматривать это не годится 8 строк:
// Calculates the depth of the layer in the object graph
public int GetIndex()
{
int ct = 0;
ViewLayer pos = this;
while (pos.Parent != null)
{
ct++;
pos = pos.Parent;
}
return ct;
}
(Я понимаю, что я открываю себя критики, разместив код, но мой точка зрения, это читаемый код)
Это слишком долго, вы должны были использовать что-то вроде: 'public int GetIndex (ViewLayer pos = this) {\ n return (pos.Parent == null)? 0: 1 + GetIndex (pos.Parent); \ n} \ n' синхронизация в 3 строках :-) – paxdiablo
Это не чистый код. Чистый код для такой тривиальной задачи не нуждается в комментариях. Во-первых, имя могло быть DepthInObjectGraph. Во-вторых, это могло быть рекурсивным и принимать 1 или 4 строки, в зависимости от того, хотите ли вы, если/else или?:. – qertoip
@qertiop - хорошая работа, вы нашли способ улучшить код - то, что почти всегда возможно. ваш комментарий относится к ответу, т. е. вы думаете, что ни один метод не должен быть длиннее 1-4 строк? –
Размер кода метода является неправильной метрикой для обязанностей метода. Метод должен иметь ровно одну задачу поведенческих/творческих задач без дубликатов кода.
Я думаю, что это сложнее, чем это.
Во-первых, методы, как правило, следуют степенному распределению: в любом заданном проекте будут какие-то внешние методы, которые настолько огромны, что подавляющее большинство других методов никогда не сходится.
Во-вторых, если вам нужно выпустить десять вызовов API для выполнения одной конкретной задачи, нет смысла разбить эту последовательность вызовов на два метода, чтобы соответствовать размеру. Когда вы разбиваете что-то на части, вам нужно дать два имени (или даже три) вместо одного. вы должны документировать каждую часть и т. д. Нижняя строка: маленькая - это хорошо, но не следите за ней вслепую. Лучший совет - попытаться сделать каждый метод последовательным (сфокусированным).
Конечно, это просто делает код сложнее ориентироваться и понимать, звонки B, называет C, затем E, затем D и т. Д. Я не уверен, как он обеспечивает хорошее именование, у меня достаточно проблем с поиском хороших описательных имен для моих существующих методов, никогда не бывало ни одного 5 строк.
Это также делает занятия более длинными, так как вы должны иметь подпись, открывать и закрывать фигуру метода и дополнительную линию для чтения.
Кроме того, большинство моих заявлений linq имеют длину более 5 строк.
Пусть требования к коду диктуют, как долго это слишком долго.
Вы действительно хотите, чтобы ваши разработчики тратили время на письма, а не на разработку кода?
Можно ли использовать 25 однострочных методов и один 100-строчный метод? – Yellowfog
До тех пор, пока это нужно *, размер/количество строк не так важно, как функция ** делает одну вещь **, ИМО. –
Я лично не думаю, что есть определенный ответ, который является «правильным». Но подумал, что вы хотели бы поговорить о том, что «Дядя Боб» Мартин сделал в QCon London в этом году, где он рассказал об этой теме: http://www.infoq.com/presentations/Robert-C.-Martin-Bad -Код – AdaTheDev