Хорошее соглашение об именах для функций и методов, которые могут изменять (записывать обратно) параметр - PullRequest
1 голос
/ 15 февраля 2010

Мне нужно найти хорошую и понятную схему именования для подпрограмм, которые имеют дело с «массивами значений» (я написал что-то похожее на valarray в C ++ в Java с некоторыми оптимизациями для примитивных типов) .

Я знаю, что основная классификация подпрограмм производится между:

  • функций (они могут принимать параметры и что-то возвращать)
  • методы (они могут принимать параметры и ничего не возвращать)

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

Так что можно не только сделать это ...:

ValArrayInt a=..., b=...;
// "apply" treats "a" and "b" as readonly
ValArrayInt temp = ValArrays.apply(adder, a, b); // temp = a + b
a = temp;

... но также и это:

ValArrayInt a=..., b=...;
// "apply" modifies "a"
a.apply(adder, b); // a += b

Пожалуйста, предложите схему именования для таких процедур:

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

Я думал о чем-то вроде ModifyingMethod, NonModifyingMethod или аналогичных, но я думаю, что эти имена не достаточно простые и слишком длинные.

Ответы [ 3 ]

1 голос
/ 19 февраля 2010

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

updateClaimWithPolicyDetails(Claim c, PolicyCriteria pc, String identifier)

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

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

public Policy updateClaimAndGetPolicy(Claim c, PolicyCriteria pc, String identifier) 

Из этого можно сделать вывод, что кто-то обновляет Заявку и возвращает политику (заявка может быть уже обновлена ​​для этой политики).

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

updateClaimAndPolicyCriteria(Claim C, PolicyCriteria pc, String junkParam)

Сказанное выше может сообщить вам, что критерии заявки и политики будут обновлены.

0 голосов
/ 19 февраля 2010

Мне нравится приведенный выше ответ перед ожидающим обновлением или изменением. Однако в действительности это должна быть функция документации, описывающая, что вызывает функция и как она влияет на параметры. Однако обычно вы не хотите изменять параметры, передаваемые в функцию, хотя существуют случаи (например, Collections.sort), в которых вы хотите сделать это, чтобы предотвратить копирование. Кроме того, обязательно используйте неизменяемые объекты, где это уместно, вместо того, чтобы всегда использовать какой-то тупой класс Java-бина со всеми общедоступными методами получения и установки.

0 голосов
/ 16 февраля 2010

Кодирование этой информации в имя метода может быть сложным.

С другой стороны, эта информация должна существовать в документации метода (например, в Javadoc), явно указав побочные эффекты метода.

...