Используете ли вы статьи в именах переменных?

Question

Редактировать: Кажется, что есть хотя бы две веские причины, по которым Smalltalkers делают это (удобочитаемость во время проблем с цепочкой сообщений и областью видимости), но, возможно, вопрос может оставаться открытым дольше для решения вопросов общего пользования.

Оригинал: По причинам, о которых я давно забыл, я никогда не использую статьи в именах переменных. Например:

Персона, Автомобиль, Объект

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

Недавно я начал изучать Smalltalk, главным образом потому, что я хочу изучать язык, на котором выросли и полюбили Мартин Фаулер, Кент Бек и многие другие великие люди.

Однако я заметил, что Smalltalker'ы, как представляется, широко используют неопределенные статьи ( a, ) в именах переменных. Хорошим примером будет следующий метод Setter:

name: aName address: anAddress.
     self name: aName.
     self address: anAddress

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

Вы используете это? Почему или почему нет?

Answer 1

Он обычно используется в Smalltalk как язык без типов, потому что он намекает тип аргумента в вызове метода. Сама статья сигнализирует, что вы имеете дело с экземпляром какого-либо объекта указанного класса.

Но помните, что в Smalltalk методы выглядят по-разному, мы используем так называемые ключевые слова, и в этом случае статьи действительно помогают удобочитаемости:

anAddressBook add: aPerson fromTownNamed: aString

Answer 2

Это соглашение об именах является одним из шаблонов в книге Кента Бека Шаблоны лучших практик Smalltalk . ИМХО, эта книга обязательна даже для тех, кто не говорит по-мелкому, так как она действительно помогает называть вещи и писать самодокументированный код. Кроме того, это, вероятно, один из немногих образцов языка, который показывает качество Александра без имени .

Еще одна хорошая книга по шаблонам кода - Smalltalk со стилем , которая доступна в виде бесплатного PDF .

Обычно принято, что переменные экземпляра и методы доступа используют пустое существительное, а параметры - неопределенный артикль плюс либо роль, либо тип, либо комбинация. Временные переменные могут использовать голые существительные, потому что они редко дублируют переменную экземпляра; альтернативно, довольно часто их называют с большей точностью, чем просто неопределенный артикль, чтобы указать их роль в потоке управления: eachFoo, nextFoo, randomChild ...

Answer 3

Я думаю, что только что нашел ответ. Как сказал Конрад Рудольф, они используют это соглашение по технической причине:

... это означает, что [ переменная метода ] не может дублировать имя переменной экземпляра, временной переменной, определенной в интерфейсе, или другой временной переменной. - IBM Smalltalk Tutorial

По существу, локальная переменная метода не может называться так же, как переменная объекта / класса. Исходя из Java, я предполагал, что переменные метода будут иметь локальную область видимости, и вы будете обращаться к переменным экземпляра, используя что-то вроде:

self address

Мне все еще нужно больше узнать о методе / локальной области видимости в Smalltalk, но, похоже, у них нет другого выбора; они должны использовать имя переменной, отличное от имени экземпляра, поэтому anAddress , вероятно, самый простой подход. Использование только адреса приводит к:

Name is already defined ->address

если у вас уже есть переменная экземпляра address , определенная уже ...

Answer 4

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

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

Я не знаю Smalltalk и не могу говорить о причинах «их» соглашений, но везде, как указано выше. может быть простой технической причиной, лежащей в основе соглашения Smalltalk (например, ALL_CAPS в Ruby, который является константой не только по соглашению, но и из-за семантики языка).

Answer 5

Я покачиваюсь, используя это. Я думаю, что это зависит от соотношения C ++ и Objective C в моих проектах в любой момент времени. Что касается основ и рассуждений, Smalltalk популяризировал понятие объектов как «вещей». Я думаю, что это были Yourdon и Coad , которые сильно подтолкнули описание классов от первого лица. В Python это будет что-то вроде следующего фрагмента. Мне бы очень хотелось, чтобы я мог вспомнить достаточно SmallTalk, чтобы собрать «правильный» пример.

class Rectangle:
    """I am a rectangle. In other words, I am a polygon
    of four sides and 90 degree vertices."""
    def __init__(self, aPoint, anotherPoint):
        """Call me to create a new rectangle with the opposite
        vertices defined by aPoint and anotherPoint."""
        self.myFirstCorner = aPoint
        self.myOtherCorner = anotherPoint

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

aRect <- [Rectangle createFromPoint: startPoint 
                    toPoint: otherPoint]

Это был просто очередной преходящий увлечение, которое до сих пор всплывает так часто. В последнее время я заметил, что имена членов, такие как myHostName, появляются в коде C ++ как альтернатива m_hostName. Я становлюсь все более очарованным этим использованием, которое, я думаю, немного прислушивается к идиомам SmallTalk.

Answer 6

Там, где я работаю, стандартом является добавление префикса ко всем полям экземпляра с «the-», локальных переменных с «my-» и параметров метода с «a-». Я считаю, что это произошло потому, что многие разработчики использовали текстовые редакторы, такие как vi, вместо IDE, которые могут отображать разные цвета для каждой области.

В Java я бы сказал, что предпочитаю это, чем писать сеттеры, где вы разыменовываете this .

Сравните

public void setName(String name) {
    this.name = name;
}

против

public void setName(String aName) {
    theName = aName;
}

Самое важное - это иметь стандарт и придерживаться его для всех.

Answer 7

Нет, не знаю. Я не чувствую, что это добавляет что-то к удобочитаемости или удобству обслуживания моей базы кода, и это никак не различает переменную для меня.

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

var person = new Person();
var aPerson = GetSomeOtherPerson();

Answer 8

Неа. Я чувствую, что это пустая трата пространства символов и ухудшает читабельность вашего кода. Я мог бы использовать варианты существительного, например, Персона против Людей в зависимости от контекста. Например

ArrayList People = new ArrayList();
Person newPerson = new Person();
People.add(newPerson);

Answer 9

Никогда не использовал, может быть, потому что на моем основном языке нет статей: P

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