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

Новый комментарий
 
AlexeyStep:
Суть темы в том как грамотно и правильно собрать сова.

а покажите ка вашего самого лучшего собранного сова.

хочется посмотреть на каком уровне они у вас собираются. 

есть ли вобоще о чеи говорить (может тут и "в подметки" не годимся ;)

---

пессимист - параноик да, пока что выигрывает.


 

Думаю, данный вопрос достоин не одной статьи - слишком много правил...  

То, что вспомнилось сразу по именованиям:

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

Вот, например,  фрагмент моего кода - часть класса СINICore - основная функциональность INI-файла:


    bool                m_bHasOpened;

    CArrayString        m_asStartCommentaries;
    CMyArrayString      m_ssaSectionNames;
    CArrayObj           m_paSections;
   
    string              m_strStringBuffer;
   
    int                 m_iWriteDoublePrecision;


2. Глобальные именнованные констатны и перечисления пишутся Капсом.

3. Следует везде, где можно, заменять конструкцию #define статическим константным членом класса - это позволяет во-первых, проводить дополнительную проверку типов, а во-вторых, "привязывать" константу логически к объекту, с которым она работает. Фрагмент того же класса:

class CINICore: public CINIFileI
{
protected:

    static const ulong MAX_LENGTH_OF_STRING_IN_FILE;
    static const ulong MIN_LENGTH_OF_STRING_IN_FILE;

 
Хороший стиль - это когда другой программер, и даже не программер, и даже сам, понял чего накодил. )
 

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

 

 

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

 

 
C-4:
Согласен почти полностью. Члены таки удобно выделять и их почти все до сих пор выделяют.
 

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

Второй императив которуму надо неустанно следовать - это простота. Любой взятый логический сегмент кода должен быть очень очень прост. Если у Вас имеется участок "адского кода" который настолько сложен что даже сам автор его боится изменять, то значит этот императив наруше и это участок надо разбить на более простые сегменты.

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

Чертвертый принцип - это закрытость для изменений и открытость для расширений. Если ваш код приходится изменять всякий раз, когда в него вносятся незначительные изменения - значит скорее всего его архитектура не достаточно гибка и Вы не достаточно хорошо понимаете философию ООП. Расширение - это нечто другое. Например, если новые данные оказываются частным случаем данных для работы с которыми разработаны Ваши алгоритмы, то сами алгоритмы менять после появления новых типов данных не надо. Они как бы заранее уже учли все частные случаи. Насколько универсальны окажутся ваши алгоритмы, настолько хорошо вы будете готовы к потенциальным изменениям. Немного сумбурно написал, но по-другому пока не могу объяснить.

 
Нужно учитывать специфику MQL5, где this не всегда применим, например 
class A {
public:
        void f();

        int x;
};

void A::f()
{
        this.A::x = 0;
}
не компилируется, и СервисДеск считает что это правильно
 
A100:
Нужно учитывать специфику MQL5, где this не всегда применим, например не компилируется, и СервисДеск считает что это правильно
Конечно правильно. Ведь это все равно что написать: А.A::x = 0;
 
Если Вы не понимаете разницы, то у меня один аргумент, что в С++ все компилируется как надо. Кроме того обращение к члену через "->" в С++ говорит о том, что слева указатель. В MQL5 все обращения через "." и поэтому для понимания типа без Венгерской нотации в ряде случает не обойтись.
12345
Новый комментарий
Причина обращения: