# Sadece Kod Gerçeği Söyler Bir programın nihai anlamı, çalışan kod tarafından verilir. Bu yalnızca ikili biçimdeyse, okunması zor olacaktır! Bununla birlikte, kaynak kodu sizin programınız, herhangi bir tipik ticari yazılım geliştirme, bir açık kaynak projesi veya dinamik olarak yorumlanan bir dilde kod ise mevcut olmalıdır. Kaynak koduna bakıldığında, programın anlamı açık olmalıdır. Bir programın ne yaptığını bilmek için, baktığınızdan emin olabileceğiniz tek şey kaynaktır. En doğru gereksinimler belgesi bile tüm gerçeği söylemez: Programın gerçekte ne yaptığının ayrıntılı öyküsünü içermez, yalnızca gereksinim analistinin üst düzey niyetlerini içerir. Bir tasarım belgesi, planlanmış bir tasarımı kapsayabilir, ancak uygulamanın gerekli ayrıntılarından yoksun olacaktır. Bu belgeler mevcut uygulama ile senkronizasyonu kaybedilmiş olabilir... veya basitçe kaybolmuş olabilir. Ya da hiç yazılmamış. Kaynak kodu kalan tek şey olabilir. Bunu akılda tutarak, kodunuz size veya başka bir programcıya ne yaptığını ne kadar net bir şekilde söylediğini kendinize sorun? "Ah, yorumlarım size bilmeniz gereken her şeyi anlatacak" diyebilirsiniz. Ancak yorumların kod çalıştırmadığını unutmayın. Diğer belgeleme biçimleri kadar yanlış olabilirler. Yorumların koşulsuz olarak iyi bir şey olduğunu söyleyen bir gelenek vardır, bu yüzden şüphesiz bazı programcılar daha fazla yorum yazar, hatta kodda zaten açık olan önemsiz şeyleri yeniden ifade edip açıklar. Bu, kodunuzu netleştirmenin yanlış yolu. Kodunuzun yoruma ihtiyacı varsa, olmaması için yeniden düzenlemeyi düşünün. Uzun yorumlar ekran alanını karıştırabilir ve hatta IDE'niz tarafından otomatik olarak gizlenebilir. Bir değişikliği açıklamanız gerekiyorsa, bunu kodda değil sürüm kontrol sistemi giriş mesajında yapın. Kodunuzun gerçeği olabildiğince açık bir şekilde söylemesini sağlamak için ne yapabilirsiniz? İyi isimler için çabalayın. Kodunuzu, adlandırmayı da kolaylaştıran uyumlu işlevselliğe göre yapılandırın. Ortogonallik elde etmek için kodunuzu ayırın. Amaçlanan davranışı açıklayan otomatik testler yazın ve arayüzleri kontrol edin. Daha basit ve daha iyi bir çözümü nasıl kodlayacağınızı öğrendiğinizde acımasızca yeniden düzenleme yapın. Kodunuzu okunması ve anlaşılması için mümkün olduğunca basit hale getirin. Kodunuza şiir, deneme, herkese açık bir blog veya önemli bir e-posta gibi diğer kompozisyonlar gibi davranın. İfade ettiğiniz şeyi dikkatli bir şekilde oluşturun, böylece yapması gerekeni yapsın ve ne yaptığını mümkün olduğunca doğrudan iletsin, böylece artık etrafta olmadığınızda niyetinizi iletmeye devam etsin. Kullanışlı kodun her zamankinden çok daha uzun süre kullanıldığını unutmayın. Bakım programcıları size teşekkür edecek. Ve bir bakım programcısıysanız ve üzerinde çalıştığınız kod doğruyu kolayca söylemiyorsa, yukarıdaki yönergeleri proaktif bir şekilde uygulayın. Kodda biraz akıl sağlığı oluşturun ve kendi akıl sağlığınızı koruyun. [Peter Sommerlad](http://programmer.97things.oreilly.com/wiki/index.php/Peter_Sommerlad) Tarafından --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/tr/thing_62.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.