Discussion of article "Tips from a professional programmer (Part I): Code storing, debugging and compiling. Working with projects and logs"

New comment
 

New article Tips from a professional programmer (Part I): Code storing, debugging and compiling. Working with projects and logs has been published:

These are some tips from a professional programmer about methods, techniques and auxiliary tools which can make programming easier.

Terminal program files are located under the MQL5 directory. This catalog is a so-called "sandbox". Data access from the outside is closed. This is a good decision. However, the use of a DLL probably enables access to anywhere.

For example, here is the structure of the Cayman project:

  • /Experts/Cayman/ - Expert Advisor
  • /Files/Cayman/ - data files (settings, parameters)
  • /Include/Cayman/ - library of classes (functions)
  • /Scripts/Cayman/ - main operational scripts
  • /Scripts/CaymanDev/ - developer scripts (used for debugging)

The main advantages of this placement are:

  • Contextual search only in project files via TotalCommander
  • Version control via Git (control is enabled only for the project files, while all other files are ignored)
  • Easy copying to another terminal (demo -> real – release)


Author: Malik Arykov

 

Thank you. Good, useful article.

 
Interesting ) I've attached my library with a link. I have six different terminals and it is very inconvenient when each terminal has its own copy of the library. But here it is always the same for all terminals. Do you use the .gitattributes file ? And if yes, in what form?
 
Good article. I used to always drag my documents to a non-system disc like this, just in case).
 

Bitbucket has its own quite normal bug tracker by default, you don't need to start an external one.

Links are for amateurs, it's easier to work through a repository, then the question about the number of copies simply does not arise

Interesting opinion about external editors, especially taking into account the author's love for scripts

 
Andrei Novichkov:
Do you use the .gitattributes file ? And if yes, in what form?

I don't use it, as there is no need. I don't care about binary files (including image, docx) and their deltas. I only care about the texts of my programmes and their history.

 
Andrei Trukhanovich:

Bitbucket has its own quite normal bug tracker by default, you don't need to start an external one.

Links are for amateurs, it's easier to work through a repository, then the question about the number of copies just doesn't arise

Interesting opinion about external editors, especially taking into account the author's love for scripts

1) A kanban board is not a bug tracker. I can manage tasks of several repositories (MQL4, MQL5, WebSite) of the Cayman project on one board.

2) I understood correctly that if I have two terminals with the same MQL5 content , then each MQL5 has a local repository and one common cloud repository. If so, let's imagine the situation. You make changes in one MQL5 and want to apply them to the second MQL5. Your actions:

  • push the first MQL5 - commit the version in the cloud
  • pull the second MQL5 - update the version.

Why so many steps?

3) I like comfort - to do a lot of work with one click on a script. NPP gives me the comfort of highlighting logs. For example, here I highlighted my log in NPP for an example. And highlighting of lines with tokens //, Error, todo is automatic, because it is written in the syntax of files with extensions *.txt, *.log

log highlighting

 

There are free plugins with kanban in bitbucket too.

Malik Arykov:

    Why go to so much trouble?

    Because it's the right thing to do.

    Different terminals - different instances, not to mention that in one terminal can be working in the second debugging and that terminals can differ radically in instrument settings and trading conditions.

    Plus there are nuances with the terminal picking up new compiled versions (tldr it is better not to compile the code at all if it is running on the terminal now).

    It is strange to start talking about repositories and then suggest using symbolic links, although, of course, they can be useful in certain situations.

     
    Andrei Trukhanovich:

    It's strange to start talking about repositories and then suggest using symbolic links, although of course they can also be useful in certain situations.

    Well, the links look at the same local repository (one MQL5 (*.mq?, *.ex?) for all terminals).

    At the same time, each terminal has its own peculiarities. For example, I have AppSettings.txt, parameters of analysers, terminal settings, etc. (specified in .gitignore)

    From each (any) terminal you can call "Edit" and be sure that you are correcting the same code.

     
    Malik Arykov:

    From each(any) terminal you can call "Edit" and be sure you are correcting the same code.

    That's exactly what's scary.)

    but the boss is the boss.

     

    Git now has private repositories.

    Native Git Desktop recognises mq4/mqh files as binary. Even if I specify diff in the attributes, it is not clear how to see changes in the application. What are some solutions to compare file versions conveniently?

    ----

    If you save files in MTEditor in UTF-8 encoding, you can see comparisons via Git Desktop

    12
    New comment