VCS kullanırken kod biçimlendirmek kötü bir şey mi?

24

Doğru yapıldığından emin olmadan önce kodumu hemen hemen her zaman biçimlendiririm. Takımımın çoğu gerçekten önemli değil ve kodlarını her zaman doğru şekilde biçimlendirmiyorlar (kodu etkilemeyen ancak bakımı yapmaya çalışırken okunabilirliği etkileyen küçük şeyler).

Geçenlerde "Kaydetme sırasında biçimlendirme" seçeneğine sahip VS elektrikli el aletlerini kurdum ve önceden biçimlendirilmemiş bir dosyada değişiklik yaptım. Geliştirme VP az önce bana geldi ve birleştirme aracında bir veya iki satır yerine neredeyse tüm dosyanın değiştiğini gösterdiği için biçimlendirme için beni azarladı (ve kolayca değiştirdiğim şeyi tam olarak göremiyordu) ve Gelecekte kaydetme biçimini devre dışı bırakmamı söyledi. Bu endişeyi anlasam da, bazen biçimlendirilmemiş kodları sıralamakta zorlanıyorum ve IMO her zaman için doğru şekilde biçimlendirilmelidir. Sadece bir hevesle ilgili şeyleri yeniden biçimlendirmekle kalmadığımı unutmayın, ancak kod yazarken, metni okumayı kolaylaştırmak için biçimlendirmek için elektrikli aleti kullanacağım veya tuş komutunu kullanacağım. bir değişiklik.

Bu yüzden soruyorum, kodu her zaman biçimlendirmek aslında kötü bir şey midir? Kaygıları, kodun okunabilir olduğundan emin olmaktan daha mı geçerli?

code-formatting

— Allan Wight
kaynak

8

O haklı, o yüzden neden tüm ekibe kaydetme biçimi aracını kullanmalarını sağlamıyorsunuz? Öyleyse, tümü kolay okunabilen ve görüntülenmesi kolay olan farklı biçimlerde kod elde edersiniz.

— gbjbaanb

12

En iyi dosya karşılaştırma araçları "önemsiz farklılıklar" veya "boşlukları yoksay" için bir filtreye sahiptir. Beyond Compare gibi bazıları önceden oluşturulmuş dile özgü filtrelerle birlikte gönderilir. Eğer varsa, bunu kendi avantajınıza kullanın.

— Michael K,

7

Kodun biçimlendirilmesi yapılan değişiklikler kadar önemlidir. Bir takımdayken okunabilirliğin en yüksek önceliklerden biri olması gerekir. Başkan Yardımcınız bunu bilmeli ve bu konuda endişelenmeli.

— Edgar Gonzalez,

@Edgar: +1. Başkan yardımcısı çok seçici davranıyor. Önce okunabilirlik ... ve boşlukla yoksay seçeneği, bunun önemli olmadığı anlamına gelir. Aynı zamanda daha büyük bir sorun olduğu anlamına geliyor çünkü takımın geri kalanı umursamıyor. Başkan yardımcısı bu konuda daha çok endişelenmeli.

— hızla_

41

Öncelikle, ekibinizin bir biçimlendirme sözleşmesi seçmesi ve buna bağlı kalması gerekiyor. Bir anlaşmaya varmanız ve herkesin buna bağlı kalması gerekir, böylece neye benzemesi gerektiği konusunda kavga eden insanlar olmaz. Bu sadece kendi başınıza yaptığınız bir şey olmamalı.

Gerçek sorunuza gelince. Kod biçimlendirmek kötü bir şey değil. Kötü olan, kod değişiklikleriyle aynı şekilde büyük biçimlendirme değişiklikleri yapmaktır. Ekibiniz işlerin nasıl biçimlendirilmesi gerektiği konusunda fikir birliğine geldiğinde, kodlardan birini geçmek ve her şeyi biçimlendirmek Bunu kendi başına kontrol et. Taahhüt mesajı, değişikliklerin yalnızca beyaz boşluk olduğunu ve işlevsel olmadığını açıkça belirtir. Daha sonra fonksiyonel değişiklikler yapmanız gerektiğinde, farklı bir taahhütte bulunurlar, böylece açıkça görülebilirler.

— unholysampler
kaynak

birkaç revizyondan önce yapılan değişiklikleri karşılaştırmak isteyip istemediğinize yardımcı olmaz, ancak kod değişikliği + format değişikliklerinden 1 seferde daha iyidir. Tabii ki, bu cevap refactoring için de geçerlidir.

— gbjbaanb

1

+1: Buna ek olarak, Stylecop veya stili otomatik olarak biçimlendiren ve uygulayan başka bir araç gibi bir şey kullanmak iyidir. Ardından, ayarları tüm ekip üyeleri arasında senkronize edin, böylece biçimlendirme herkes arasında tutarlı olur ve mutlaka "doğru" biçim kuralının ne olduğunu hatırlamanıza gerek kalmaz.

— Ryan Hayes

3

OP bir belgeyi biçimlendirmeye çalıştığı için azarlandıysa, bir şey bana StyleCop'u kullanmasını öneremeyeceğini söylüyor.

— Wayne Molina

3

@gbjbaanb: Evet. Bu yüzden bu tür kararları başlangıçta almak en iyisidir. Şu an üzerinde bulunduğum proje depoda kontrol edilen Eclipse formatlayıcı ayarlarına sahip, böylece herkesin aynı ayarları yaptığını biliyoruz.

— unholysampler

1

@quickly_now: Bu yüzden veto haklarına sahip yöneticilerimiz var. İnsanlar aynı fikirde olmazsa, bir karar verebilirler.

— unholysampler

29

Hayır, biçimlendirme kodu çok önemlidir . Ancak, taahhütler iki grupta yapılmalıdır:

Kozmetik değişiklikler - kodu daha okunaklı yapan her şey.
Diğer değişiklikler - kodu etkileyen her şey.

Yalnızca kozmetiklerin değiştirildiğini belirtmek için onay mesajını kullanın. Daha önemli değişiklikler ararken bunlar kolayca atlanabilir.

— JK
kaynak

3

Ek olarak, ekibiniz arasındaki belirli bir biçimlendirme kuralına karar vermek de iyi bir uygulamadır. İlk önce bunu tartışmadan başkalarının kodunu biçimlendirmeyin.

— Steven Jeuris

Evet .. Ama bilirsin, bazen "sen varken" bu lanet karışıklığı biçimlendirmek çok caziptir. Ayrıca, kozmetik değişiklikleri fonksiyonel değişikliklerden ayırmaya çalışmak, eğer VS kullanıyorsanız ve bir şeyi otomatik olarak biçimlendirirseniz, ağrı olabilir. Oh, ve hiç kimse sizin tarihinize bakarak çok Önemli Görevler varken bazı aptal formatlar yaptığınızı söylemeyecek

— Dyppl

10

İkinizin de bir noktası var, ancak ikinizi de istediğiniz gibi elde edebilirsiniz. Önce kodu biçimlendirin, sadece bu değişikliği kontrol edin. Ardından, işlevsel değişikliklerinizi yapın ve bunu ikinci adım olarak kontrol edin.

— PeterAllenWebb
kaynak

3

Bence şu anki durumunuz için en iyi çözüm bu ama ekibinizle bunun hakkında konuşmalısınız. Bununla birlikte, kodlama standardının olmaması olan daha büyük bir probleminiz var.

— Thomas Owens

2

Kabul. OP’nin ortamının “işleri hızlı bir şekilde ortaya çıkarmak için” standartlara uyduğu kovboy yerlerinden biri olup olmadığını merak ediyorum.

— Wayne Molina

4

Ben de bir biçimlendirici seçiciyim, bu yüzden burada birkaç ipucu:

Gerekli ilk adım: ekibin sekmeler ve boşluklar, ayraç konumları, yorum stilleri, vs. gibi bazı temel biçimlendirme standartlarına karar vermesini sağlayın. Artık biçimlendirme değişiklikleriniz herkese tam bir sürpriz olmayacak ve adım atmayacaksınız Herhangi bir parmak ucunda.
Biçimlendirmeyi yalnızca değiştirdiğiniz kod etrafında temizleyin. Yalnızca bir işlevde değişiklik yaparsanız, o işlevi temizleyin. En azından zamanla daha iyi görünen bir kodunuz olacak.
Büyük biçimlendirme revizyonları, başka hiçbir kod değişikliği olmadan ayrı bir işlem olarak yapın. Bunları yalnızca değişiklikten önceki değişiklikten sonraki kodu karşılaştırmak isteme olasılığınız düşük olduğunda yapın, çünkü böyle bir fark karşısında karşılaştırma can sıkıcı olabilir. Genelde bu kodun geliştirilmesinden önceki ilk şeyleri temizlerim.
Önemli değişikliklerin ve önemli olmayan değişikliklerin dile bağlı olarak işaretlenebilen iyi bir fark aracı edinin. Benim favori farkım da Ötesinde Karşılaştırma gerçek kod değişikliklerini bir renkte işaretler ve boşluk / yorum yalnızca diğerindeki farkları gösterir.

bir ipucu daha düzenle:

Biçim dilini diline göre değiştirir, ancak koddaki gerçek kozmetik değişiklikler için derleme işleminden önce ve sonra derlenmiş ikilileri karşılaştırabilmeniz gerekir.

— John
kaynak

İkili VC etiketlerini dahil etmediğiniz sürece (veya derleme bilgisi).

— Vatine

2

Aşağıdakiler dışında, diğer kişilerin kodunda yeniden biçimlendirme yapmamalı ve değişiklik yapmamalısınız:

siz takım kodlama standartlarını oluşturmaya çalışan yöneticisiniz
yöneticiniz sizden takım kodlama standartlarına uymak için kodu temizlemenizi istedi
Takım kodlama standartlarına uymak için artık takımınızdaki bir geliştiriciden kod temizlemiyorsunuz.

Her durumda, takım kodlama standartlarına atıfta bulunduğumu fark edeceksiniz. Takım için makul, kararlaştırılmış kodlama standartlarına güçlü bir inancı duyuyorum. Onlara sahipseniz, orijinal geliştirici geri dönmeli ve takım standartlarına uymak için kodunu temizlemeli, bunu arkasından yapmamalısınız. Eğer standartlarınız yoksa (ve gerekir), başka bir ekip üyesinin kodunu, özellikle de onların arkasındaki felsefelerinize uyacak şekilde değiştirmemelisiniz. Unutmayın, bir takımın bir parçasısınız ve kodlama standartları önemliyken, ekip üyeleri arasında güven ve saygı da var.

— cdkMoose
kaynak

“Arkanların ardında”: bu, kod sahipliğinin psikolojik sorunlarına (ya da kalkınma çim savaşına) dayanıyor.

— rwong

2

"Diğer insanların kodu", söylemenin ilginç bir yoludur. Şirketimin ürününde çalışıyorum, şirketimin sahip olduğu koddan derledim, ekip arkadaşlarım ve ben üzerinde çalışıyoruz. Üzerinde çalışırken standartlara ulaştırmak için hiçbir şekilde arkalarında durmuyor. Bununla birlikte, ideal çözümün asıl geliştiriciyi standartlara göre temizlemesini sağlamak olduğuna katılıyorum.

— Caleb Huitt - cjhuitt 14:11

@Caleb: Onlar sadece düz reddediyorlarsa zorlaşır.

— hızla_kanat

"Başkalarının kodu" derken, mülkiyeti kastetmiyorum, yazdıkları ve hala desteklemekten sorumlu olduklarına inandıkları bir şeyi kastediyorum. Kodlama standartlarının yokluğunda, 1000 kod satırı olan bir sınıf uygularsam ve bazı davranışları düzeltmek ve tüm dosyayı yeniden biçimlendirmek için 2 satırda değişiklik yaparsanız, dosyayı açtığımda çok şaşıracağım. Bir takımın üyeleri olarak bunu birbirine yapmamalıyız. Bu dosyayı tam bir yeniden biçimlendirme ile kontrol ederseniz ve bana kafa bile atmazsanız, bu çok takım dostu değildir.

— cdkMoose

OP’lerin orijinal tartışmasında, kodlama standartlarına sahip olmayan (ya da iyi uygulanmayan) bir ortam olduğunu okudum, bu yüzden böyle cevap verdim. Bu ortamda, bir geliştirici standartlarını başkalarına dayatmamalı.

— cdkMoose