Конвенции для порядка параметров в функции

Question

Конвенции для порядка параметров в функции

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

если я пишу:

    public Comment AddComment(long userID, string title, string text)

Или вероятно:

    public Comment AddComment(string title, string text, long userID)

Почему нет:

    public Comment AddComment(string title, long userID, string text)

Вы следуете каким-либо правилам при упорядочивании параметров для функций? Какой параметр Вы заняли бы первое место и который будет следовать?

7

parameters function

задан Andy 9 May 2010 в 04:07

2 ответа

Лично я бы сделал первое, потому что именно такой порядок я бы установил в GUI: Пользователь, Заголовок, Текст.

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

1

ответ дан 7 December 2019 в 12:16

Другие вопросы по тегам:

parameters function

Похожие вопросы:

score 4 · Accepted Answer

Есть только 3 правила, которые я обычно применяю:

Если язык позволяет передавать хэш/мап/ассоциативный массив в качестве единственного параметра, старайтесь передавать именно его. Это особенно полезно для методов с >=3 параметрами, особенно если эти же параметры будут передаваться во вложенные вызовы функций.

Это позволяет упростить обслуживание - добавление еще одного параметра (особенно когда один и тот же список параметров передается между вызовами вложенных функций глубиной в 10 уровней) требует изменения 1 места в коде (конечного вызывающего устройства) вместо КАЖДОЙ отдельной функции, которая принимает этот список и передает его в другое место.

У этого есть небольшой недостаток - отсутствие проверки типов в языках типа C++ (например, ваш компилятор не может проверить, содержит ли хэш/карта правильные типы значений для ожидаемых типов ключей) - если это беспокоит, вы можете инкапсулировать эту карту параметров как структуру/класс.
Если язык допускает значения по умолчанию для параметров (например, C++, хранимые процедуры Sybase), вы, очевидно, оставляете необязательные параметры последними, и чем меньше вероятность того, что параметр будет указан со значением, тем ниже в списке он должен быть.
В противном случае, упорядочьте их в любой логической группе, которая наиболее удобна для чтения/сохранения.

Это может быть немного субъективно - например, следующий/предыдущий вес/высота могут быть упорядочены next_weight,next_height, prev_weight, prev_height или next_weight, prev_weight, next_height, prev_height одинаково правильно. Опять же, 3 основных соображения: читабельность/логичность для вас и простота обслуживания.

Что касается читабельности, вы можете упорядочить их по типу или по смыслу.

Что касается "логичности", вы можете упорядочить их по смыслу (например, сгруппировать все "следующие" вместе, или все высоты вместе), ИЛИ по какому-то порядку, навязанному в другом месте - например, по порядку столбцов в соответствующей таблице базы данных, или по порядку полей в GUI (хуже, так как он может измениться).

Что касается обслуживания, если не выкристаллизовывается никакого очевидного значимого порядка, алфавитно-цифровой порядок является наилучшим, так как он позволяет ОЧЕНЬ легко найти параметр путем сканирования и особенно решить, куда вставить новый параметр.