Используете ли вы конкретные соглашения для обозначения дополнительных переменных?

Question

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

Это может быть лучше объяснено встречным примером. Я поддерживаю приложение, которое печатает две графики как часть рекламного объявления. Они хранятся в базе данных как и LowerLogo, которые я должен останавливать и проверять каждый раз, когда я их использую, потому что я ожидаю, что top дополняет bottom, а lower должен дополнять upper.

Там же некоторые очевидные примеры, которые я считаю работу хорошо:

client/server
source/target для копирования/перемещения данных или файлов из одной переменной в другую
minimum/maximum

но есть некоторые понятия, которые просто не поддаются таким опрятным схемам именования. Например, при пейджинге через записи, «последний» означает «окончательный» или «предыдущий»? Недавно я увидел какой-то код, который использовал firstPage, , nextPage и finalPage, чтобы полностью избежать целостного lastPage, который, как я думал, был очень избит, следовательно, этот вопрос.

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

Answer 1

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

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

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

Answer 2

Да, я пытаюсь называть дополнительные наборы переменных систематически, так что симметрия понятна. Это не всегда легко; иногда даже не возможно. Ну, не возможно, используя правила, которые я ложится для себя - это означает, что я обычно стараюсь иметь имена одинаковой длины. «Верхний» и «нижний» пример привел бы меня в смятение (предполагая, что я уже не бутовый, что далеко не точно); Я бы, вероятно, использовал «верхний» и «нижний», потому что они имеют одинаковую длину; «верх» и «нижняя» меня тоже сорвали из-за разницы в длине.

Answer 3

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

Проблема исчезнет, ​​если есть хороший JavaDoc или что-то еще, что такое система документации, и если у вас хорошие имена классов, которые идут с ними. Например, если у вас есть экземпляр класса Connection, и у него есть метод, называемый setDestination, это нормально, но если вы знаете, что setDestination принимает один параметр с именем destination, и он относится к классу Server, вы классный ... даже если вы можете назвать это target, aimHere, placeToSendTheData или whatever (и соответствующие им имена, source, comingFromHere и placeToGetTheDataFrom). Плюс система doc заявляет , что это за, и это бесценно.

Эта следующая вещь может показаться глупой, и я уверен, что я буду проголосовать здесь, на StackOverflow, но уникальные имена непрофессиональных зондирующих переменных имеют большое преимущество: я знаю, что мои переменные имеют такие имена, как placeWeWantTheDataToGo (и IDE позаботится о том, чтобы набирать его), но «серьезные» парни, которые делают JDK, будут никогда использовать такие глупые имена. Поэтому я сразу знаю, что переменная одна из моих. Кстати, когда я работал с разработчиками в Испании и Италии, они пишут код с именами испанских переменных (не всегда, но обычно). Это вызывает тот же эффект: мы можем быстро увидеть, что класс Conexion является нашим, но класс Connection - нет.

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

Answer 4

В моих базах данных вы найдете много временных («истории») таблиц, содержащих пару столбцов с именем start_date и end_date. Нет бонусных очков для меня, потому что я предпочел бы использовать обычно используемый «конец», чем пытаться придумать интуитивную альтернативу с тем же количеством символов, что и слово «начало».

Я предпочитаю эти общие термины, даже если более контекстно-зависимые термины могут быть жизнеспособными, например. предпочитая employee_start_date более employee_hire_date (что, если их занятость началась по другой причине, кроме формального найма, например, их компания была предметом приобретения). Тем не менее, я бы предпочел person_birth_date по сравнению с :)