Structure rules. Learning how to structure programmes, exploring possibilities, errors, solutions, etc.

[Vladimir Gomonov]

Clumsy program structure very often leads to exorbitant difficulties in development, especially when the projects grow. I propose to discuss here all the issues related to project structuring.

From the simplest programmes to complex software packages.

--

I urge the pros to support this thread.

I understand immensity of a theme and its "religious charge"(*), and consequently possible chaotic and potential conflict of a branch.

Nevertheless I ask for support as everyone can benefit - sensible (with high potential) ideas are often found in heaps of rubbish, one needs only to be able to notice and in time to "get hold of".

----

(*) By "religiously charged" in this context I understand the fact that program structures are often built by programmers on habits, traditions and literary sources, but not at all on common sense and expected real conveniences for oneself and other people (for example, future co-authors).

[Rustamzhan Salidzhanov]

First come, first served :). Why don't you start by telling us what it looks like for you?

[Vladimir Gomonov]

From the"Bugs, bugs, questions" thread:

A100 2013.07.22 14:00 # 

MetaDriver:

Structure rules. Content is secondary, structure is primary.

My "Panel" has the simplest structure: Event -> Handling

Events are also simple: button presses, list selections, calendar selections, mouse movements, etc.

Quite a typical problem to start designing: how to organise (structure) event handling in a program so that it (the program) can be further developed and at the same time minimal rework of what has already been done.

Do you want to discuss options?

[Mykola Demko]

MetaDriver:
From the branch"bugs, bugs, questions":

A very typical problem for the beginning of designing: how to organize (structure) the processing of events in a program so that it (the program) can be further developed and at the same time to redo what has already been done to a minimum.

Do you want to discuss options?

Is there any literature for example?

In general, design issues overlap with CAD and TRIZ.

I draw on paper, so it is more convenient for me, sometimes it takes up to 50 sheets until a clear structure is made out. Can certainly in spets.editors, but each of them for me uncomfortable (limited), impossible to realize a flight of fancy, in short, slow down the work.

[A100]

I have the simplest option

int main()
{
        while ( !IsStopped() )
        {
                switch ( GetEvent() ) {
                case TIMER   :
                case BUTTON  :
                case LISTVIEW:
                case CALENDAR:
                case CLOSE   :
                case ERROR   :
                default      :
                }
        }
}

[Alexandr Bryzgalov]

MetaDriver:

what is meant by structure?

ZS: I was taught this way:

1. Everything you can do in a function is in a function.

2. goto is a sin

3. All conditions must be minimal and there must not be any overlap in one condition

4. 3. indent

5. one has to write in such a way that others can read it after you

6. clear and meaningful variable names

7. comments, but don't overdo it

like this, but not quite like this: http://korzh.net/2011-03-pravila-xoroshego-tona-v-programmirovanii.html

[Alexandr Bryzgalov]

Urain:

Is there any literature for example?

In general, design issues overlap with CAD and TRIZ.

I draw on paper, it is more convenient for me, sometimes up to 50 sheets are spent until a clear structure emerges. You can, of course, use special editors, but each of them is inconvenient (limited) for me, it is impossible to realize a flight of fancy, in short they slow down the work.

CAD is not exactly the same, but it is computer-aided design.

Before writing a program, I was taught to make an outline on paper, a simplified algo language, but I'm not used to it.

[Vladimir Gomonov]

FAQ:
First come, first served :). Why don't you start by telling us what it looks like for you?

Well, I suspected that would be the case... ))

OK, I have nothing much to hide (in terms of structuring), I'm not afraid of discussion.

But I don't recommend that you immediately assume or hastily criticize - I don't assume "exemplary" or even any kind of harmony in my decisions - in their mass, they are not especially well-founded and generated by the same "religious" factors - habits, "book truths", forum articles, samples of standard terminal delivery and other spontaneous aggregated rubbish in the head. I have some findings, but nothing too serious.

To begin with, I would like to propose a couple of convenient terms, so that there would be less confusion (I suspect there will be plenty).

1) Physical project structure : The organization of files, folders and other entities visible at the "outside" view of the project.

2) Logical project structure: Organization of all the "internal" software stuff - variables, functions, classes, protocols, etc.

-----------------

The physical structure of my mql-projects is very simple and primitive. I consciously try to do this, to reduce confusion and minimize the consequences of possible confusion.

As a rule (for a medium-sized one) it is a set of .mqh files (arranged in appropriate folders) + one mq5-file.

// If the system is multi-threaded (for example, in the simplest case, the Expert Advisor + indicators) - then the number of mq5-files corresponds to the number of programs in the project.

I try not to use (.ex5) libs. // Very controversial decision, but I do it to minimize the runtime problems.

--

I'll refrain from commenting on logical project structures for the moment - the subject is very big and I need to take my breath away... :)

[Mykola Demko]

sanyooooook:

CAD is not quite the same, but it is computer-aided design.

I was taught to sketch out a simplified algo language before writing a program, but I never got used to it.

I try to visualise the problem as a whole, and identify the main objects that make up the problem.

Then I break down the objects into their components and look for intersections in the components, and then the ancestor objects appear.

That's how it is.

If I find some entities in the project, that have already been encountered, I try to use old, verified code.

If you are talking about design, just stop fighting and adopt MQ style, then one click of a styler button will give you all the same style and everything will be understandable to everyone.

[A100]

MetaDriver:

I try not to use libs (.ex5). // A very controversial solution, but I do it to minimise runtime problems.

Not to use library means not to use .dll, and using the latter saves the code volume, because it can be used in MQL4 and MQL5 at the same time

[Alexandr Bryzgalov]

Urain:

I try to visualize the task as a whole, and identify the main objects that make up the task.

Then I divide the objects into components, look for intersections in the components, and then ancestor objects appear.

That's how it is.

If I find object entities in a project that I've seen before, I try to include the old verified code.

You think in object-oriented way, I think in functional way )