Hatalar, hatalar, sorular - sayfa 3121
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Biri biliyorsa, lütfen bana bildirin. Mevcut bir kodun yeni bir sürümünü CodeBase'e yüklerseniz, önceki seçmenin yeniden oy kullanma yasağı sıfırlanır mı ve yeni sürüm için yeniden oy kullanabilirler mi? Kendim bundan kesinlikle şüpheliyim, ancak böyle bir fırsat olsaydı, kod geliştiğinden ve yenisinin (varsayımsal olarak öncekinden daha düşük olmayacak şekilde tasarlanmıştır) yerine önceki derecelendirmeyi sıfırlamak adil olurdu. yeni sürüm seçmeni daha fazla tatmin edebilir ve eski kod için eski derecelendirme artık geçerli olmayacaktır. (Ancak, işlevselliğin artmasıyla birlikte kod da büyür ve bu nedenle yeni hatalar ve aksaklıklar olabilir, daha da çirkin olabilir. Her şey olabilir ... ve yeni tahmin daha düşük olabilir, ama bu bana uyuyor .)
Evet, ... kodlarınızın düşük derecelendirmesi için saçınızı yırtmayı bırakın. Bir kişi kodunuza 1 puan verdiyse, bu kodun böyle olduğu anlamına gelmez. Pekala, en az 100 kez yeniden yapın ... ve bu kodun 100 kez tamamı bu şekilde değerlendirilecektir. anlamak çok mu zor?
Evet, ... kodlarınızın düşük derecelendirmesi için saçınızı yırtmayı bırakın. Bir kişi kodunuza 1 puan verdiyse, bu kodun böyle olduğu anlamına gelmez. Pekala, en az 100 kez yeniden yapın ... ve bu kodun 100 kez tamamı bu şekilde değerlendirilecektir. anlamak çok mu zor?
Belki de özgeçmişiniz oylama alanındaki gerçek durumu yansıtıyor ve bu üzücü. Ama kendim için üzülmüyorum - bu sanal yıldızları çayla içip cüzdanınıza koyamazsınız, ürünleri yeni kullanıcılara sunmanın bir yolu konseptinde hayal kırıklığına uğradım, onlar için endişeleniyorum. Güvenilir bir derecelendirme/derecelendirme olmadığında, kullanıcılar istedikleri ürünü "Dereceye Göre Sırala" ile verimli bir şekilde arayamazlar. Derecelendirme sisteminin bir kukla olduğu ve istenen ürünü ada / açıklamaya göre aramaya devam ettiği ve aptal yıldız sayısına güvenmediği ortaya çıktı. Aksi takdirde, yüzeyde yüzen (haklı ya da değil) her şeyi yakalayacaklar, ancak gerçekten ihtiyaçları olan şey gözden kaçırılacak. Sadece daha düşünceli olması için değiştirmeyi önerdim. Ama kimse böyle bir gerçekle savaşmayacaksa, ellerimi yıkıyorum.
Belki de özgeçmişiniz oylama alanındaki gerçek durumu yansıtıyor ve bu üzücü. Ama kendim için üzülmüyorum - bu sanal yıldızları çayla içip cüzdanınıza koyamazsınız, ürünleri yeni kullanıcılara sunmanın bir yolu konseptinde hayal kırıklığına uğradım, onlar için endişeleniyorum. Güvenilir bir derecelendirme/derecelendirme olmadığında, kullanıcılar istedikleri ürünü "Dereceye Göre Sırala" ile verimli bir şekilde arayamazlar. Derecelendirme sisteminin bir kukla olduğu ve istenen ürünü ada / açıklamaya göre aramaya devam ettiği ve aptal yıldız sayısına güvenmediği ortaya çıktı. Aksi takdirde, yüzeyde yüzen (haklı ya da değil) her şeyi yakalayacaklar, ancak gerçekten ihtiyaçları olan şey gözden kaçırılacak. Sadece daha düşünceli olması için değiştirmeyi önerdim. Ama kimse böyle bir gerçekle savaşmayacaksa, ellerimi yıkıyorum.
Tamam, şimdi kodunuza bir göz atalım.
Her tıklamada, bir seferde 4 istek olmak üzere global değişkenlere erişim tetiklenir
Bundan, böyle bir kodu kişisel bir makinede kullanmanın İMKANSIZ olduğu sonucuna varır, sabit disk için üzülmediğiniz başka birinin üzerinde bir yerde yapabilirsiniz.
Döngüde, bir döngü üzerinden yineleme yaparken 3 kez ArraySize çağırmanız gerekiyor ve bunlardan ikisi var, bu işlemciye fazladan bir yük oluyor, bunu yapmak da istenmiyor, kod performansı düşüyor.
DeInite'ta nesneler garip bir şekilde siliniyor, endişelenecek bir şey yok, ancak yeni başlayanlar için kötü bir örnek, normal şekilde yapılırsa, daha sonra nesne oluştururken bir önek girin ve gereksiz yeniden hesaplamalar yapmadan silin.
Kodunuz için 2 puan veriyorum.
Göstergenin çalışması için - Bilmiyorum, başlatmadım.
Objektif olarak mı?
Tamam, şimdi kodunuza bir göz atalım.
Her tıklamada, bir seferde 4 istek olmak üzere global değişkenlere erişim tetiklenir
Bundan, böyle bir kodu kişisel bir makinede kullanmanın İMKANSIZ olduğu sonucuna varır, sabit disk için üzülmediğiniz başka birinin üzerinde bir yerde yapabilirsiniz.
Döngüde, bir döngü üzerinden yineleme yaparken 3 kez ArraySize çağırmanız gerekiyor ve bunlardan ikisi var, bu işlemciye fazladan bir yük oluyor, bunu yapmak da istenmiyor, kod performansı düşüyor.
DeInite'ta nesneler garip bir şekilde siliniyor, endişelenecek bir şey yok, ancak yeni başlayanlar için kötü bir örnek, normal şekilde yapılırsa, daha sonra nesne oluştururken bir önek girin ve gereksiz yeniden hesaplamalar yapmadan silin.
Kodunuz için 2 puan veriyorum.
Göstergenin çalışması için - Bilmiyorum, başlatmadım.
Objektif olarak mı?
1. Her onayda, tam olarak GP'ye bir çağrı vardır, böylece her onayda ve her yeniden başlatmada (örneğin, TF'ler üzerinden geçişler), OnCalculate() içindeki tüm ana ve daha ağır kod yürütülmez ve göstergesi daha hızlı çalışır. Yeni verilerin hesaplanması - yalnızca her keneden çok daha nadir olan yeni bir alt çubuğun görünümü ile D1 .
2. Kod üzerinde dikkatli ve kapsamlı bir şekilde çalıştım, ancak if() içinde bazı denetlenmemiş gereksiz karşılaştırma işlemleri bıraktım, çünkü performansın bundan zarar görmeyeceğini kesinlikle biliyorum.
3. İMKANSIZ hakkında - çok abartılı. İndirip kendiniz görebilirsiniz: gösterge uçar.
4. GP'lerin demiryoluna atıldığını bilmiyordum ve daha sonra çalışan MT5 oturumunda her erişildiğinde oradan okunuyorlar. Hala, terminal başlatıldığında ve zaten orada yaşadığında HDD'den bir kez RAM'e okunduklarını ve göstergenin HDD'ye değil RAM'de onları çağırdığını düşünüyorum.
5. ArraySize() 'nin pahalı bir özellik olduğunu düşünmüyorum. Ve eğer pahalıysa, o zaman bu özel kodda bu fark edilmeyecektir. Bu işlevin sıklıkla bulunduğu ve göstergenin kendisinin çok daha karmaşık ve kaynak yoğun olduğu ilk göstergemde muhtemelen bu konuda optimize ederdim.
6. OnDeinit() içinde şunu kullanıyorum:
tam olarak "l" ön ekiyle bir silmenin olduğu yerde (nesneler oluşturulurken " l abel " ve "line" isimleri kullanıldı.
7. Şimdi kodu indirip anlayan bir kullanıcının yapması gerekeni yaptınız. Kusurlar buldunuz - bu aynı zamanda MQL öğrenmenin bir parçasıdır.
8. Özetle: 1.) bu belirli göstergenin ideal olmayan bir kodunun izin verilebilirliği konusundaki temel argümanım basitlik, kompaktlık ve hatta bu hız olmadan... artı tasarlananın ideal çalışmasıdır; 2.) ideal olmayan kod için ikinci ana argümanım, hız ve çok yönlülük açısından kötü analogların bile olmaması (başka birinin orijinalinin tartışmasına bakın) ve orijinaline kıyasla iyileştirmelerin varlığıdır, bu arada, dar odaklıdır ve aynı tipte çok sayıda tekrar eden blok açısından kompakt döngülere katlanmaz.
9. 7. paragrafa rağmen, başka birinin kodunu gerçekten anlamadınız. 2 puanın çok düşük. Yazılım ürünlerini koda göre değerlendirmenizi henüz tavsiye etmem. Objektiflik hakkında bir şey söylemeyeceğim çünkü prensipte herhangi bir kullanıcıdan objektiflik beklemek imkansız. Objektif bir değerlendirme (derecelendirme) sadece birkaç aklı başında kullanıcının değerlendirmelerinin toplamı şeklinde mümkündür ve kesinlikle yüksek olması gerekmez.
1. Her onayda, tam olarak GP'ye bir çağrı vardır, böylece her onayda ve her yeniden başlatmada (örneğin, TF'ler üzerinden geçişler), OnCalculate() içindeki tüm ana ve daha ağır kod yürütülmez ve göstergesi daha hızlı çalışır. Yeni verilerin hesaplanması - yalnızca her keneden çok daha nadir olan yeni bir alt çubuğun görünümü ile D1 .
2. Kod üzerinde dikkatli ve kapsamlı bir şekilde çalıştım, ancak if() içinde bazı denetlenmemiş gereksiz karşılaştırma işlemleri bıraktım, çünkü performansın bundan zarar görmeyeceğini kesinlikle biliyorum.
3. İMKANSIZ hakkında - çok abartılı. Göstergenin uçtuğunu indirebilir ve kendiniz görebilirsiniz.
4. GP'lerin demiryoluna atıldığını bilmiyordum ve daha sonra çalışan MT5 oturumunda her erişildiğinde oradan okunuyorlar. Hala, terminal başlatıldığında ve zaten orada yaşadığında HDD'den bir kez RAM'e okunduklarını ve göstergenin HDD'ye değil RAM'de onları çağırdığını düşünüyorum.
5. ArraySize() işlevinin pahalı bir işlev olduğunu düşünmüyorum. Ve eğer pahalıysa, o zaman bu özel kodda bu fark edilmeyecektir. Bu işlevin sıklıkla bulunduğu ve göstergenin kendisinin çok daha karmaşık ve kaynak yoğun olduğu ilk göstergemde muhtemelen bu konuda optimize ederdim.
6. OnDeinit() içinde şunu kullanıyorum:
tam olarak "l" ön ekiyle bir silmenin olduğu yerde (nesneler oluşturulurken " l abel " ve "line" isimleri kullanıldı.
7. Şimdi kodu indirip anlayan bir kullanıcının yapması gerekeni yaptınız. Kusurlar buldunuz - bu aynı zamanda MQL öğrenmenin bir parçasıdır.
8. Özetle: 1.) bu belirli göstergenin ideal olmayan bir kodunun izin verilebilirliği konusundaki temel argümanım basitlik, kompaktlık ve hatta bu hız olmadan... artı tasarlananın ideal çalışmasıdır; 2.) ideal olmayan bir kod için ikinci ana argümanım, hız ve çok yönlülük açısından analogların olmaması (başka birinin orijinalinin tartışmasına bakın) ve bu arada, orijinaline kıyasla iyileştirmelerin varlığıdır. dar odaklıdır ve çok sayıda benzer şekilde tekrarlanan blok açısından kompakt döngülere katlanmaz.
9. 7. paragrafa rağmen, başka birinin kodunu gerçekten anlamadınız. 2 puanın çok düşük. Yazılım ürünlerini koda göre değerlendirmenizi henüz tavsiye etmem. Objektiflik hakkında bir şey söylemeyeceğim çünkü prensipte herhangi bir kullanıcıdan objektiflik beklemek imkansız. Objektif bir değerlendirme (derecelendirme) sadece birkaç aklı başında kullanıcının değerlendirmelerinin toplamı şeklinde mümkündür ve kesinlikle yüksek olması gerekmez.
Ön ek ile silme şu şekildedir: ObjectsDeleteAll(0,"pref_"); // " pref_l abel " ve " pref_line "
En azından OnCalculate'deki ilk satırdaysa, çağrının şimdi olduğu gibi her onayda değil, yeni bir çubukta olması için ekleyin.
Ön ek ile silme şu şekildedir: ObjectsDeleteAll(0,"pref_"); // " pref_l abel " ve " pref_line "
En azından OnCalculate'deki ilk satırdaysa, çağrının şimdi olduğu gibi her onayda değil, yeni bir çubukta olması için ekleyin.
Bu arada, 7. paragrafla ilgili olarak: MQL5 Belgelerinde bile yıllardır düzeltilmeyen hatalarla karşılaştım.
Ön ek ile silme şu şekildedir: ObjectsDeleteAll(0,"pref_"); // " pref_l abel " ve " pref_line "
Ön ekin başlangıcı dinamik olduğundan, önerdiğiniz gibi silmek için makul bir olasılık yoktur: {D1} veya {W1} veya {MN1} ve ancak o zaman değişmez önek "l. ..". Dinamik ve statik önekleri değiştirebilir ve tercihinize göre güvenle silebilirsiniz, ancak bu mantıksızdır, çünkü bilgileri " R1 olarak algılamak sakıncalıdır. {D1} ", ama daha uygun olarak "{D1} R1". Bütün bunları uzun zaman önce düşündüm ve aynen yaptığım gibi yaptım.
Ön ekin başlangıcı dinamik olduğundan, önerdiğiniz gibi silmek için makul bir olasılık yoktur: {D1} veya {W1} veya {MN1} ve ancak o zaman değişmez önek "l. ..". Dinamik ve statik önekleri değiştirebilir ve tercihinize göre güvenle silebilirsiniz, ancak bu mantıksızdır, çünkü bilgileri " R1 olarak algılamak sakıncalıdır. {D1} ", ama daha uygun olarak "{D1} R1". Bütün bunları uzun zaman önce düşündüm ve aynen yaptığım gibi yaptım.
DrawTheLine( "pref" +line_types[lt], StYine de, evet, prensipte mümkün ve öyle. Yukarıda, şu anda şunu düşünerek ünlü bir şekilde açıkladım:
nesnelerin adıyla ilgili değil. Sonuçta, grafikte okunan tam olarak etiketler için OBJPROP_TEXT kullanılarak ayarlanan şeydir , ancak nesnelerin adları daha az okunabilir şekilde imzalanabilir, çünkü bunlar gizlidir ve nadiren herkes tarafından okunur.
Öte yandan, "Nesnelerin listesi"nde (Ctrl + b) nesnelerin insan tarafından okunabilir adlarını görmek arzu edilir, bu nedenle benim sürümüm hala tercih edilir. Ayrıca, nesne adlarının aşırı uzun olmaya zorlandığı zamanlar vardır, bu nedenle fazladan "pref_" tamamen geçersiz olur.Yine de, evet, prensipte mümkün ve öyle. Yukarıda, şu anda şunu düşünerek ünlü bir şekilde açıkladım:
nesnelerin adıyla ilgili değil. Sonuçta, grafikte okunan tam olarak etiketler için OBJPROP_TEXT kullanılarak ayarlanan şeydir , ancak nesnelerin adları gizli olduklarından ve nadiren herkes tarafından okunduğundan daha az okunabilir şekilde imzalanabilir.
Öte yandan, "Nesnelerin listesi"nde (Ctrl + b) nesnelerin insan tarafından okunabilir adlarını görmek arzu edilir, bu nedenle benim sürümüm hala tercih edilir. Ayrıca, nesne adlarının aşırı uzun olmaya zorlandığı zamanlar vardır, bu nedenle fazladan "pref_" tamamen geçersiz olur.ve eğer birinin hala grafikte grafik nesneleri olan bir programı varsa, türünüz "l" önekidir < burada tam olarak "l" önekiyle bir silme vardır (nesneler oluştururken, " l abel" ve " l adları ine" kullanıldı >
Üçüncü taraf bir programda "l" ile başlayan tüm nesneleri öldürür. Bu gerçekten iyi bir çözüm değil.