Какая характеристика наиболее важна для хорошего распорядка дня?

Question

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

(Указав одну характеристику для каждого ответа, можно проголосовать за них индивидуально. Т.е. цель этого вопроса - не выделить одну характеристику, а, скорее, выделить все важные.)

Answer 1

Я думаю, что наиболее важным критерием будет то, что он преследует одну цель.

После этого он правильно выполняет эту (и только эту) цель.

Answer 2

Самокомментируемые имена процедур.

Примеры: GetStoreFromAddress GetCarsByMake

Answer 3

Он должен быть легко протестирован.

Answer 4

Название подпрограммы однозначно соответствует ее функциональности.

Удивительно, как часто функция X выполняет X, а также Y или большую часть X, но не все X.

Answer 5

Не существует единого критерия, который отличал бы хороший распорядок от плохого.

Среди критериев:

• концептуальная целостность: имеет то, что можно описать в простая короткая форма, одно предложение или абзац;
• слабая связь: его поведение не чувствителен к тому, что происходит в коде вокруг него;
• разумный размер: длинные процедуры труднее читать и понимать, и меньше шансов получить хорошие концептуальная целостность;
• Критерий Парнаса: они «прячутся» одна вещь, которая может измениться, так что изменения требований ограничили влияние на остальную систему.

Answer 6

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

Answer 7

Количество действий, которые он пытается сделать.

Если это не совсем 1, вероятно, у вас проблема.

Answer 8

У этого не должно быть неожиданных побочных эффектов.

Answer 9

хорошая обработка ошибок (надежность)

Answer 10

краткость

(это должен был быть полу-забавный ответ, но ТАК не позволял публиковать одно слово само по себе!)

Answer 11

Он должен быть атомарным

Answer 12

Строки кода.

Answer 13

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

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

Answer 14

Он выполняет одно дело или делегирует несколько функций другим функциям

Answer 15

Четкость - легко понять

Answer 16

Думаю, на этот вопрос легче ответить, если рассматривать подпрограммы как часть API. Не так много процедур, которые стоят отдельно, по крайней мере, в действительно полезной системе. Так что, честно говоря, я думаю, что при написании подпрограмм нужно учитывать следующее:

1. Интуитивность Насколько интуитивно понятен мой набор инструкций - поймут ли люди цель, не углубляясь в большое количество документации?

2. Ортогональность Насколько ортогональны мои процедуры? Каждый из них выполняет одну конкретную задачу или существует несколько (но немного разных) способов сделать одно и то же? Если есть, значит, это плохо, и API, вероятно, необходимо переработать.

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

Answer 17

По названию подпрограммы вы можете сказать, что она делает (и когда вы проверите код, вы поймете, что были правы ;-)

Answer 18

В подпрограмме используется постоянный уровень абстракции.

Answer 19

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

Answer 20

Единая точка возврата