Как грамотно и правильно собрать сова? [стиль MQL5] - страница 3

Новый комментарий
 
A100:
Если Вы не понимаете разницы, то у меня один аргумент, что в С++ все компилируется как надо.
А зачем там this вообще?
 
A100:
Если Вы не понимаете разницы, то у меня один аргумент, что в С++ все компилируется как надо. Кроме того обращение к члену через "->" в С++ говорит о том, что слева указатель. В MQL5 все обращения через "." и поэтому для понимания типа без Венгерской нотации в ряде случает не обойтись.

С++ строчку "define true false" откомпилирует. Это не показатель вообще.

Я понял, вы предлагаете писать: this.this.this.A::Doom(); - и наивно удивляетесь почему MQ этого не понимает.

TheXpert:
А зачем там this вообще?
Скажу больше, зачем там this.A вообще?:))
 
C-4:
Скажу больше, зачем там this.A вообще?:))
Разрешение контекста. Запрашиваемый член может быть нужен от базового класса.
 
TheXpert:
Разрешение контекста. Запрашиваемый член может быть нужен от базового класса.
Да, об этом не подумал.
 
C-4:

Я понял, вы предлагаете писать: this.this.this.A::Doom(); - и наивно удивляетесь почему MQ этого не понимает.

Это Ваше предложение, а мое было выше - с одним this. И прежде чем предлагать такое - попробуйте сначала скопилировать это в С++ 
C-4:

С++ строчку "define true false" откомпилирует. Это не показатель вообще.

#define - это предпроцессор -  заменить до компиляции все слова true на false -  в чем здесь ошибка?

 
TheXpert:
А зачем там this вообще?
Для единого стиля программирования
this.A::X
this.   Y
     B::Z

нет единого стиля, когда у Y может быть this, а у Z - нет.

 Отсутствие единого стиля - затрудняет чтение.

 
A100:
Ну я чего спросил... Я его просто пипец как редко использую и явно оно нужно чаще всего только лишь в выражениях типа return *this.
 

"Хороший стиль" - сколько людей столько мнений. Хорошим он должен быть для Вас. Не кому-то, а Вам должно быть комфортно читать код! Никого не слушайте, учите С++. Нормальный С++, а не mql (рассматривать его стоит не более как диалект). Стиль никак не поможет вам собрать советника(. Это не вопрос стиля, это вопрос здравого смысла делайте то (код), что должны (согласно ТЗ или идеи), это не должна быть писулька "как у всех" или "как принято". Вам привели вырезку из умной книжки. Вам повезло)? Не думаю...

Просили совет - учитесь самостоятельно - сэкономите кучу времени и нервов. 

 
Насчёт нотации с префиксами: это не для удобства читателя кода - она полезна писателю, бо позволяет чисто глазками, на автопилоте проводить 1ю отладку кода. Т.е. полезна как раз для начинающих
 
C-4:

to:AlexeyStep Вы только учитывайте, что люди, дающие Вам ответы, могли изучать программирование еще лет 20 назад и не в курсе современных тенденций. Вот Вам на размышление отрывок из книги "Чистый код" Роберта Мартина, которую я настоятельно рекомендую прочитать каждому, в особенности так называемым местным "гурам", большинство из которых застряли на уровне 80-ых:

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

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

while (nА < nB)

    {

    ....

    ++nA;

    };


Никаких багов быть вроде как не должно.

А я несколько раз встречался с ситуацией, когда этот код в строгой венгерской нотации должен был быть написан так:

byte btA;

...

integer iB;

...

while (btА < iB)

    {

    ....

    ++btA;

    };


Здесь потенциальная проблема уже явно видна, и может привести к нестабильности работы в НЕКОТОРЫХ случаях - то есть к  трудновыявляемым ошибкам.

Большинство компиляторов не выдают в этом коде варнингов, несмотря на то "в современных компиляторах обеспечивается проверка типов и обеспечение их сохранения".

12345
Новый комментарий