Каков общий и разумный порядок параметров для функций? - PullRequest
Новая
       22

Каков общий и разумный порядок параметров для функций?

4 голосов
/ 22 декабря 2010

При условии, что все они обязательны: 

function search (haystack, needle)
function search (needle, haystack)

function placeObject (object, column, row)
function placeObject (column, row, object)

function newObject (parent, width, height, isVisible)
function newObject (isVisible, width, height, parent)
function newObject (width, height, isVisible, parent)

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

Ответы [ 3 ]

1 голос
/ 22 декабря 2010

Попробуйте произнести предполагаемый вызов. 

function search (needle, haystack)

Поиск иголки в стоге сена. 

function placeObject (object, column, row)

Поместить объект в (столбец, строка).

newObject сложно: старайтесь поддерживать его в соответствии с вашей структурой, если таковые имеются, ставьте общие параметры в первую очередь. Я бы поставил isVisible в последнюю очередь только потому, что он логический, и из логического литерала может быть сложно определить, что он делает. С несколькими логическими значениями я предпочитаю объединять их в объект флагов целочисленного типа, созданный с помощью битовых масок (или словаря значения ключа, или строки, в зависимости от языка), чтобы получить удобочитаемость: 

openFile(path, READ | LOCKED | COMPRESSED | ...)
0 голосов
/ 22 декабря 2010

У меня такое ощущение, что обычная логика - это функция времени. Видите ли, если у вас есть функция: 

public Pizza makePizza(cheese, sauce){}

И затем вы создаете переменную, которая определяет начальный номер в массиве: 

int toppingNo = 3;

Вы, вероятно, хотите отправить это и своей функции, верно? 

public Pizza makePizza(cheese, sauce, topping){}

И так, сын мой, так рождаются параметры!

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

0 голосов
/ 22 декабря 2010

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

  1. Согласованность.Если у вас есть, например, функции, которые копируют объекты, то следуйте порядку, в котором указаны источник и место назначения.Вы можете использовать существующие смещения, которые могут иметь люди (например, порядок операндов в директиве ассемблера MOV или порядок аргументов стандартной функции C * strcmp).

  2. Группировка.Полезно объединять вещи, которые логически «сгруппированы».Например, если ваша функция открывает соединение с базой данных, имя пользователя и пароль должны быть вместе (и, вероятно, в том же порядке).

  3. Читабельность.«Большие» параметры, по которым выполняются операции, должны предшествовать меньшим.Например, draw_line(canvas, x0, y0, x1, y1), а не draw_line(x0, y0, x1, y1, canvas).

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

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

...