Лучшая практика для именования параметра в конструкторах Java и простых методах set
По-прежнему использовать определение и пример из memory_order . Но замените memory_order_seq_cst на memory_order_release в магазине и memory_order_acquire при загрузке.
Упорядочение Release-Acquire гарантирует все, что происходило до того, как хранилище в одном потоке становится видимым побочным эффектом в потоке, который выполнил загрузку. Но в нашем примере ничего не происходит до того, как сохранит как в thread0, так и в thread1.
x.store(true, std::memory_order_release); // thread0
y.store(true, std::memory_order_release); // thread1
Более того, без memory_order_seq_cst последовательное упорядочение thread2 и thread3 не гарантируется. Вы можете представить, что они становятся:
if (y.load(std::memory_order_acquire)) { ++z; } // thread2, load y first
while (!x.load(std::memory_order_acquire)); // and then, load x
if (x.load(std::memory_order_acquire)) { ++z; } // thread3, load x first
while (!y.load(std::memory_order_acquire)); // and then, load y
Итак, если thread2 и thread3 выполняются до thread0 и thread1, это означает, что x и y остаются ложными, таким образом, ++ z никогда не затрагивается, z остается 0 и Утверждает огонь.
Однако, если memory_order_seq_cst входит в изображение, он устанавливает единый общий порядок изменения всех атомарных операций, которые так помечены. Таким образом, в thread2 x.load затем y.load; в thread3, y.load, а затем x.load - это точно.
8 ответов
Вариант два является наиболее распространенным. В Java считается плохой практикой использовать бессмысленные префиксы или суффиксы имен, чтобы отличать переменные экземпляра от параметров от локальных переменных. Но для самих имен нет никаких условностей. Используйте любые имена, чтобы код было легче понять.
Я также видел вариант 2 как наиболее распространенный:
int importance;
public int getImportance()
{
return importance;
}
public void setFoo(int importance)
{
this.importance = importance;
}
IDE, такие как Eclipse и Netbeans, автоматически записывают геттеры и сеттеры в указанном выше формате.
У использования этого метода есть несколько преимуществ:
Не используется символ подчеркивания ( _ ) в имени поля - подчеркивание не рекомендуется для не -константные имена полей.
Использование символа подчеркивания в идентификаторе не рекомендуется, за исключением идентификаторов для констант.
значение, например static final int
NUM_GEARS = 6 , соглашение меняется
немного, с заглавной буквы
и разделяя последующие слова с
символ подчеркивания. Автор
соглашение, символ подчеркивания
никогда не используется где-либо еще.
(Курсив добавлен.)
Поскольку имена полей не являются константами, согласно тому, что написано на этой странице, не следует использовать подчеркивания в непостоянных полях.
IDE могут автоматически добавлять Документ Javadoc комментирует в соответствии с именем параметра метода, поэтому было бы полезно иметь имя поля в списке параметров.
Ниже приведен пример автоматически сгенерированного документа Javadoc:
/**
*
* @param importance <-- Parameter name in Javadoc matches
* the parameter name in the code.
*/
public void setImportance(int importance)
{
this.importance = importance;
}
Наличие в документации Javadoc отражения имя поля имеет еще одно преимущество - IDE, в которых есть автозавершение кода, могут использовать имя поля в Javadoc для автоматического заполнения имен параметров:
// Code completion gives the following:
this.getImportance(importance);
Придание значения имени поля и имени параметра упростит чтобы понять, что на самом деле представляет параметр.
Вот некоторые из достоинств, которые я могу придумать на данный момент,и я считаю, что это наиболее распространенный способ именования параметров в Java.
(1) очень написан на C / C ++. В Java не часто используются символы подчеркивания в начале.
Я лично использую (2) почти исключительно.
(3) просто усложняет вашу жизнь, потому что может быть трудно придумать два значимых, но кратких названия для член и параметр.
Я видел, что 2 и 3 используются чаще всего. Тем не менее, ответ продиктован принятым стандартом для кодовой базы, в которую вы вносите свой вклад. Я думаю, что важнее быть последовательным во всем проекте, чем иметь один «правильный» ответ для каждого отдельного Java-разработчика.
Генерация кода Eclipse использует стиль № 2 из вашего списка.
Я знаю, что когда netbeans автоматически создает геттеры и сеттеры, он использует метод номер 2. Лично я обычно добавляю temp к переменной, т.е. foo = tempfoo . Но, как говорит Ниш, вы должны стараться оставаться последовательными, независимо от того, какой метод вы выберете
Вариант 2.
Если вы видите определение "setFoo (String foo)" (например, в javadoc или при наведении указателя мыши), можно ожидать, что поле "foo" устанавливается равным значению параметра "foo". Другие имена могут потребовать от вас двойной проверки - например, setName (String person) просто установит имя для человека или будут предприняты дополнительные действия (найти имя в таблице лиц и т. Д.) ?.
Обычно этого не делают, потому что вы можете случайно написать
... foo = foo;
вместо
this.foo = foo;
, что является самоопределением параметра, который ничего не делает. Современные компиляторы это улавливают - современная среда IDE генерирует оператор this.foo = foo при создании установщика для поля.
В Eclipse вы можете создать геттер и сеттер для поля с помощью Ctrl-1, когда курсор находится на рассматриваемом поле.
я использую соглашение, согласно которому переменные-члены должны начинаться с m_; как в:
String m_foo;
Таким образом, очень ясно, какие переменные являются членами, а какие нет.
Кроме того, моя последняя компания предваряла все аргументы в методе с помощью «the», как в :
public doFoo (String theKey, String theRandom) {
....
}
очень легко не путать аргументы с внутренними переменными.
соглашения должны касаться создания код легче читать и сокращает количество ошибок.
As you code to make the interface as clear as possible, I always prefer using a field as _name internally, having it as name as a method argument, assigning it elegantly as _name = name. I have seen this in Fowler's Refactoring and other similar textbooks, though I see ugly mechanisms such as using the field as name internally then using aName as a method argument, ugh.