Günlük ücret: programcılar arasında usta bir yazar olmayı öğretmek
Tam metin 2930 Kelimeler, tahmini öğrenme süresi 10 dakika
Kaynak: Pexels Photography: StartupStock Phot
"Daha İyi Programlama" nın yayınlanmasından bu yana, içinde metin düzenleme çalışmaları yapıyorum. Deneyimlerime göre, programcılar oldukça iyi yazarlar.
Elbette iş nedeniyle birçok makalenin editörlüğünü yaptım. Orijinal metni çeşitli şekillerde geliştiremezsek, çalışma duygusu kalmayacağını hissediyorum. Bununla birlikte, programcının makalesinde birçok dilbilgisi hatası olsa bile, makalenin çerçevesi ve düzeni hala çok parlak. Açıkçası, bilgisayar dili bilgisi, İngilizce yazma için daha mantıklı ve sistematik bir yöntem sağlar.
Bunu söyledikten sonra, programcılar genellikle bazı yazı noktalarında sorunlarla karşılaşırlar.
Programcılar ve okuyucular arasındaki ilişki nedir?
Okuyuculara göre, farklı yazı türleri, yazarların farklı kimlik konumlandırmasına sahip olmasını gerektirir. Örneğin: bir vaka çalışmasında, bir öğretim görevlisidir; bir eğitim yazarken bir rehberdir; bir inceleme makalesinde, okuyucunun bir arkadaşıdır; ve bir rapor yazarken bir muhabirdir.
Aşağıdaki dört cümleyi örnek olarak kullanın:
· "Ardından, çok düğümlü Kubernetes kümelerine bir göz atacağız. (Şimdi, Kubernetes çok düğümlü kümelerine bakalım.)"
· "Ardından, çok düğümlü Kubernetes kümelerine bakacaksınız. (Daha sonra, Kubernetes çok düğümlü kümeleri göreceksiniz.)"
· "Şimdi, çok düğümlü Kubernetes kümelerine bir göz atacağım. (Şimdi, Kubernetes çok düğümlü kümelerine bir göz atacağım.)"
· "Şimdi, çok düğümlü Kubernetes kümelerine bir göz atın. (Şimdi, çok düğümlü Kubernetes kümelerine bir göz atın.)"
Bu cümlelerin gramer sorunu yoktur, ancak her cümle okuyucular için farklı okuma beklentileri ortaya koymaktadır.
"(Daha sonra, çok düğümlü Kubernetes kümelerine bir göz atacağız.) Sonra, Kubernetes çok düğümlü kümelere bakalım."
"Biz" birinci kişide çoğuldur, bu sırada yazar okuyucunun okuma rehberi ve tüm makalenin rehberi olur. Bu ton, eğitimlerde ve kılavuzlarda çok yaygındır.
Bazı yazarların makalelerinde okuyuculara rehberlik etmek için "biz" i kullandıklarını ve daha sonra her ismin iyelik zamiri "bizim" ile değiştirildiğini fark ettim. Örneğin, "Sonra kontrol panelimizi açıyoruz ... sonra gönder butonumuza tıklıyoruz ... şimdi projemizin sonuna geldik. (Sonra, kontrol panelimizi açın ... ve gönder butonumuzu tıklayın .. Şimdi projemizin sonuna geldik.) "Belki de programlamada, her isimden bahsedildiğinde, tüm ilişkileri belirtilmelidir, ancak İngilizce yazıda durum böyle değildir! Bir metin paragrafında "biz" veya "bize izin ver" kullanılsa bile, aşağıdaki isimler, ismi değiştirmek için her zaman varsayılan kesin madde olan "the" yi kullanabilir.
"Ardından, çok düğümlü Kubernetes kümelerine bakacaksınız. (Daha sonra, Kubernetes çok düğümlü kümeleri göreceksiniz.)"
Burada ikinci tekil tekil kişinin gelecek zamanı kullanılır. Bu cümlede, yazar artık okumanın bir katılımcısı değildir (çünkü ilk kişi "biz" yazar ve okuyucuyu içerir ve "siz" yalnızca okuyucuyu içerir), bu da makaleyi okumayı daha az samimi hale getirir, ancak okuyucunun bilmesini sağlar Sadece bilmek istediği gerçeklerdi.
"Şimdi, çok düğümlü Kubernetes kümelerine bir göz atacağım. (Şimdi, çok düğümlü Kubernetes kümelerine bir göz atacağım.)"
Birinci tekil tekil gelecek zaman burada kullanılır. Bu, okuyucuyu makalenin okuma yapısından çıkarır ve yalnızca yazarı katılımcı olarak bırakır. Bu, makaleyi yazarın kendi hikayesi yapar ve okuyucu sadece pasif bir alıcıdır. Bu ton, eğitimler veya kılavuzlar yazmak için uygun değildir, çünkü bu durumda okuyucuların dahil olması gerekir. Ancak bu ton, teknik raporlar veya konferans raporları yazmak için çok uygundur.
"Şimdi, bu çok düğümlü Kubernetes kümelerine bir göz atın. (Şimdi, bu çok düğümlü Kubernetes kümelerine bir göz atın.)"
Bu cümle zorunludur. Okuyucuya ne yapması gerektiğini doğrudan söyler, böylece okuyucunun bilgileri aktif olarak kabul etmesi sağlanır. Bir öğretici yazarken, okuyucuya ne yapacağını ve nasıl yapacağını söylemeniz gerekir, bu yüzden en iyisi zorunludur. Elbette, okuyucuların makaledeki diyagramları veya belirli kodları kontrol etmesini beklediğinizde de zorunlulukları kullanabilirsiniz.
Tavsiyem: tutarlı olun. Yazmaya başlamadan önce kimliğinize karar vermelisiniz - okuyucular için rehber, öğretim görevlisi, ilginç arkadaş, hikaye anlatıcısı veya operasyonel rehber misiniz? Yazarken, kendi kimlik konumunuzu kesinlikle takip etmelisiniz.
Gereksiz sözdizimi
Bu başlık tipik bir gramer fazlalığıdır. neden? Tanım olarak, gramer fazlalığı zaten gereksiz anlam içeriyor. Buradan anlaşılacağı gibi "gramer fazlalığı" nın anlamı, aynı anlamı ifade etmek için fazlalık sözcükler kullanmaktır.
Bunu dil fazlalığı olarak da anlayabilirsiniz (ancak bu uygun değildir çünkü çok abartılıdır).
Aslında, sözlü ve yazılı İngilizce'de fazlalık çok yaygındır. Programlamada da fazlalık var. Wikipedia gereksiz kodu tanımlar:
Bilgisayar programlama, fazlalık kod, kaynak koddur veya bir bilgisayar programındaki derlenmiş koddur, örneğin:
önceden hesaplanmış ve hala mevcut olan bir değeri yeniden hesaplamak,
asla çalıştırılmayan kod (ulaşılamayan kod olarak bilinir),
kod çalıştırılır ancak dış etkisi yoktur (örneğin, bir program tarafından üretilen çıktıyı değiştirmez; ölü kod olarak bilinir).
("Bilgisayar programlama için yedek kod, gereksiz kaynak koddur veya bilgisayar programları için derlenmiş koddur, örneğin:
Tekrarlanan hesaplamalar için mevcut değer,
Asla çalıştırılmayacak kod (erişilemez kod),
Çalıştırılabilen ancak dış ortamı etkileyemeyen kod (örneğin, programın çıkardığı kod değiştirilemez; buna geçersiz kod da denir). ")
İngilizce insan kodu olarak kabul edilirse (bu bir gerçektir), çıktı dil alıcısının anlayışıdır. Fazlalık, makalenin kelime sayısını artırır, ancak okuyucuların makaleyi anlamasını geliştiremez.
Tıpkı bir bilgisayar dilinde olduğu gibi, belirli bir kod satırı silindikten sonra aynı çıktı korunabiliyorsa, o kod satırı gereksizdir ve silinmelidir.
Bazı gereksiz örnekler
"Benzer şekilde, etkileşimli görselleştirmeleri de basit açıklamalarla birlikte gelir." "Benzer şekilde" veya "aynı" silebilirsiniz. Bu iki kelime cümle içinde aynı işlevi gördüğünden, her ikisi de yukarıda görünen nesnelerle bir karşılaştırmayı gösterir.
"JavaScript Promises'i ilk kullanmaya başladığımda, bunların sihirli olduğunu düşündüm. (JavaScript Promises'i ilk kullanmaya başladığımda, bunların sihirli olduklarını düşünmüştüm.)" "İlk" ve "başladı" Tekrarlanan: Bir şeyi ilk kez yaptığınızda, bir şeyler yapmaya başlıyorsunuz. Bu cümle "... kullanmaya başladığımda" veya "İlk kullandığımda ..." olarak değiştirilmelidir.
"Çoğu zaman" "sık sık" olarak değiştirilebilir.
"Çok sayıda ..." "çok" olarak değiştirilebilir.
"Sırayla", "olarak" olarak değiştirilebilir.
"Kullan" ve "kullan" her ikisi de "kullan" anlamına gelir. Makalede "yararlan" kullanmak, iki heceyi boşa harcadığından bahsetmeye bile gerek yok! (Aslında bu gereksiz değildir, ancak kişisel olarak baş ağrısına neden olur. Lütfen artık "kullan" kullanmayın.)
Ara sıra fazlalık büyük bir sorun değildir. Birinin "zamanda bir an" yazdığını görürsem (tüm "anlar" "zamandadır" !!!) Deli olmayacağım.
Bununla birlikte, çok fazla fazlalık, yazmayı uzun ve sıkıcı hale getirebilir ve hatta makaleyi daha kafa karıştırıcı hale getirebilir.
İyi kod gibi, iyi makalelerin de etkili bir şekilde düzenlenmesi gerekir.
Kod biçimi
Ben bir editörüm, programcı değilim, bu yüzden kodu biçimlendirmeye pek yardımcı olamıyorum. Kodun makaleye nasıl entegre edileceği biçimlendirme ve ifade ile ilgilidir, bu benim işim. Bunun için bazı önerilerim var.
"Daha İyi Programlama", özellikle yazara kodu bir cümleye nasıl entegre edeceğini açıklayan basit bir öğreticiye sahiptir: kodu iki aksan işareti arasında sandviçleyin "" "(bu tuş çoğu klavyede Esc tuşunun altındadır), kodunuz şöyle olacaktır Görüntüle.
Bunun veya buna benzer başka bir formatta kod yazarsanız, formatı değiştirmenize yardımcı oluruz. Ancak, hangi biçimi kullanırsanız kullanın, lütfen hata oranını düşürmek için en azından tutarlı olun.
Biçim tutarsızsa, işlevler ve işlev adları arasında ayrım yapamayız. Başka bir deyişle, Swift (bir teknoloji), .swift (bir son ek) ve swift (bir kuş veya "hızlı" için bir sıfat) arasında ayrım yapamayız.
Uzun kod bloğu
Genellikle uzun kod blokları (ikiden fazla satır) Gist'e yerleştirilmelidir. Ancak, Gist şu anda Medium'da doğru şekilde oluşturulamıyor. Bu nedenle, lütfen uzun kod blokları için bile bu stili kullanın: paragrafın başına üç aksan işareti yazın, böylece tüm paragraf biçimlendirilebilir.
Uzun kod parçacıklarını bir cümlenin parçası olarak ele almayın. Böyle yazmayın:
Şimdi dosyayı açın ve ekleyin
* Çok satırlı JavaScript kodu *
Sonunda ... (önceki cümleden devam ediyor)
Aslında, bir cümleye yalnızca tek bir terim veya kısa kod satırı entegre edilebilir. Uzun kod parçalarını uygun şekilde tanıtabilirsiniz, ancak bunu şu şekilde yazın:
Şimdi, dosyayı açın ve aşağıdaki kodu ekleyin:
* Çok satırlı JavaScript kodu *
(Yeni cümle ...)
postscript
"Daha İyi Programlama" içeriğini aktif olarak benimsiyoruz. Fikirler en önemli şeydir. İçeriğinizin değerli olduğunu - mevcut ihtiyaçları karşıladığını ve orijinal içerik olduğunu düşünürsek - iyi makalelerin daha fazla kişi tarafından görülebilmesi için buna yatırım yapmaktan çok mutlu olacağız.
Yorum Beğen Takip Et
Yapay zeka öğrenme ve geliştirmenin kuru mallarını paylaşalım
Yeniden yazdırıyorsanız, lütfen arka planda bir mesaj bırakın ve yeniden yazdırma şartnamelerine uyun
