Programcı olmayanlar için yazım kodu kılavuzu


13

Arka fon

Kod içeren bilimsel bir makale yazdım ve son zamanlarda kanıtları aldım, yani derginin yazımlarının yazımdan ne oluşturduğunu. Sonuç kabul edilemezdi: Girinti tutarsız; her kod bloğunun sonunda bir tam durak vardır; tırnak işaretleri yok edildi, vb. Tüm hataların kullandığım programlama diline özgü olmadığını unutmayın.

Şimdi, hiçbir programlama deneyimi ve harici kaynağı olmayan birisinin neden böyle hatalar yaptığını görebiliyorum, ancak internet zamanlarında hiç kimse harici kaynaklara sahip olmamalıdır. Böylece, önerdiğim bir şey aramak için favori arama motoruma danıştım ve hiçbir şey bulamadım. Programcılar için LaTeX veya benzeri kodları güzel bir şekilde nasıl ayarlayacağına dair çok sayıda kılavuz var , bu da güzel ve uygun, ancak bu açıkça başka birinin kodunu yazmak zorunda olan dizgi yazarı için yapılmadı.

Soru

Ben bir kaynak arıyorum:

  • Dizgi kodunun temellerini açıklar,
  • programlama deneyimi olmayan dizgileri hedefler.

Bununla ilgili zorluk, kullanılan dile ve konvansiyonlara bağlı olmasıdır, bu yüzden cevaplar bir kaynağı
Zach Saucier

2
@Scott Tırnaklar, boşluklar, karakterler ile ilgili olarak - gerçekten de oldukça iyi bir genelleme yapılabilir: korunmaları gerekir.
Mikhail V

1
@MikhailV Birçok kod dilinin yabancı dillerle ortak yönlerden çok ortak yönleri olduğunu hissediyorum. Tabii ki boşlukların ve satır beslemelerinin nereye yerleştirilmesi gerektiğini kabaca belirleyebilirsiniz, ancak doğru olmak için, yazım okuduğunuz dili gerçekten anlamanız gerekir. Evet, editörlere / düzeltmenlere "olduğu gibi" gitmelerini söyleyebilirsiniz, bu da sonuçta doğru olacağı anlamına gelmez.
Scott

1
@Wrzlprmft Komik bir şey, bir acrobat veya acrobat okuyucuda önceki tüm boşlukları kaybetmeden python form PDF'yi yapıştıramaz. "Akıllıca" onları kaldırır. Benzer şekilde, word veya INdesign gibi birçok WYSIWYG düzenleyicisine kod yapıştırırsanız, tırnak işaretlerini tipograf tırnaklarıyla değiştirir (böyle bir özelliği devre dışı bırakmazsanız), ancak gerçekten KÖTÜ olan kod için. Ayrıca idesign'da, satır kesmesi için farklı bir karakter girmeden kodu gerçekten düzgün bir şekilde ayarlayamazsınız, bu da kodu geri kopyalarsanız kötü bir şey olabilir.
joojaa

1
@ usr2564301: Her şeyden önce, bu soru şimdi bazı arama motorları tarafından bulunmakta ve bu yüzden benimkiyle aynı sorunlara sahip herhangi bir dizgecinin potansiyel bir cevap bulabilmesi daha olasıdır (ve eğer yapmazlarsa, doğru bir şekilde hakkında). İkincisi, evet, kanıtlarıma verilen yanıta bir bağlantı ekleyeceğim, çünkü kanıtların ikinci turunda henüz işlenmemiş hataları önleyebilir. Dizgi makinesi inatçı ise referans almak da zarar vermez. Son olarak, bu nadiren kodla uğraşmak zorunda olan bir dergi / yayıncıdır, bu yüzden tasvir ettiğiniz senaryolardan biraz farklıdır.
Wrzlprmft

Yanıtlar:


7

Belki de asıl mesele, kodun insanların dizgileri anlama biçiminde gerçekten dizilmiş olmaması gerektiğidir. Bu nedenle, bir belgeye kod koyarken , tüm boşluklarda, sekmelerde, özel veya özel olmayan karakterlerde ve satır sonlarında olduğu gibi kelimesi kelimesine yazılmalıdır .

  • Sekmeler 4 veya 8 boşluk kadar geniş olmalıdır (dördü en yaygın olanıdır)
  • Yazı tipi sabit genişlikte yazı tipi olmalıdır. Ve neredeyse evrensel vardır olmak.
  • Başvurunuzun herhangi bir değişiklik yapmadığından emin olun!

    Bu, bitişik harf olmadığı anlamına gelir.

    Ayrıca birçok program (Word ve InDesign gibi) uygulaması tipograf çiftleri için düz tırnakları değiştirir. Kodu belgenize koymadan önce bu tür seçeneklerin devre dışı olduğundan emin olun.

  • Kodun bir satırdan diğerine otomatik olarak akmasına izin vermeyin. Koda dokunmayın, uzman değilsiniz!

Kod gövde metni değildir, herhangi bir tipografik kurallara uymaz. Kendinize bir çizimde metin yazar mısınız?

Uzmansanız

Bir uzmansanız ve söz konusu dili biliyorsanız o zaman aşağıdakiler geçerlidir.

Not : Tahmin etmeyin veya çıkarmayın, söylenenleri okuyun. Birçok dil aynı görünür ve kod gerçek koda benzeyen sahte bir dil olabilir. O zaman yapabilirsin:

  • Editör yalnızca anahtar kelimeleriniz aynı sabit genişliğe sahipse anahtar kelimeleri renklendirme / kalınlaştırma / italize etme gibi yapın. En iyi editör bunu sizin için yapsın (scintilla gibi editörler biçimlendirilmiş kodu dışa aktarabilir). Editörün dili, belki de kütüphaneleri bilmesi gerektiğini unutmayın.

    Bunu yanlış yaparsanız, faydadan daha fazla zarara neden olduğunu unutmayın.

Bir alan adı uzmanıysanız. Bildiğiniz gibi dili ve kütüphaneyi bilin ve söz konusu kodu anlayın:

  • Ardından, düzeninize uymuyorsa kodu birkaç satıra yeniden hizalayabilirsiniz. Ne yaptığınızı gerçekten bilmediğiniz sürece bunu yapmayın, sonuçta onarılamaz zararlar verebilirsiniz.

    Turnusol testi, söz konusu kodu yazmış olabilirsiniz. Eğer değilse, yargılayamazsınız. Yazara sorun.

    Bununla nasıl başa çıkılır? Programcılar kod stili standartlarını anlar. Gönderme kılavuzuna, her satıra yalnızca X karakter sığabileceğinizi yazmanız yeterlidir. Programcılar bunu kendileri yapabilir. Kod düzenleyicilerinde bunun için sık sık araçlar bulunur. Tek aralıklı yazı tipi kullanmanın bir başka nedeni.

Ama sonra bunların hepsini biliyordunuz, sonuçta bir uzmansınız. Yazarın kodu düzenlemesine izin ver.

Satır numaraları?

Bazı programlama dilleri ve kullanım örnekleri satır numaralarından yararlanabilir. Yine de burada dikkatli olun, çünkü bu bazı dillerde sahte bir pastır .

Sorunlar.

Ne yaparsanız yapın, aslında imkansız teknik engellerin karşısında olabilirsiniz. Kod gerçekten biçimlendirilmemeli, sadece biçimlendirilmemiş metin olmalıdır. Bu şaşırtıcı sorunlara yol açar.

Örneğin: Python gibi diller, Adobe Acrobat gibi birçok PDF görüntüleyicisi tarafından işlenemez. Kodu PDF dosyasından yapıştırırsanız editör, kopya yapıştırma sırasında önceki alanı eklememeye karar verir. Bu, kodu PDF'den düzenleyiciye yapıştırma yeteneğini yok eder. Bununla başa çıkmak için gerçekten iyi bir yol yok!


ah yes so true
joojaa

1
@ usr2564301 Her neyse, okunabilir bir yazı tipi seçiminin bir tipografın anlaması gereken bir şey olduğunu düşünüyorum. Her neyse, küçük harf i noktasını da ayıran biri (evet, bir ay boyunca bir parça fo kodunda hata ayıkladık çünkü küçük bir 'i' harfinin farklı olduğunu bir Türk yerelinde büyük bir 'I' formundan farklı olduğunu bilmiyorduk) bir 1 too
joojaa

“Kodun bir satırdan diğerine akmasına izin vermeyin” teoride iyi bir tavsiye. Ancak standart 6x9 baskı biçiminde diziliyorsanız ve 600 karakterden oluşan bir kod satırınız varsa, buna dikkat etmeniz zor olacaktır.
Janus Bahs Jacquet

1
@JanusBahsJacquet Kodu genellikle satır başına 80 karakterden az olarak yazılır. Eğer böyle bir şey alırsanız, o zaman belki gönderme yönergeleri emmek. Programcılar teslim kurallarını bilir, sonuçta bu kod tabanlarıdır. Şey, satırları kırarak kodun anlamını değiştirebilir.
joojaa

1
@JanusBahsJacquet Bu yüzden yazara sorduğunuzda, yönergeleri güncellersiniz, böylece bunu çok sık yapmanız gerekmez. her iki durumda da kod uzun satırlar halinde bölünemez eğer o zaman dizici ya da bu konuda bir şey yapamam. Bu arada, bir dizgici yeniden boyutlandırılamayan veya kırpılamayan çok geniş bir resme ne yapardı? Her neyse, kod gönderimlerinin gelecekte daha yaygın olacağını tahmin edeceğim
joojaa

4

Cevabı elbette birçok faktöre bağlı olabilir, ancak doğru, iyi biçimlendirilmiş düz metin koduyla başlarsak , burada az çok genel şeyler olabilir.

Kaynak metindeki ilk 'biçimlendirme': satırsonu , boşluk ve sekme karakterleri olacaktır. Yeni hat ve (DTP yazılımında olduğu gibi) manuel satır sonu aynı şey değildir ve bunun tersi, bazı nadir diller geldiğini hatırlatırız olabilir böyle duymadım rağmen, diğer biçimlendirme karakterlerini tanır.

Yorumlar kodun yürütülebilir bir parçası değildir, bu yüzden gerçekten bir yorum olup olmadığını biliyorsanız, bunlar çok fazla risk olmadan yeniden biçimlendirilebilir. Bu yüzden bakmanız gereken ilk şey yorumların nasıl etiketlendiğidir.

İlk düz metin biçimlendirmesiyle ilgili bazı temel bilgileri bilmek iyidir. Örneğin, Python için PEP8 stil rehberi vardır . Python için yapılmış olsa da, bu biçimlendirme kılavuzu C / C ++ ve Java gibi büyük diller için referans olarak kullanılabilir. Şüphe duyduğunuzda çeşitli örnek projelere bakmak yardımcı olabilir.

Böylece, ilk ilke şöyle olacaktır: Kaynak metni değiştirmeyin. Bir kontrol listesi üzerinden gitmek istiyorum - emin olun:

  • Hiçbir sahnede karakter otomatik kaydetme gerçekleşmez.
  • Metinde hiçbir düzenleme yapılmaz (yapılması gerektiğinden% 100 emin değilseniz).
  • Satır kaydırma görünmüyor.
  • Girintiler görsel olarak korunur ve tutarlıdır (  girinti seviyesi başına yaklaşık dört x genişlik).
  • Başlangıç ​​(sıfır) girinti seviyesi görünür olmalıdır.
  • Tanımlı stiller sözdiziminin biçimlendirmesini yok etmez (sözdizimi vurgulama kullanılıyorsa).
  • Orijinal biçimlendirmeyi yeniden kontrol edebilmek veya yeniden başlatabilmek için kaynağın düz metin olarak yedeğini alın.
  • Varsa, satır numaraları özellikle açıklamalarda referans gösteriliyorsa bozulmamış olmalıdır.

Aslında orijinal kaynak düzgün biçimlendirilmişse, hiçbir satır kaydırması olmamalıdır. Sarılmış çizgiler hala görünüyorsa ve kaçınılmazsa, tek düzey asılı girinti en yaygın çözümdür (yukarıdaki bağlantılı PEP'e bakın). Satır kesilmesi gerekiyorsa - stil kılavuzuna veya yazara başvurun.

Yine de bazı küçük 'beyaz boşluk' karakterlerinin değiştirilmesi gerekebilir. Kaynak sekme karakterleri içerebileceğinden, bu elbette dizelleştiricinin her satırın başındaki tüm sekmelerin tutarlı olmasını sağlamalıdır, yani iç içe girintiler görsel olarak korunur ve her girintinin her bir seviyesi aynı genişlikte olmalıdır (yaklaşık dört x  bir girinti seviyesi başına genişlik).

İdeal olarak, boşluk karakterleri veya karışık boşluklar ve sekmelerle yapılan girintiler tablo ile (veya DTP yazılımının iç içe girintiler için daha iyi yapabileceği şeyle) değiştirilmelidir, bu nedenle gerekirse girintileri ayarlamak daha kolay olabilir.
Tabii ki boşluk bırakılabilir, ancak yazı tipini değiştirirken genişliklerini yönetmek daha zor olabilir ve tablo sütunlarında olduğu gibi iç çizgi girintilerini hizalamak daha zor olabilir.

Eş aralıklı yazı tipi + boşluklar

Kaynak kasıtlı olarak boşluklarla biçimlendirilmişse ve yalnızca tek aralıklı yazı tipinde okunması amaçlanmışsa (örneğin ASCII diyagramları veya ASCII-art) boşlukların tamamen değişmeden korunması gerektiğini , ancak bu kararın en baştan yapılması gerektiğini unutmayın. "Courier New" yazı tipi bu durumda en yaygın olanıdır. Yine de gerçekten ihtiyaç duyulmuyorsa, tek aralıklılara karşı öneriyorum, çünkü daha az yeni insan bugün kodlama için tek aralıklı seçiyor ve düzeltme okuma durumunda, orantılı yazı tipleri daha iyi okuma deneyimi sağlayacak.

Genel olarak, kısaltılmış (örn. Arial dar) veya daha küçük yazı tipleri daha iyi çalışabilir: gövde metninin aksine daha fazla vurgu yapar, kodu daha kompakt hale getirir ve böylece istenmeyen satır sarmanın ortaya çıkması daha az olasıdır.

Bence bir çizgi çizebilir ve yukarıdakiler yapılırsa, en azından renksiz düz bir tek yazı tipi kod bloğu için her şeyin iyi olması olasılığı% 99 olabilir.


Araçlar ve gelişmiş biçimlendirme

Ayrıca, sözdizimi vurgulaması kullanılarak görünüm önemli ölçüde geliştirilebilir.

  • renkli baskı veya ekran görüntüleme: tam renkli bir düzende vurgulamanın her özelliği kullanılabilir, bu nedenle en iyi senaryodur, ancak yazdırma bazı renk değişikliklerine neden olabilir.

  • gri tonlamalı veya s / b baskı: burada elbette kalın (örn. anahtar kelimeler) veya italik (örn. yorumlar) kullanılabilir, ancak renklerin tüm sonuçlarla griye dönüştürüleceğini unutmayın. Örneğin gri renkli yorumlar ekranda harika görünebilir, ancak kağıt üzerinde çok soluk olabilir.

En önemli soru, düzenleyicinin kodu okunabilir bir biçimde temsil edebilecek araçlara sahip olup olmadığıdır. Neyse ki, kod düzenleme için bir çok ücretsiz araç var, en göze çarpan (Windows için): Notepad ++, VSCode, Visual Studio . Ancak sekmelerin boşluklara örtülü olarak otomatik dönüştürülmesinin farkında olun.

Notepad ++ uygulamasında , kodu tüm biçimlendirme ve sözdizimi vurgulamasını koruyacak şekilde RTF olarak dışa aktarma seçeneği vardır .

Düzen, kod sunumundaki metin akışının değiştirilmesini gerektirmiyorsa, görüntüler doğrudan kullanılabilir (ekran görüntüleri) - metin kadar esnek değildir, ancak% 100 biçimlendirme ve satır numaralandırmasını koruyacaktır ve çok zaman kazandırabilir. Örneğin, satır numaralarının metin biçiminde korunması zor olabilir. Ayrıca PDF'ye dışa aktarma iyi bir alternatiftir - ancak tüm DTP yazılımları PDF'leri gömemez ve PDF'ye yazdırırken bazı biçimlendirme kaybolabilir.

Örneğin, Notepad ++ içindeki Python kodu için kurulumum şöyle:
resim açıklamasını buraya girin

Bu sadece bir kişinin ekran görüntülerini doğrudan kullanabileceğini ve aslında en kolay yöntem olabileceğini göstermek içindir. Ekran yakalamaya yardımcı olabilecek çeşitli araçlar vardır - daha yüksek çözünürlüklü görüntüler için ekranların 'dikilmesi' gerekebilir.

Renk şeması, elbette, desteklenen dilin zaten farkında olan editörün stil konfigürasyonunda tanımlanan bireyseldir, böylece sözdizimini bilmese bile yanlış biçimlendirme yapmayı zorlaştırır. Burada genel tipografi kuralları çalışmalıdır: çok fazla renk, tutarlı yazı tipleri, girintiler, rahat satır aralığı.

Özel dil tanımları için ek araçlar / eklentiler de yaygındır, ancak sözdizimi bilgisi gerektirir.


Bu harika ve dikkatle düşünülmüş bir yanıttır. Ancak, çözünürlük nedeniyle bunu yazdırmayı planlıyorsanız ekran görüntüleri en iyi düzeyde olabilir. Akılda tutulması gereken bir şey.
Jeremy Carlson

1
@JeremyCarlson, Np ++ 'da yazı tipi boyutu / satır aralığı da ayarlanabilir - bu nedenle teoride ekran görüntüsü çözünürlüğü için bir sınır yoktur, ancak özellikle küçük bir ekranda oluşturulması daha zor olacaktır. Sanal ekran kullanmak ve çok büyük pencere boyutu ayarlamak için bazı hileler bile olabilir
Mikhail V

çünkü daha az yeni insan bugün kodlama için tek aralıklı seçiyor - Bu olabilir, ancak tek aralıklı hala büyük çoğunluk tarafından kullanılmaktadır. Normal dizgi kurallarını koda çeviremezsiniz. Örneğin, noktalama işaretleri normal metinlerden daha önemlidir (benim bu cevabımdaki argümanların çoğu buna dönüşür ). Tek aralıklı olmayan bir kod yazı tipi, normal metin için olandan oldukça farklı olacaktır. Ayrıca, genellikle bazı benzer yapıların yatay olarak hizalanmasını a[i][j] = 1istersiniz , örneğin ⮠ a[m][n] = 2.
Wrzlprmft

@ Wrzlprmft düzenlemeler için teşekkürler. Ve evet, kod ve matematik için optimize edilmiş çok fazla iyi yazı tipi yok (Verdana tamam). Gerçekten de, Times'ın çok küçük bir dönemi, iki nokta üst üste ve bazı sorunları var, ama bunu sonuna kadar kullanıyorum - 'faydalar maliyetlerden daha ağır basar'
Mikhail V

-5

HTML'de, okuyucuya / yorumlayıcıya içeriği tam anlamıyla ele almasını söyleyen bir <code> ... </code> etiket kümesi vardır. ayrıca, <pre> ... </pre> aynısını yapar. Sıklıkla formülleri, denklemleri ve yayın kodunu yazmak zorunda olan biri olarak, bunun için IMAGES'ın kullanımını da savunuyorum. Sorunlu öğenin bir .gif veya .jpg veya .png dosyasını yapıyorum.

Diğer bir faktör, kodun geleneksel olarak Courier monospace veya diğer tek aralıklı yazı tipinde oluşturulmasıdır, çünkü okuyucuya gövde metni olmadığı için semaforlar veya telgraflar. Bu stil seçimine abone oluyorum, bence çok mantıklı.

Çoğu "eski" dizgi sisteminde, oldukça yüksek karmaşıklığa sahip matematik denklemleri dayanılmaz derecede zaman alıcıydı ve hatayla doluydu.


Tabii ki, görüntüler kesilemez!
dwoz

3
Bunun sorulan soruya nasıl cevap verdiğini anlamıyorum
Zach Saucier
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.