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

It is in common use in Smalltalk as a typeless language because it hints the type of an argument in method call. The article itself signals that you are dealing with an instance of some object of specified class.

But remember that in Smalltalk the methods look differently, we use so called keyword messages and it this case the articles actually help the readability:

anAddressBook add: aPerson fromTownNamed: aString

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

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

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

self address

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

Name is already defined ->address

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

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

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

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

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

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

Я покачиваюсь, используя это. Я думаю, что это зависит от соотношения 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.

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

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

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

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

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

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

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

Сравните

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

с

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

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