Standart özelliklerin/yaklaşımların alternatif uygulamaları - sayfa 9
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Sorunun artık oluşmaması ve güvenle unutulması sağlandı. Bir zamanlar yazdığınız koda geri dönmek zorunda kalmamanız harika. Çalışır - ana şey.
Pekala. Ben kendim bunu her zaman yapıyorum (ve bu sefer de gördüğünüz gibi).
Bir şey aniden değişirse sorun ortaya çıkacaktır. Kod açık olduğunda ve açık olmayan yerler iyi yorumlandığında, bazı değişikliklerle hataların nedenleri kolayca tespit edilebilir. Ancak bu gibi durumlarda "ve unuttum" - düzeltme yapmak çok daha zordur.
Evet, bunun nadir bir vaka olduğu açık… Ama bu çok nadir vakalar kişisel olarak beni çok tedirgin ediyor. O yüzden bu tür durumlarda mümkün olduğunca anlaşılır kodlar yazmaya çalışırım, anlaşılmayan yerleri detaylıca yorumlarım.
Şu anda hiç anlamadığım kodumun bir örneği. Ve anlamak için birçok faktörü çok iyi incelemek gerekir.
Gördüğünüz gibi, kod/stil çok basit. Ancak, aynı kodu yeniden yazabildiğimde bir hatayı veya yokluğunu tespit edebileceğim. Bu gerçekten çok uzun zaman alacak çünkü. sorunu tam olarak anlamanız gerekir.
Bu nedenle, ilke, karmaşık şeylerin oluşturma aşamasında yalanması (stres testleri yazılır) ve mqh'yi birbirine bağlayan basit bir biçimde kullanılmasıdır. Gördüğünüz gibi, anlamanın karmaşıklığı her zaman stil veya özlülük tarafından belirlenmez.
Tamamen dil yapılarının başka bir örneği daha var - TypeToBytes. Tamamen farklı bir düzeyde anlamakta zorluk var. Ve orada, makrolar olmadan solup giderdim. Yani makro kullanımından dolayı oldukça hızlı bir şekilde kaynak koda giriliyor. Çünkü makrolar çoğu zaman kısalık için değil, anlamak içindir.
Ve birçok basit ama unutulabilir tuzakları hesaba katmanız gerektiğinde başka bir durum daha var. MT4Orders'ta olan budur. Bu nedenle, bazı satırlara sadece kendilerine yönelik yorumlar eşlik ediyor. Kodunuzu anlamanıza yardımcı olur.
Ancak bunların hepsinin, işinize dahil olmanız gerekmeyen mqh olduğunu unutmayın. Ve araç kodu çok basit mqh kullanılarak yazılmıştır. Normal iHigh işlevlerinin kaynak koduna bakmak için tırmanmazsınız. Ama aslında o bir canavar. Sen sadece onları kullan. Aynı şey kütüphaneler için de yapılmalıdır. Kullanım için aynı Genel İncil, tam olarak anlaşılmasını gerektirmez.
MT4 Uzman Danışmanları ve MT5 bağlantı noktaları için KB'ye bakın. MT5 bağlantı noktalarının anlaşılması zor bir iştir. Sadece kısalık kokusu değil (kod orijinalinden birçok kat daha büyüktür), aynı zamanda mqh dosyalarında dikkate alınmayan MT5 tuzaklarının tıkır tıkır tıkır tıkır tıkır tıkır işlemesine de neden olur.
Açıkçası burada tartışacak bir şeyim yok. Açıkçası, programlamaya yaklaşımınızdan başlarsanız her şey doğrudur (belki aşırı ve haksız kod sıkıştırma durumları dışında), ancak benim yaklaşımımdan başlarsanız, o zaman çok şey yanlıştır.
1. Tabii ki, bulunması zor olan hatalar çok basit yazılmış kodlarda bile gizlenebilir. Ancak yazması zor olanlarda onları bulmak daha da zordur. Anlamı ortaya çıkarmak için zihinsel çabayı hesaba katın. Çok fazla çalışmanız gerekiyorsa (birçok işlev yazın, yeni mekanizmalar oluşturun, bunları mevcut olanlara başarıyla entegre edin), o zaman ana şey zamandan ve emekten tasarruf etmektir. Kodun "güzelliğine" bağlı değil. Stiller için değil. Kodunuzu, gecenin bir yarısı uyandığınızda kendiniz okuyup, bir an önce anlayabilmeniz için oluşturmalısınız. Kendinizden en iyi şekilde yararlanmak için kodunuzu oluşturmanın mükemmel yolunu aramaya başlarsınız. Ve buna bakarak:
böyle bir kaydın tüm dezavantajlarını hemen anlarsınız:
1. Çok sayıda karakter.
2. Aşırı "paketleme".
3. Yorumsuz matematiksel işlemler.
Böyle bir kod sormak, üstesinden gelinemez. Gücünüzün sınırına kadar çalışırsanız ve çok yorgunsanız, ustalaşmak da zordur. Her gün böyle çalıştığınızı hayal edin. Böyle bir koddan hemen uzaklaşacaksınız.
2. Başkasının koduna bakma ve sadece bağlan?
Büyük, ciddi ve en önemlisi yüksek kaliteli programların başkalarının bloklarından basit bir derleme ile oluşturulmadığına inanıyorum. Sadece küçük bir kısmını oluşturup geri kalanını takarak etkili bir program oluşturamazsınız. Vinaigrette olacak.
Çalışabilir ve çalışacaktır. Ancak bunlar "dizlerinin üstünde" programlardır.
Bloklardan bir araya getirilen programların etkinliğine inanmıyorum (geliştiricinin bakmadığı bile). Bu kurgu. Program topal ve çözümler etkisiz olacaktır. Birçok sorun olacak. Programcılar tek bir ekip olarak çalışır ve ortak bir sorunu çözerse, bu iyidir, ancak farklı insanların farklı programları arasında “yüzen” çözümler kullanılıyorsa (hala onlara bakmayan), bu bakış açısından saçmalıktır. verimlilik.
Çalışabilir ve çalışacaktır. Ama bunlar "diz çökmüş" programlar.
Yayınlarımı KB'de görebilirsiniz. Birileri onları kullanıyor olmalı.
Sadece kendim için ve dizlerimin üzerinde yazıyorum. Yayınlar bir yan üründür.
Bu yüzden LONG_MAX'ı kontrol edin - çifti uzunluğa dönüştürmeden önce bile olmalıdır. Yuvarlama işlevinin bir tam sayıya uymayan değerler için tasarlanmadığı açıktır. Ve bu sorunu değiştirmez.
Eğer fonksiyon bir double döndürürse ve bunu uzuna çeviririz, o zaman aynı taşma tehlikesiyle karşı karşıya kalırız.
Kişisel olarak, yuvarlamadan hemen önce, sınır değerleri için her zaman bir onaylama kontrolüm vardır, ayrıca, program mantığına göre, her zaman bir tamsayı için maksimum değerden daha büyük bir değerin asla dönüşüme gelemeyeceğini garanti ederim.
Sık sık char için uzun kullanır mısın? Çift ile aynıdır - bu hiyerarşinin son adımıdır, buna giremezsiniz, çoğu durumda bu gerekli değildir, std'de onunla çalışmak için her şey oradadır. Hiyerarşiyi küçümsemeyin ve onu terletmeyin.
LONG_MAX/MIN için kontroller ekleyin - ve bir şey bana performans testlerinin çok pembe olmayacağını söylüyor. Ve kişi standart değiştirmede sallandı, bu da tüm değer aralığında çalışması gerektiği anlamına geliyor.
Sık sık char için uzun kullanır mısın? Çift ile aynıdır - bu hiyerarşinin son adımıdır, buna giremezsiniz, çoğu durumda bu gerekli değildir, std'de onunla çalışmak için her şey oradadır. Hiyerarşiyi küçümsemeyin ve onu terletmeyin.
LONG_MAX/MIN için kontroller ekleyin - ve bir şey bana performans testlerinin çok pembe olmayacağını söylüyor. Ve kişi standart değiştirmede sallandı, bu da tüm değer aralığında çalışması gerektiği anlamına geliyor.
uzundan uzuna (ve tam tersi) - her zaman.
uzun char nadirdir.
Dönüştürme ihtiyacı, tamsayı ve kayan işlemlerin sonucunun önemli ölçüde farklı olması nedeniyle ortaya çıkar. Ve yürütme hızı, teoride, tamsayılı veriler için daha hızlıdır.
Bir aralığı kontrol etmeye gelince - vurguladım, ASSERT'e değer - yani, böyle bir kontrol sadece DEBUG versiyonunda çalışır. Herhangi bir genel işlevin başlangıcında, gelen tüm parametreler her zaman izin verilen aralık için onaylar kullanılarak kontrol edilir ve bu bana bir kereden fazla yardımcı oldu. RELEASE sürümleri - elbette, zaten herhangi bir kontrol olmadan çalışır.
Yayınlarımı KB'de görebilirsiniz. Birileri onları kullanıyor olmalı.
Sadece kendim için ve dizlerimin üzerinde yazıyorum. Yayınlar bir yan üründür.
Tecrübenizden ve profesyonelliğinizden şüphem yok.
Basitçe, birkaç yıl boyunca yorucu ve günlük programlama ve geliştirme sürecinde, belirli bir kodun, çözümün veya yaklaşımın faydalarını abartmaya başlarsınız. Ve çoğu zaman, çok garip sonuçlara varırsınız... Garip, ancak geniş uygulama ile doğrulanmıştır.
Ben sadece görüşümü paylaştım.
Dönüştürme ihtiyacı, tamsayı ve kayan işlemlerin sonucunun önemli ölçüde farklı olması nedeniyle ortaya çıkar.
Çiftlerde hangi durumlarda bir şeyin düzgün yapılamayacağını hayal edemiyorum. Lua'da (quik'e bağlı) tamsayı türleri yoktur, yalnızca bir çift vardır ve hiçbir şey yoktur.
Çiftlerde hangi durumlarda bir şeyin düzgün yapılamayacağını hayal edemiyorum.
Tezgah.
double tüm int-aralığın bilgisini kaybetmez, long ile durum böyle değil .
Tezgah.
Eh, hala çok fazla saymanız gerekiyor))). Ve eğer gerçekten istiyorsanız, o zaman bir seçenek olmayan nedir:
Eh, hala çok fazla saymanız gerekiyor))). Ve eğer gerçekten istiyorsanız, o zaman bir seçenek olmayan nedir:
Evet, saptırmanın mümkün olduğu açıktır. Ama buna değer mi?
Bir değişkenin anlamına göre, sadece tamsayı değerlerine sahip olması gerekiyorsa, tamsayı olması gerektiğini düşünüyorum, böylece içine kayan bir değer yazmak imkansız olurdu. Değişkenin türü veya dönüş değerinin kendisi, değişken hakkında ve kısmen algoritma hakkında zaten önemli bilgiler taşır. Her yerde kayan değerler kullanırsak bu bilgiler kaybolacaktır.
Ve bir tamsayı bile - algoritmaya bağlı olarak, bence, ya imzalı ya da imzasız olarak bildirilmelidir, ayrıca, mutlaka uzun değil, hatta belki "daha kısa" - sadece koda bakmak için - kişi hangi aralığı hemen anlayabilir? Bu değişkenin izin verdiği değerlerin sayısı .
Lua'da tamsayı değerlerinin olmaması bence ciddi bir eksi.