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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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