Bu rehberin yayınlanma zamanını, OpenSCAD'in en son sürümünü kutlamak ve onunla eş zamanlı olacak şekilde ayarladım! En son sürüm (2011.12) bugün yayınlandı, bu yüzden gidin ve şimdi alın! Bu şeyi devam eden bir çalışma olarak işaretledim çünkü güncellenmesi gerekecek, ancak bu şey

OpenSCAD projelerinin her gün daha karmaşık hale gelmesiyle birlikte, onu kullananların tutarlı bir tarz düşünmeye başlamasının son derece önemli olduğunu düşünüyorum. Kodun düzeni, teknik doğruluk ve verimlilik kadar önemlidir çünkü iyi bir düzen, okunaklı, yeniden kullanılabilir ve b

OpenSCAD kodunda stil için aşağıdaki yönergeleri teklif etmek istiyorum. Eğer aynı fikirde değilseniz, lütfen konu hakkında konuşun veya bir türev oluşturun. Bunun konu hakkındaki son söz olmasını beklemiyorum. Amacım, daha kolay bakım yapılabilen OpenSCAD koduna yol açacak bir di

Lütfen bu talimatları mümkün olduğunca yakından takip edin, ancak unutmayın: "Aptalca bir tutarlılık, küçük zihinlerin iblisidir" [2][3]. Başka bir deyişle, bu kurallardan herhangi biri kodunuzun çalışmamasına neden olursaDaha az.Okunaklı/bakım kolayıysanız o özel durumda kurala uymamalısınız. Amaç her zaman okunabilirlik ve bakım kolaylığıdır. En azından, bir tarz seçin ve ona sadık kalın.

Beyaz boşluk.

Okunaklı kod için muhtemel en önemli faktör, doğru yerlerde doğru miktarda boşluk bırakmaktır. OpenSCAD'da, diğer birçok programlama dili gibi, beyaz alan (boş satırlar, boşluklar ve sekmeler) görmezden gelinir, bu da kodu okunaklı ve bakımı kolay bir şekilde düzenleme özg

Tabiat

Neredeyse tüm dillerde öneri (Python'da kural değilse), herhangi bir kod bloğuna (koşul, döngü, modül) başladığınızda, kodunuzun mevcut girinti seviyesinden bir seviye daha içeriye girinti yapması gerektiğidir. Örnek:

for(z = [-5, 5]) { // Açılış parantezini aynı satıra yerleştirin.
    translate([0, 0, z]) {
        if(z < 0) {
            cube(size = 0.5, center = false);
        }
        Diğer türde, eğer (z > 0) ise {
           cube(size=0.25, center = false);
        }
Diğer taktirde {
            cube(size=0.35, center = false);
        }
    } // blok açıcıyla aynı hizada.
} // Uzun kod blokları için burada bir hatırlatma yorumu kullanın (örneğin // for(z))

Kıvırcık parantezlerin yerleşimi, Kompakt Kontrol Okunabilirliği Stili'ne uygun olmalıdır. Bu, kodun oldukça kompakt olmasını sağlarken, if/else gibi hizalanmış kontrol ifadeleri için kodun sol kenarını taratmayı kolaylaştırır. Bloklar, hataları önlemek için tüm durumlarda (tek satırlık bl

OpenSCAD'de girinti her zaman ile yapılmalıdır.Sekmeler.Boşluklar değil, OpenSCAD editörünün girinti kısayolunun sekme kullandığı için. Bununla birlikte, bu örneklerde olduğu gibi sabitleri ve işlemcileri hizalamak için boşluk kullanmak uygun (ve teşvik edilir)dir:

vektor_of_vectors = [[0, 0, 0],
                             [1, 0, 1],
                         [0, 1, 0]];

Poligon(
    puanlar = [[0, 0],
                 [1, 0], // Bir sekme, düzenleme için boşluklarla takip edilir.
                 [1, 1], // Aynı şey.
                 [0, 1],
    paths  = [[0, 1, 2, 3]] // = operatörünü hizalayın.
);

Burada dikkat edilmesi gereken bir şey, hizalama için boşlukların sadece mono yazı tipiyle çalışacağıdır. Bu nedenle OpenSCAD'in tercihlerinde bir mono yazı tipi seçilmesi önerilir.

Kod bloklarını girintileme konusunda OpenSCAD için özgün bir kural oluşturulmalıdır. Dönüşümler ve atamalar genellikle gruplar halinde gelir (örneğin, assign(...) scale(...) rotate(...) translate(...) {...}), bu nedenle grubun her üyesi için girinti eklemeye gerek kalmaz. Bu durumda tüm grubu blok açıcı olarak düşünm

Assign(x = 5)
scale([1, 1, 0.5])
Döndür ([180, 0, 0])
[5, 5, 0]'ı tercüme edin.
eğer (y == 0) {
    cube([1, 2, 3]);
}

Bu, atama, ölçekleme, döndürme, çeviri, fark, birleştirme ve renk ile yapılmalıdır, ancak diğer blok ifadeleri yalnızca grubun son öğesi ise kullanılmalıdır. Grupun ilk öğeleri, eğer varsa, her zaman "atama" ifadeleri olmalıdır.

Boşluklar.

Boşluklar, koddaki öğeler arasında biraz ayrım sağlamak için güzeldir, ancak aşırıya kaçmamak önemlidir. Virgül sonrasındaki boşluklar (,), liste öğelerini okumayı kolaylaştırır, köşeli parantezlerin (:) etrafındaki boşluklar aralıkları okumayı kolaylaştırır ve işleçlerin

Yorumlar.

Tüm dosyalar bir yorum bloğuyla başlamalıdır (/...Şeyi tanımlayan bir /), ardından şeyin daha resmi bir tanımını sağlayan bir Thingdoc[5] bloğu. Bir /...Her modülden önce giriş parametrelerini açıklayan bir yorum bloku da yararlıdır. Bir örnek:

/*
 Harika bir nesne çizer!
Â
 @param int width Harika nesnenin genişliği, varsayılan olarak 5'tir.
 */
modül awesome_object(genişlik = 5) {
    .
    .
    .
}

Eğer kodu yorumlamak cazip geliyorsa, tüm kodu yorumsuz bırakarak koşullu ifadeler veya modüller kullanarak denediğiniz şeyi başarıp başaramayacağınızı görün. Örneğin, bunu:

Bir örnek kullanım için aşağıdaki satırı yorumdan çıkarın!
//my_awesome_thing(10, 5);

Bu şekilde değiştirilebilir:

modül my_awesome_thing_demo(param1, param2) {
    my_awesome_thing(param1, param2);
}

Karmaşık kod blokları için, belirli bir satırın amacını açıklamak için yorumlar eklemek faydalı olabilir. Bu yorumlar kısa ise, // yorum açıcısını takip eden satırın sonuna yerleştirilebilir, aksi takdirde referanslanan kodun üzerinde bir veya daha fazla yeni satıra yerleştirilmelidir (yorum

Satır Uzunluğu.

Satır uzunluğu için kesin bir kural sağlamak zor, çünkü (bu yazı itibariyle) OpenSCAD satır/sütun bilgilerini göstermiyor. Bununla birlikte, genel kurallar belirlenebilir. Her zaman sarılmış satırlardan kaçınmaya çalışmalısınız, çünkü bunlar kodun çok daha az okunaklı olmasına neden olur. Tab

1. Kodu modüler hale getirin. Durumunuzda mantıklıysa, kodu sorunlu satırdan bir modüle veya işlevine taşıyabilirsiniz, böylece satırı kısaltabilirsiniz.
2. Satırı bölün. Satırı, hepsinin tek bir satıra sığabileceği kadar çok satıra bölün. Bölün.Sonra.Noktalar ve işlemciler ve önceki satırla hizalamak için sekmeler ve boşlukların bir kombinasyonunu kullanın.

İsimlendirme Sözleşmesi

OpenSCAD'de değişken isimlendirme, aşağıdakine uygun olmalıdır.alt_çizgi_adlandırmaOpenSCAD'in yerleşik modülleri için kullanılan isimlendirme şemasına uyarlanan bir sözleşme. Başka bir deyişle, değişkenlerin tümü küçük harflerle ve kelimeleri ayırmak için alt çizgilerle olmalıdır. Değişken isimlerini kısa, benzersiz ve anlamlı tutmaya çalışın.

Genel Yönergeler.

Modülerleştirme.

Genellikle bir modül bir sayfadan daha uzun olmamalıdır. Bu kadar uzun bir modülünüz varsa, modülün uzunluğunu azaltmak için bazı kodları ayrı modüllere bölüp bölmeyeceğinizi görün. Bu kodun bir kısmının yeniden kullanılabilir olduğunu fark etmek sizi şaşırtabilir. Kod s

[1]http://www.openscad.org/
[2]http://www.python.org/dev/peps/pep-0008/
[3]http://www.bartleby.com/100/420.47.html
[4]http://en.wikipedia.org/wiki/Indent_style#Compact_Control_Readability_style
[5]https://github.com/prusajr/ThingDoc/wiki/Syntax