Соглашения об именах методов для общего типа функций

Описание проблемы

Я часто думаю о названии метода для функции, о которой я пишу. Как установщики и получатели, чтобы изменить или получить состояние объекта. Может быть, я использую объекты не правильно, но я часто нахожусь в ситуациях, когда использование сеттеров и геттеров кажется не совсем подходящим. У меня есть несколько конкретных вопросов.

Вопросы

  1. Является ли предпочтительным использование стандартизированных имен методов или, скорее, имен методов, которые относятся к области решаемой вами проблемы? (Например, в игре вы можете использовать логический вон isWinner()).
  2. Когда будут уместны сокращения? И как вы должны сокращать? Я часто создаю аббревиатуры, когда мне приходится много писать, но это кажется плохим критерием, потому что рецензенты кода должны, на мой взгляд, отказаться от метода и понять, что происходит. С "как вы должны сокращать" я имею в виду это: должен message быть; msg, mesи, например, average; avg, av, или же initializing, init, initialize так далее..
  3. Есть ли причины, по которым вы должны поставить основной функционал методов в конце? Например, welcomeMsg() (функциональность в конце), msgWelcome() (функциональность спереди).
  4. У вас есть только 3 различных метода? Сеттеры (используются для обновления, инициализации), геттеры и тесты условий? Таким образом, вы можете увидеть все методы между этими 3?

Особые ситуации

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

  • welcomeMessage() {} //could be either msgWelcome, welcomeMsg, there will be many more messages. What is a good way for message method names?

  • initialiseGame() {} //could as well be initGame or setupGame changing, ugh.

  • checkIfWon() {} //hasWon() is probably better.

  • askUserInput() {} //seems like a common thing to do, what is a good way to do this, is creating a method for this common or do people often do this inline within an other method? The userinput should match specific conditions.

  • countMatches() {}//to check how many of the letters given by the userInput match the hidden word. calculateMatches(), enumMatches(), enumerateMatches(), getMatches all seem plausible alternatives.

  • containsOnlyLetters(String string) {}//checks if input contains only letters. isOnlyLetters() makes it more clear that it is a boolean, but seems to be further away from problem description.

Источник

2 ответа

Решение

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

  1. Является ли предпочтительным использование стандартизированных имен методов или, скорее, имен методов, которые относятся к области решаемой вами проблемы?

Когда я могу, я использую язык домена для имен методов и пытаюсь сделать эти имена глаголами. Например, bankAccount.Deposit(new Money(200)); вместо bankAccount.setMoney(new Money(200));

Использование языка предметной области обычно выглядит лучше и делает ваши объекты более абстрактными и приближенными к тому, что вы на самом деле моделируете. Когда вы не можете придумать подходящее доменное имя для метода, я обычно прибегаю к стандартным префиксам (get, set, is / has / etc).

  1. Когда будут уместны сокращения? И как вы должны сокращать?

Я почти никогда не сокращаю. Конечно, это неприятно видеть и писать длинные имена методов, но вы часто пользуетесь автозаполнением IDE. Я лично нахожу это раздражающим видеть переменную / метод / имя класса, которые сокращены. Это заставляет меня остановиться на секунду и попытаться понять смысл. Мне нравится код, который хорошо читается, и я думаю, что сокращения сокращают читабельность. Хотя есть несколько хороших сокращений. НХЛ, НФЛ и т. Д. Существуют также общие сокращения, такие как msg для сообщения, num для номера и т. Д. Я не обязательно ОБНИМАЮ их, но для согласованности я обычно вообще не сокращаю. Я бы сказал, чтобы быть последовательным, но больше склоняться к сокращению.

  1. (а) Есть ли причины, по которым вы должны поставить основной функционал методов в конце?

В этих случаях я хожу с тем, что читается лучше. Используя этот метод в коде, он лучше читается как: System.out.println(hangmanGame.welcomeMessage()); или же System.out.println(hangmanGame.msgWelcome());? Я предпочитаю первое. Если бы я писал это, я бы превратил этот метод в глагол, и, вероятно, System.out.println(hangmanGame.getWelcomeMessage());

  1. (б) У вас есть только 3 различных метода? Сеттеры (используются для обновления, инициализации), геттеры и тесты условий?

Да, это только 3 типа методов, которые у вас есть. Технически у вас есть только два типа: мутаторы и аксессоры (сеттеры, геттеры), так как возвращение логического значения является геттером. Итак, вы либо вызываете метод объекта, чтобы изменить его состояние, либо получить его состояние.

Bullet1: ответ в 3(а)

Bullet2: на самом деле не имеет значения, но если вам нужно мнение, мне нравится setupGame. В области игры игры настраиваются, а не инициализируются:).

Bullet3: мне больше нравится hasWon(). если (player.hasWon()) вместо if (player.checkIfWon()),

Bullet4: Я предпочитаю getMatches() здесь, но тем более getMatchCount() (если вы ищете то, чего хотите). Мне нравится префикс get, потому что он сообщает программисту, что метод возвращает что-то. Из countMatches() вы не знаете, не посмотрев на сигнатуру метода, вернет ли он что-то или нет.

Bullet5: я разорваюсь на этом, но если бы мне пришлось выбирать, я бы пошел с containsOnlyLetters, потому что класс Java String имеет функцию содержит. Пока имя метода звучит так, как будто вы опрашиваете класс, разумно предположить, что он возвращает логическое значение. То есть вам не нужно использовать префикс is.

Надеюсь это поможет.

Источник

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

  2. просто сокращайте по своему вкусу и будьте последовательны. Например: msg/mes, init, alloc, avg/ medium, min & max. Если это так же понятно, но короче, то это хорошо для использования.

  3. Я хотел бы сделать это обязательной командой, такой как showWelcomeMsg() или showMsg(WELCOME), таким образом, намного яснее, что на самом деле произойдет. Если это не функция, я бы выбрал welcomeMsg, так как она выглядит лучше.

Подойдут initGame (больше похоже на инициализацию состояния игры, но не на ее создание) или setupGame (функция "все в одном"). Выиграл, нет необходимости быть излишне многословным. getMatchesCount - это нормально, чтобы получить только счетчик, так как вам также нужно отображать их, я бы заставил getMatches возвращать массив со всеми совпадающими буквами. countMatches не совсем ясно, какое возвращаемое значение. Это также может быть void и устанавливать внутренние переменные и т. Д. IsOnlyLetters (public) или lettersOnly (private/local).

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

Источник
Другие вопросы по тегам