Son zamanlarda, birkaç proje ve geliştirme ortamı arasında geçiş yapıyorum. Her birinde kodlama stili beklentileri farklıdır.
Şimdi sorum üç kısım, birincisi, sadece meraktan:
Yanıtlar:
№1. # Kodlama stilinizi nasıl tanımladınız ve buldunuz?
Önce kitaplarda, sonra MSDN metinlerinde ve makalelerinde, ardından bloglarda ve diğer web sitelerinde kod örnekleri aracılığıyla.
№2. Nasıl büyütmeye ve geliştirmeye devam ediyorsunuz?
İnsanların yaptığı tüm önerilere gözümü açık tutuyorum. Onları deniyorum, eğer benim için çalışırlarsa, yapışırlar. Ben de zaman zaman denemeler yapıyorum, bazı şeyleri iyileştiren şey benimle kalıyor.
№3. Bunu nasıl sürdürüyorsun? (Zihinsel notlardan belge tutma, StyleCop gibi bir araç kullanma vb.)
Tarzımı hatırlıyorum ve her yere otomatik olarak uyguluyorum.
Not 1. Güncel kalmak için bir gözü açık ve bir kulağı keskin tutmak son derece önemlidir. Yıllar önce başkalarından Macaristan gösteriminin bir zorunluluk olduğunu öğrendim, bu yüzden onu takip ettim. Topluluk o kadar da büyük olmadığını fark ettiğinde herkesle değiştim.
Not 2. Hangi stil öğelerini benimsediğiniz çoğu zaman önemli değildir, aksine stilinizi kodlarınız boyunca tutarlı tutarsınız. Aynı şey bir takım için de geçerlidir. Bir stil seçin, ancak buna sadık kalın.
Not 3. Farklı diller için kodlama stilleri değişebilir. C ++ bir stili, diğerini Java hak ediyor. HTML ve CSS özellikleri tekrar farklı bir stil gerektirir.
Not 4. Hangi tarzı seçerseniz seçin,% 100 çalışmayacağını anlayın ve kabul edin. Bazen, yerinde çok farklı, farklı hizalama veya belirli kod parçasını daha okunabilir tutmak için ne olursa olsun, yerinde farklı bir stil gerektiren bazı kodlarınız olabilir. Tarzınızı her yere itmeyin, kod okunabilirliğine odaklanın. Açıksa, stil bu belirli yerde çalışmaz, bir istisna yapın.
Not 5. Bir dine kod tarzını izlemeyin. Kod stilini uygulayan araçlar iyidir, ancak bazen sizi çıldırtabilir. Mesela Visual Studio'nun otomatik kod formatını devre dışı bıraktım çünkü beni deli ediyordu. Bir araç bir engel haline gelirse, bir istisna ekleyin ve kodunuzun% 100 uyumlu olmadığından endişelenmeyin. Bu o kadar da önemli değil ve ulaşılamayan mükemmellik zaten.
Ben "Tamam bu benim tarzım olacak" dediğim bir zaman olduğunu sanmıyorum. Belirli bir ortama veya dile odaklanın. Tarzınız belirli bir sorunla karşılaşma şeklinizi yansıtmalıdır.
MSDN'de yansıtılan stiller de dahil olmak üzere farklı stillerin özelliklerini benimsedim. Daha sonra #region/#endregionbloklarımı ve tercih edilen başka bir şeyi sağlayan VS'de şablonlar ayarladım .
Araştırma ve okuma yoluyla karşılaştığım diğer stilleri incelemeye devam ediyorum. Eğer göze çarpan ve okunabilirlik, bakım veya organizasyondaki tarzımı geliştirebilecek bir şey olduğunu düşünürsem deniyorum. Yeni bir stil ayarlaması yapılırsa, VS'deki şablonları güncelleyeceğim veya zihinsel notlar yapacağım.
Yalnız kodlarken kısalık hedefliyorum; Spartan Programlama tam olabilir , sersemlik deliliği ... Ama muhtemelen inancım için en yakın tanıdık şey.
Başkalarıyla, özellikle de bakım kodlamasıyla kodlarken, bukalemun olmayı hedefliyorum - yaptığım değişiklikler, yer değiştirmeden değiştirdiklerini iyileştirmelidir.
Kodlama stilinizi nasıl tanımladınız ve buldunuz?
Basitlik ve okunabilirliğe odaklanarak (okunabilirlik! == anlaşılabilirlik, bkz. Spartan Programlama )
Nasıl büyütmeye ve geliştirmeye devam ediyorsunuz?
Başkalarının ve kendi kodumu gözden geçirerek (ve hatta standartları kendileri kodlayarak).
Bunu nasıl sürdürüyorsun? (Zihinsel notlardan belge tutma, StyleCop gibi bir araç kullanma vb.)
Kullandığım dokuwiki , bir kurulum için esinti (hiçbir veritabanı), hiyerarşik yapısı, (kutunun dışında ACL) ayrıntılı denetime gerçekten güzel görünüyor, ve iyi, onun bir wiki, herkes katkıda bulunabilir böylece. Ayrıca, katkılar / değişiklikler her zaman fikir birliği altındadır ve yalınlık ve okunabilirlik temelinde gerekçelendirilmiştir.
Bu garip bir cevap, ama gerçekten programlamayı almak için çok uzun zaman aldım. Kendimi bir programcı olarak düşünmeden önce 'sanatta' çalışmak için çok zaman harcadım.
Kod yazarken, paragraflar, ifadeler vb.Gibi birimler halinde düşünmeye eğilimliyim. Bu nedenle, bir hikaye / deneme / vb. Geliştiriciler bir hatta veya küçük bir alana olabildiğince sıkıştırmaya çalıştıklarında gerçekten rahatsız oluyorum, çünkü yazarın zeki ve gelecekteki okuyucuları rahatsız etmesinin yanı sıra hiçbir şey yapmıyor.
Verimlilik uğruna garip bir şey yapmam gerekirse, neden böyle olduğunu açıklamak için yorum yapacağım.
Muhtemelen bunun için herhangi bir oy almam ama belki de yine de biraz tartışmaya yol açacaktır.
Teknik tarafa gelince, parantezlerin yerleştirilmesi ve benzeri gibi, sonuçların okunabilirliği arttığı için onları hizalı tutarım.
1. How did you define and find your coding style?
Büyük bir şirket / proje tarafından büyük ölçüde geliştirilmiş ve yaygın olarak kabul görmüş veya yaygınlaştırılmış, zaten geliştirilmiş bir stil rehberini benimsemeye gidiyorum.
Bunu birçok nedenden dolayı yapıyorum, ancak esas olarak bu tarz kılavuzlar geliştiriciler tarafından hemen benimsenebileceğinden. Bir stil kılavuzu, geliştiricilerin buna istekli olduğu kadar değerlidir.
Python'un PEP 8'i , Android için Java'nın stil kılavuzu , jQuery Core stil kılavuzu veya Google'ın Python stil kılavuzu bunlara örnektir .
2. How do you keep augmenting and improving it?
Bu tarz rehberler için en büyük argüman, burada icat edilmemiş ve benim tarafımdan icat edilmemiş olmalarıdır. Geliştiricilerin puanları, korkutucu kod satırları ve şirketinizin / ekibinizin bir stil rehberi geliştirmek ve sürdürmek için yatırım yapmaya istekli olduğundan daha fazla zaman aldı.
Gelişmelere gelince, bilmeniz gerekebilecek her şeyi hemen yanıtlayan bir stil rehberi hiç olmadı . Ancak, çoğu durumda, ileriye doğru itildiğini gördüğüm gelişmeler, stil kılavuzunun kod yazma yaklaşımı ile halihazırda ortaya koyduğu şeyin sadece daha ayrıntılı bir versiyonuydu.
Bu tür durumlarda, bir gariplik bloğuyla karşılaştığınızda, bir sözdizimine ya da renk sözdizimi desteğiyle başka bir uygun kod snippet paylaşım aracına yapıştırmalı ve başka geliştiricilerle bir yerde tartışmalısınız. Hakkında harika bir şey, bu gibi durumlarda, kodun ne yaptığıyla ilgilenmemeniz, ancak kodun nasıl göründüğü ile ilgilidir, böylece bu bloğu bağlamdan çıkarabilir ve onu daha önce belirtilmiş olanlarla karşılaştırarak nasıl geliştirmeniz gerektiğini tartışabilirsiniz. tartışmalar için ana başlangıç noktası olarak stil kılavuzu.
3. How do you maintain it?
Harika olan şey, zaten çevrimiçi olarak kamuya açık tutulan mevcut belgelere sahip olmanızdır.
Kod biçimlendirme söz konusu olduğunda, ekstra mil gidebilir ve ekibinize favori düzenleyicileri için biçimlendirici yapılandırmaları sağlayabilirsiniz, bu da üst düzey görünümleri koruma konusunda kabalık ve tahmin yapmayı gerektirir. Aslında, fazladan bir mil çıkmasını söyleyemem, ancak gelişimin ayrılmaz bir parçası - kod değişikliklerinin% 90'ının, birinin uygun şekilde biçimlendirilmiş / stilize edilmiş kodun check-in olduğu bir fark yaratmanın daha kötü bir şey olmaması büyük yeni bir özellik taahhüt etmeden önce temizleyin.
Bir ekibin parçasıysanız, her zaman ekibin standardını toplamanız gerekir. Kendi kişisel düzeninizi değil, genel bir düzen kullandığınız söylenecek çok şey var. Kodunuzun başkaları tarafından okunmasını ve anlaşılmasını kolaylaştırır, bu da önemlidir.