Yapı kayaları. Programları yapılandırmayı, olasılıkları, hataları, çözümleri vb. keşfetmeyi öğreniyoruz.

 
Programların beceriksiz yapısı, özellikle projeler büyüdüğünde, çoğu zaman engelleyici geliştirme zorluklarına yol açar. Burada projelerin yapılandırılmasıyla ilgili tüm konuları tartışmayı öneriyorum.

En basit programlarla başlayıp karmaşık yazılım sistemleriyle biten.

--

Profesyonelleri bu konuyu desteklemeye çağırıyorum.

Konunun enginliğini ve "dini suçlamasını" ( * ) ve dolayısıyla şubenin olası karışıklığını ve olası çelişkisini anlıyorum.

Bununla birlikte, sizden desteklemenizi istiyorum, çünkü her katılımcının kendi yararı olabilir - mantıklı (yüksek potansiyele sahip) fikirler genellikle çöp yığınlarında bulunur, sadece zamanında fark edip "almanız" gerekir.

----

( * ) Bu bağlamda "dini suçlama" ile, programcıların program yapılarını sıklıkla alışkanlıklar, gelenekler ve edebi kaynaklar üzerine inşa ettikleri ve kendileri ve diğer insanlar için sağduyu ve beklenen gerçek kolaylıklar (çünkü örneğin, gelecekteki ortak yazarlar) .

 
İlk kim önde :). Bir şeye başla, bize nasıl göründüğünü söyle?
 
" Hatalar, hatalar, sorular " başlığından:
A100 2013.07.22 14:00  
MetaSürücü :

Yapı kayaları. İçerik ikincil, yapı birincildir.

Bir "Panel" var - yapı basit: Olay -> İşleme

Etkinlikler de basittir: bir düğmeye basmak, bir liste seçmek, takvim, fareyi hareket ettirmek vb.

Tasarımın başlangıcı için çok tipik bir sorun: gelecekte (programın) geliştirilebilmesi ve aynı zamanda halihazırda yapılmış olanı en az düzeyde yeniden yapabilmesi için bir programdaki olayların işlenmesinin nasıl organize edileceği (yapılandırılacağı).

Seçenekleri tartışmak ister misiniz?

 
MetaDriver :
" Hatalar, hatalar, sorular " başlığından:

Tasarımın başlangıcı için çok tipik bir sorun: gelecekte (programın) geliştirilebilmesi ve aynı zamanda halihazırda yapılmış olanı en az düzeyde yeniden yapabilmesi için bir programdaki olayların işlenmesinin nasıl organize edileceği (yapılandırılacağı).

Seçenekleri tartışmak ister misiniz?

Örneğin herhangi bir edebiyat var mı?

Genel olarak, tasarım konularının CAD ve TRIZ ile ortak bir yanı vardır.

Not Kağıda çiziyorum, benim için daha uygun, bazen net bir yapı ortaya çıkarken 50 sayfaya kadar çıkıyor. Özel editörlerde tabi ki yapabilirsiniz ama her biri benim için sakıncalı (sınırlı) oluyor, bir fantezi uçuşunu gerçekleştirmek mümkün değil kısacası işi yavaşlatıyorlar.

Система автоматизированного проектирования — Википедия
  • ru.wikipedia.org
Эту страницу предлагается объединить с CAx. Пояснение причин и обсуждение — на странице Википедия:К объединению/18 января 2014. Обсуждение длится одну неделю (или дольше, если оно идёт медленно). Дата начала обсуждения — 2014-01-18. Если обсуждение не требуется (очевидный случай), используйте другие шаблоны. Не удаляйте шаблон до...
 

bende en basiti

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

yapı ne demek

Not: Bana şöyle öğretildi:

1. bir fonksiyonda bir fonksiyonda mümkün olan her şeyi çıkarın

2. goto kullanmak günahtır

3. Tüm koşullar minimum olmalı ve tek bir koşulda kavşak olmamalıdır

4. 3 girinti

5. yaz, böylece senden sonra başka bir tane yapmak mümkün olacak

6. Anlaşılır ve anlamlı değişken isimleri

7. Yorum yapın, ancak aşırıya kaçmayın

işte buna benzer bir şey ama tam olarak bu değil: http://korzh.net/2011-03-pravila-xoroshego-tona-v-programmirovanii.html

Правила хорошего тона в программировании
  • korzh.net
Сегодня хотелось бы немного поговорит о качестве кода при программировании. Многие из нас не раз сталкивались с ситуацией, когда приходилось разбираться в чужом коде. Сколько же было матных слов произнесено при этом. Так давайте же обсудим некоторые правила, которые все и так знают. 1. Всегда делайте отступы Самое сложное, в неправильно...
 
Urain :

Örneğin herhangi bir edebiyat var mı?

Genel olarak, tasarım konularının CAD ve TRIZ ile ortak bir yanı vardır.

Not Kağıda çiziyorum, benim için daha uygun, bazen net bir yapı ortaya çıkarken 50 sayfaya kadar çıkıyor. Özel editörlerde tabi ki yapabilirsiniz ama her biri benim için sakıncalı (sınırlı) oluyor, bir fantezi uçuşunu gerçekleştirmek mümkün değil kısacası işi yavaşlatıyorlar.

CAD tamamen aynı değildir, ancak bilgisayar destekli tasarımdır.

programı yazmadan önce bile bana kağıt üzerinde eskiz yapmayı öğrettiler, basitleştirilmiş bir algoritmik dil ama buna hiç alışamadım.

 
FAQ :
İlk kim önde :). Bir şeye başla, bize nasıl göründüğünü söyle?

Şey, olacağından şüphelendim ...))

Saklayacak bir şeyim yok (yapılandırma açısından), tartışmaktan korkmuyorum.

Ancak size bunu hemen bir model olarak almanızı veya tam tersine aceleyle eleştirmenizi tavsiye etmiyorum: Kararlarımda kesinlikle "örnek" veya hatta herhangi bir uyum olduğunu varsaymıyorum - çoğu zaman özellikle sağlam değiller ve üretiliyorlar. aynı "dini" faktörler tarafından - alışkanlıklar, "kitap gerçekleri", forum makaleleri, terminalin standart teslimatından örnekler ve kafada kendiliğinden toplanan diğer çöpler. Bazı bulgular var, ancak özellikle ciddi bir şey yok.

Başlangıç olarak, dalda daha az kafa karışıklığı oluşması için birkaç uygun terimi kullanıma sokmayı önermek istiyorum (çok fazla olacağını tahmin ediyorum).

1) Projenin fiziksel yapısı : Projeye "dışarıdan" bakıldığında görünen dosya, klasör ve diğer varlıkların organizasyonu.

2) Projenin mantıksal yapısı: Tüm "iç" yazılım saçmalığının organizasyonu - değişkenler, işlevler, sınıflar, protokoller, vb. vb.

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

Mql projelerimin fiziksel yapıları ilkellik açısından oldukça basittir. Karışıklığı azaltmak ve olası karışıklığın sonuçlarını en aza indirmek için bilinçli olarak bunun için çabalıyorum.

Kural olarak (orta boyutlu olanlar için) bu, çok sayıda .mqh dosyası (uygun klasörlere ayrıştırılmış) + bir mq5 dosyasıdır.

// Sistem çok iş parçacıklıysa (örneğin, en basit durumda bir Uzman Danışman + göstergeler), mq5 dosyalarının sayısı projedeki programların sayısına karşılık gelir.

İkisini de kullanmamaya çalışıyorum (.ex5 ). // Çok tartışmalı bir karar. Ancak bunu çalışma zamanı sorunlarını en aza indirmek için yapıyorum.

--

Şimdilik projelerin mantıksal yapılarından bahsetmekten kaçınacağım - konu çok geniş, en azından bir nefes almanız gerekiyor... :)

 
sanyooooook :

CAD tamamen aynı değildir, ancak bilgisayar destekli tasarımdır.

programı yazmadan önce bile bana kağıt üzerinde eskiz yapmayı öğrettiler, basitleştirilmiş bir algoritmik dil ama buna hiç alışamadım.

Görevi bir bütün olarak sunmaya ve görevi oluşturan ana nesneleri vurgulamaya çalışıyorum.

Sonra nesneleri bileşenlere ayırıyorum, bileşenlerde kesişmeler arıyorum, sonra ata nesneler ortaya çıkıyor.

Bunun gibi bir şey.

ZY, projede daha önce karşılaşmış nesne özlerini bulursam, eski doğrulanmış kodu bağlamaya çalışırım.

ZZY Tasarımdan bahsediyorsanız, o zaman MQ stilini kabul etmeyi bırakmak yeterlidir, o zaman bir düğmeye basarak şekillendiricinin herkes için bir stili olacak ve her şey herkes için netleşecektir.

 
MetaDriver :

İkisini de kullanmamaya çalışıyorum (.ex5 ). // Çok tartışmalı bir karar. Ancak bunu çalışma zamanı sorunlarını en aza indirmek için yapıyorum.

Kitaplığı kullanmamak, .dll kullanmamak anlamına gelir ve ikincisini kullanmak, hem MQL4 hem de MQL5'te kullanılabildiğinden kod miktarından tasarruf sağlar.
 
Urain :

Görevi bir bütün olarak sunmaya ve görevi oluşturan ana nesneleri vurgulamaya çalışıyorum.

Sonra nesneleri bileşenlere ayırıyorum, bileşenlerde kesişmeler arıyorum, sonra ata nesneler ortaya çıkıyor.

Bunun gibi bir şey.

ZY, projede daha önce karşılaşmış nesne özlerini bulursam, eski doğrulanmış kodu bağlamaya çalışırım.

sen nesne yönelimli düşünüyorsun, ben işlevselim)
Neden: