Birden fazla farklı kitaplık kullanırken stilleri kodlama

Tüm farklı kodlama stilleri olan bazı C kitaplıkları da dahil olmak üzere birçok kitaplık kullanan bazı C ++ kodu üzerinde çalışıyorum. Kullanılabilir bir aşamaya ulaştığında açık kaynaklı olacaktır. Hangisi, bir hatayı düzeltmek veya bir özellik eklemek için kodu kontrol eden kısa vadeli bir katılımcı için en az karışıklığa neden olur?

• Zaman zaman kullanılan kütüphanelerin tipik kodlama stiliyle eşleşmese bile tüm uygulama boyunca tek bir tutarlı kodlama stiline sahip olun.
• Bir kütüphane belirli bir modülde yoğun olarak kullanıldığında, o modülün o kütüphanenin tipik kodlama stiline (yani kütüphanenin kendi kodunda ve belgelerinde kullanılan kodlama stiline) uyun.

Benim düşüncem, ikincisinin söz konusu kütüphanedeki uzmanların bir kereye mahsus katkı yapmasını ve geliştirme sırasında öğretici / örnek kod eklemeyi kolaylaştıracağıdır. Bununla birlikte, kodlama stilini uygulama boyunca tutarsız hale getirir. Her yaklaşımın artıları ve eksileri nelerdir?

Bence bu, projenin ne kadar büyük olacağına bağlı.

Bir uçta, 1 Mloc projeniz olduğunu varsayalım. Bu kadar büyük bir proje için, tek bir bireyin ilgili tüm alanlarda "uzman" olması olası değildir. Yani bu durumda, her ana bileşen için mevcut kod stilleri ile yapışır. Yeni geliştiriciler bir alan seçecek, öğrenecek ve farklı kod stillerine sahip olabilecek diğer birçok bileşeni görmeleri pek olası değil.

Proje nerede, çok küçükse olan bireyler tüm kod tabanını anlamanıza olma ihtimali, o zaman bununla bir baskın kod stili ve sopa almak istiyorum. Bu durumda, tüm projedeki tutarlılığın daha anlamlı olduğunu düşünüyorum çünkü yeni geliştiricilerin projenin tüm alanlarında çalışması muhtemeldir.

Orta ölçekli projeler bu kararı vermek belki de en zor olanıdır. Bu durumda, her bir yaklaşımın maliyetlerini tartmanız ve uzun vadede en az pahalı olacağını düşündüğünüze karar vermeniz gerekir. Zor olan nokta, orta ölçekli projelerin genellikle tam bir stil yeniden düzenlemenin oldukça pahalı göründüğü kadar büyümüş olmasıdır. Belirli kod stillerini birlikte gruplandırmak için bir şeyler düzenlenip düzenlenemeyeceğini görmek için kod ağacı yapısına ikinci bir göz atmak isteyebilirsiniz.

Her iki durumda da, nihai karar, bu paketi bir araya getiren ekiple birlikte olmalıdır.

Mantığımı yukarıdan kaydırabilecek bazı aykırı değerler:

• Bir veya daha fazla modül iğrenç bir tarza sahipse, daha büyük bir projede bile bunu korumanın bir anlamı yoktur. Evet, stil özneldir, ancak siz ve proje katılımcılarınız gerçekten, belirli alanların akış şeklinden gerçekten hoşlanmıyorsanız, o zaman eski stili nükleer silahlara sokun ve daha iyi bir alan verin.

• Tüm stiller birbirine oldukça yakınsa, "işte yeni yol" ilan etmek ve bunu tüm yeni kodlar ve önemli yeniden düzenlemeler için kullanmak kadar kolay olabilir. Bu, incelemeleri biraz acı yapabilir, ancak tecrübelerime göre çoğu halk bu yaklaşıma uyum sağlama konusunda oldukça yeteneklidir. Ayrıca eski kodun nerede olduğunu gösteren bir işaret de sağlar.

• Bazen stil, dile eklenen yeni işlevlere göre kaydırılır. C ++ yıllar içinde birçok özellik aldı. Daha eski stili bu özelliklerden yararlanan daha yeni bir stile gerektiğinde yeniden düzenleme yapmak mantıklı olabilir.

• Bazı kütüphaneler özellikle deyimsel bir yaklaşıma veya stile sahip olabilir. Eğer öyleyse, projenin geri kalanıyla çelişse bile o kütüphane için bu stile sadık kalacağım. Buradaki amaç frobnosticators, diğer projeler üzerinde çalışan birinin projeniz üzerinde de çalışma olasılığını artırmaktır .

Bazı yorumlar zorunlu ve nesne yönelimli stilleri bir düşünce olarak belirtmiştir.

Belirli bir tarzda "ağır" olan modüller, modül orta büyüklükte veya daha büyükse muhtemelen bu şekilde kalmalıdır. Üç ana stil (emir, nesnel ve işlevsel) ile çalıştım ve ağır emir stillerini bir OO stiline yeniden yansıttım. Orta veya daha büyük bir kodla, yeniden düzenleme (istisnai olarak) zor olabilir. Yeniden düzenlemeye yardımcı olacak hiçbir takım desteğim olmadığı için deneyimlerim şaşkına döndü.

Çok zor bir şekilde şekillendirilmiş modüller ile bu modüllerin belirli gelişim nişleri için deyimsel olduğunu ve aykırı değerlerle yükselttiğim son noktaya kadar geri döndüğünü hayal ediyorum. Bu işlevsellik için bulacağınız herhangi bir modül böyle görünecek ve bu alanın uzmanlarının projenizde de kolayca çalışabilmesini istiyorsunuz. Ancak seçenekler varsa ve ekibiniz bu modülün stilini sevmiyorsa, seçenekleri araştırırım.

Aynı şekilde, OO ilkelerinin çok ileri götürüldüğü ve yanlış kullanıldığı ağır bir OO tarzı modülle çalıştım. Örnek olarak, arayüzler çoklu mirasın yerine kullanılmıştır. Tahmin edebileceğiniz gibi, bu kaba bir uygulamadır. Bu modülü yeniden düzenleme konusunda makul bir ilerleme kaydedebildim, ancak bunun yerine kullanmak için daha iyi paketler bulduğum için bu yaklaşımı terk ettim.

En azından dikkate alınması gereken birden fazla katman var gibi görünüyor:

1. Mevcut kütüphaneler ve bunlarda yapılan değişiklikler.
2. Bu kütüphaneler için yeni birim test kodu.
3. Soyutlama katmanı.
4. Soyutlama katmanı tarafından sunulan API.
5. Soyutlama katmanını kullanarak örnek ve test kodu.

Ben sadece ortak bir stil ön tüm kodu yeniden refactor için mantıklı olmadığını varsayacağım - eğer öyleyse soruyu sormak olmazdı.

Her birini sırayla almak:

1. Mevcut kod tabanı için, muhtemelen bu stile bağlı kalmak isteyeceksiniz.
2. Mevcut kod için yeni birim test kodu, özellikle eski kodla ne kadar entegre edildiğine bağlı olarak gri bir alanda duruyor. Ama büyük olasılıkla, 'tercih edilen tarzda' yapmaya çalışardım.
3. Soyutlama katmanındaki yeni kod. Bunun gerçekten ayrı bir kod katmanı olmasını sağlayarak, kod eski bir stil veya stillerle çok fazla arabirim yapıyor olsa bile, tercih edilen bir stili kullanmakta herhangi bir zorluk olmamalıdır. Çoğu kod diğer stilleri ile arayüz gerekir ve ben asla bu bir problem bulmadım.
4. Açıkçası API'nin kendisi en çok düşünmeye ihtiyaç duyuyor ve maksimum kullanılabilirlik gereksinimlerini karşılıyor.
5. Herhangi bir örnek veya test kodu da benzer şekilde tercih edilen tarzda yazılabilmelidir. Soyutlamanın tamlığına bağlı olarak (yani alt katmanları tamamen gizleyip gizlemediği), bu kolay veya zor olabilir. Tabii ki, gelecekteki müşteri kodunun okunabilir olmasını sağlamak temel hedeflerinizden biri olacaktır.

Şahsen bulduğum bazı şeyler büyük bir eski kod tabanı ile:

• Tercih edilen bir stil ayarlamak ve kod değişiklikleri için zorlamak, tüm eski kodun yeni stile geçişiyle sihirli bir şekilde sonuçlanmaz.

• Çoğu mühendis, belirli bir kitaplıktaki varolan stili kodlamayı (veya daha az) eğilimindedir. Aksi takdirde çok fazla yaptırım uygulanır.

• Eski bir kitaplıkta tercih edilen bir stile ihtiyaç duyulması, o kitaplıkta stilde çok fazla tutarsızlığa neden olma eğilimindedir. Bu nedenle, yalnızca sunumla ilgili olan standartlar için, kod sağlamlığının aksine, bunları gerektirmekte çok fazla fayda görür.

Son bir konu olarak (biraz konu dışı ama ilgili olduğunu düşünüyorum), gerçek şu ki, bazı mühendisler en iyi bildikleri dışında herhangi bir stil standardına bağlı kalmaya çalışıyorlar. Ekibi stil kararlarına dahil etmenizi ve satın alma olduğundan emin olmanızı şiddetle tavsiye ederim. Bunu yaptıktan sonra, karışık kodda bir standart uygulamak için çok daha iyi bir konumdasınız.

Çok sayıda üçüncü taraf modül içeren büyük boyutlu bir proje geliştirmeniz durumunda @MetaFight ile anlaşacağım.

Sorununuzu gerçek bir kelime problemiyle eşleştirelim: " Evinizde sessiz bir yaşam tarzınız olduğunu varsayalım. Yerinizin sessiz olmasını seviyorsunuz, asla daha yüksek sesle konuşmuyorsunuz ve ailenizin herhangi bir üyesinin bunu yapmasını hiç sevmiyorsunuz. eviniz için bir şeyler getirmek için her gün farklı insanlar.Onlar da daha düşük sesle konuşacaklar, bu durumda bu tür insanlarla uğraşırken kendinizi buna göre şekillendirirsiniz.Bu nedenle, bu insanlar için arayüz veya sargı sadece uğruna oldukça esnektir. iş yapılacak. "Dumb örneği ... lol

Ama benim amacım, kodlama standartlarına göre bu tür kütüphaneler için, bu kütüphaneleri içerideki orijinal kodlama tarzınızı koruyan bu sarmalayıcılar aracılığıyla kullanacak şekilde sarmalayıcı oluşturmaktır.

MetaFight için +1.

Açıkçası, projeniz boyunca tek bir kodlama stili kullanmak için en az miktarda karışıklığa neden olur. İlk etapta bir kodlama stili kullanmanın amacı, kodun okunmasını ve değiştirilmesini kolaylaştırmaktır.

Bir kütüphanede dahili olarak kullanılan kod stiline gelince, bunun alakalı olduğunu düşünmüyorum. Kütüphane çok zorunluysa, etrafına bir OO sarıcısı yazmak iyidir, ancak bu, kütüphanenin örneklerinde veya içlerinde olduğu gibi aynı kod stilini kullanmanızı gerektirmez.