Bir iş arkadaşı sadece görünümü değiştirmek için kodunuzu düzenliyorsa ne yapmalı?


16

Bir iş arkadaşınız kodunuzu düzenliyorsa ne yapmalısınız?

İşlevselliği eklemek veya hataları düzeltmek amacı olmadan, sadece görünüşünü değiştirmek için ...


9
Sanırım bununla ilgili bir sorunun var. Öyleyse neden? Kodu daha da kötüleştiriyor mu?
Zaz

3
@Josh: Evet, aslında kodu daha da kötüleştiriyor, çünkü onu yazan adamdan başka bir programcı tarafından bakımı daha zor.
Robert Koritnik

4
ona daha fazla iş ver
Oscar Cabrero

4
@Robert - Sanırım Josh'un amacını özlüyorsun. Kodun görünümünü değiştirme olabilir objektif hale kolay o kötü başlamak biçimlendirilmiştir özellikle ... korumak için.
Stephen C

4
Gerçekten sizin kodunuz mu, yoksa ekibe ait mi?
Eric King

Yanıtlar:


28

Onlarla bunun hakkında konuş. "Bunu beni kızdırmak için yapmıyorlar ya da bir çeşit obsesif kompulsif bozukluk olduğu için kodumu daha iyi hale getirmeye çalışıyorlar."

Çünkü yanlış olabilirsin. Bu ince bir hata düzeltmesi olabilir ve sadece onu fark etmediniz.

Veya, ihlal ettiğinizi bilmediğiniz bir kodlama standardı olabilir ve sadece düzeltiyorlar.

Ya da sizi rahatsız etmeye çalışıyor olabilirler veya bir çeşit obsesif kompulsif bozukluk olabilirler. Durum buysa, onlardan güzel bir şekilde durmalarını isteyin ve eğer işe yaramazsa, patronunuzla birlikte alın.

Ama sormadıkça asla bilemezsin.


17
Birçok IDE'nin otomatik biçimlendirme özelliklerine sahip olduğunu belirtmek gerekir. Onları düşünmeden sürekli kullanıyorum. Bazıları, nasıl yapılandırıldığına bağlı olarak, projenizdeki tüm dosyaları veya açtığınız tüm dosyaları biçimlendirir. Yanlışlıkla otomatik formatlamak kolay olabilir.
Matt Olenik

@Matt: Mükemmel nokta.
BlairHippo

1
"Bunu yapmıyorlar ... çünkü bir çeşit obsesif kompulsif bozukluk var;" Öncelikle kendimden bahsetmişken, durum her zaman böyle değil! Kodlama söz konusu olduğunda ben iki şeyim: bir mükemmeliyetçi ve temiz bir ucube. Buna rağmen genellikle bu zihniyeti meslektaşlarımın çalışmalarına uygulamaktan kaçınırım.
Nathan Taylor

5
Oh, Tom'un meslektaşına zayıf bir sınır duygusu olan OKB düzgün bir ucube olmadığını söylemiyorum. Ben sadece "Seninle birlikte YANLIŞ ne var ?!" verimli bir konuşma yapmanın iyi bir yolu değildir. :-)
BlairHippo

1
@Chris gerekçe hakkında endişelenmenize gerek yok, her zaman Ctrl + K + D!
Nathan Taylor

16

Kodum beni rahatsız etmek için nasıl görünüyor bu kadar evli değilim. :) Değişikliklerden öğrenmeye çalışıyorum. İş arkadaşım değişken isimlerini ayarladı mı? Daha verimli bir döngü mi yazıyorsunuz? Kod daha okunabilir hale getirilsin mi?

Değişikliklerin zaten orada olanı nasıl iyileştirdiğini göremezsem, genellikle değişiklikleri yapan iş arkadaşına arkasındaki motivasyonun ne olduğunu soruyorum. Avantajın benim için açık olmaması mümkündür. Ve eğer haklıysam ve yanılıyorlarsa, o zaman neden yazdığımı açıklayabilirim.

Her şey başarısız olursa, check-in işlemini geri alın. ;)

Düzenleme: Kozmetik değişiklikler yapma arzusu bir hata getirdi, ancak tüm bahisler kapalı.


9

IMO siz ve ekibiniz yine de bir kodlama standardı kullanıyor olmalısınız. Bu durumda, sorular 'orijinal kodunuz standarda uygun mu?' 'Evet' ise, iş arkadaşınız işlevsel olarak değiştirmedikçe kodunuza dokunmamalıdır. 'Hayır' ise, meslektaşınızın kodunuzu toplama hakkına sahip olduğundan korkuyorum. Bir proje sorumlusu olarak kendimi her zaman yapıyor buluyorum.

Bir kodlama standardı kullanmıyorsanız, 'iyi kodu' neyin oluşturduğuna dair tüm argümanlar çok öznel hale gelir. Bu yüzden neden bir kodlama standardı kullanmalısınız :)


8

Bu insanlardan biri olarak (bazen diğer insanların kodlarını yeniden biçimlendiren insanlar), bunu yapmamın ana nedeni okunabilirlik. Bazı insanlar çentikleri veya karıştırma tırnakları ve boşlukları ile son derece özensizdir.

Değişme alışkanlığımdaki en önemli şey, uzun satırları azaltmaktır, böylece her şeyi yatay kaydırma yapmadan okuyabilirim. Karmaşık ifadeleri ayrı ifadelere bölerim veya tek bir satıra rahatça uymuyorsa satır başına bir parametre listelemek için yöntem çağrılarını / bildirimlerini yeniden biçimlendiririm. Ayrıca, İngilizce hataları düzeltmek veya yalnızca işleri daha net hale getirmek için yorumları düzenleyeceğim.

Evet, yalnız bırakabilirim, ama kodu okumak için gereken zihinsel çabayı azaltmayı tercih ederim.

Bu konuda ne yapmalısın? Öncelikle, belki bu kişinin kodunuzu daha iyi hale getirdiğini düşünün. Ayrıca, ekibinizde kodun nasıl biçimlendirilmesi gerektiği konusunda fikir birliğine sahip olduğunuzdan emin olmalısınız. Her insanın farklı alışkanlıkları varsa, herkesi yavaşlatacaktır. Kodunuzu daha iyi hale getirmiyorlarsa ve tahıllara karşı çıkıyorlarsa, onlarla bu konuda yüzleşmeniz gerekir. Bu işe yaramazsa, başkalarını dahil etmeniz gerekebilir.


Bu sizin okunabilirliğinizdir, girintisiz SQL kodunu okumak çok daha kolay buluyorum çünkü hızlı ve girintili kodu okudum beni yavaşlatıyor ve odaklanmamı zorlaştırıyor.
HLGEM

6

Onlara neden bunu yaptıklarını sorun; geçerli bir açıklama hayal kırıklığınızı azaltabilir, ancak sizi ne kadar rahatsız ettiğini bilmelisiniz. Kim bilir, belki de sana bir iyilik yaptığını düşünürler ve öğrendiklerinde seni rahatsız ederler. Veya gerçekten tıbbi bir durumdan muzdarip biriyle uğraşıyor olabilirsiniz.


"Veya OKB'si var ve ilaç tedavisi gerekebilir." - arkadaş canlısı kalmak istiyorsanız bu bölümden bahsetmemek en iyisi
Zaz

Bir değişiklik yapacağım.
JeffO

5

İzin var mı? Değişiklikler kodu geliştiriyor mu? Eğer öyleyse, gururunu yut. Kod kalitesinin kötüleştiğini düşünüyorsanız, iş arkadaşınızla birlikte alın ve neden açık bir fayda olmadan kodunuzu değiştirme ihtiyacı duyduklarını sorun. Rahatsızlığa rağmen yapılıyorsa veya kişi yanlışlıkla sizden daha iyi olduğunu düşünüyorsa ve onlarla çalışamazsanız, patronunuzla birlikte alın.


5

IDE'nin Visual Studio gibi bir Format Documentkodu, kullanıcının IDE'de ayarladığı kurallara göre kodu biçimlendirecek bir seçeneğe sahiptir. İş arkadaşınız bunu kullanıyor olabilir (bilmeden otomatik olarak veya kasıtlı uygulama ile). Belki de IDE'si sekmeler yerine boşluklar kullanıyor veya tam tersi ve bunlar bile bilmeden otomatik olarak uygulanıyor? Ama öğrenmek için onlarla konuşmalısın.

Bu arada, açıkça bir tür biçimlendirme şemasını takip etmiyorsa, iş arkadaşlarının kodunu sık sık yeniden biçimlendireceğim (yani her yerdedir). Onları fark etmenin umarım ki ince bir yolu. (Ancak, düzgün olsaydı yeniden biçimlendiremezdim, ama beğenime göre değil).


1
"(Ancak, düzgün olsaydı yeniden biçimlendiremezdim, ama benim zevkime göre değil)" - takip etmek çok önemli bir kural, +1
Zaz

Geliştirme yönergelerimiz, kod stilini 'önerilen' köşeye koyma eğilimindedir. Okumayı zor bulursam kodu dosya düzeyinde önerilere otomatik olarak biçimlendiririm.
Joeri Sebrechts

3

Ekibinizin kodlama standartlarını karşılayacak şekilde değiştiriyorsa, bir dahaki sefere standartları izlemelisiniz.

Bunu, artık takımınızın kodlama standartlarına uymayacak şekilde değiştirirse, ona neyi yanlış yaptığını bildirin ve değiştirmesini sağlayın.

... Ekibinizin herkes tarafından kullanılan bir dizi kod biçimlendirme standardı var, değil mi?


2

Bazen dağınık iş arkadaşları tarafından yazılmış kodu yeniden sıralar (veya yorumlarda yazım hatalarını düzeltirim). Kod biçimlendirme ve düzen konusunda takıntılı olduğumu biliyorlar ve bu yüzden çok fazla şikayet etmeden bunu yapmama izin veriyorlar. Bazen bana bedava soda veya kurabiye verirler.

Tabii ki bu, SVN'deki "suçlama" işlevini bozduğu için nadiren yapılan bir iştir.

Bu da bir tür kod incelemesi yapmanın çok temel bir yoludur (genellikle üzerinde çalıştığım modüllerde iş arkadaşlarım tarafından işlenen kodun çoğunu okurum).


2

Kod konvansiyonlar olan cevap. İş yerinde bir tane olmalı. Bunu yapmazsanız, şimdi başlayın (iyi bir başlangıç ​​noktası google stil kılavuzudur ). Yazılı (veya en azından yaygın olarak bilinen) kurallar olduğunda, sorunuzun cevabı önemsizdir.


1

Bunu yapmanın saldırgan olduğunu düşündüğünü hissediyorum ...? Örneğin, ben kendim hemen bu kodu düzeltir

int myFunction( ) {

    int i ;
  return  0;

}

olmak

int myFunction() {
    int i;
    return 0;
}

yani ... eylemim yüzünden cezalandırılmalı mıyım? Gerçek hayatta, aslında 'Biçimlendirme' yazan tonlarca SVN günlüğüm var. ;-)


0

Stil denetleme aracı kullanma

StyleCop veya benzerlerini kullanmaya başlayın ve kod stili kurallarını uygulayın ve ayrıca tüm geliştiricilerin bunu kullanması için bir yükümlülük haline getirin. İstisnasız tüm kodlar aynı görünür. Ve kuruluşunuz için en uygun kuralları tartışmak için bilgeliklerle bir araya gelin . Varsayılan kurallar zaten .net çerçeve kodunun kendisine çok benzese de.

Bunu yapmanın en kolay yolu. Kendimi önceki işverenlerimden birinin kodunu düzeltirken buldum çünkü bu adam aşırı miktarda boş satır içeren kodlar yazıyordu ve girinti kuralları yoktu. Kod aslında ortalama bir geliştirici tarafından okunamıyor. StyleCop geri dönecek olsaydı, çoğumuz gerçekten mutlu olurdu.


Bunu oylamam gerekiyor. StyleCop, iyi bir fikrin korkunç bir uygulamasıdır. 1) Büyük projelerde büyük bir zaman katili yapan derlemeden sonra çalışır 2) Varsayılan kurallar aslında bazı durumlarda VS'nin varsayılanlarıyla çelişir 3) Bazı kurallar tamamen inantiftir. Bir boşluk bırakmadan "//" hakkında şikayet eder ve sonra bir yapıdan sonra tekrar "////" kullanmanızı söyler. En kötü yanı bu. Bu kötü olmaz, ama sonradan inşa kısmı gerçekten uzun bir inşa süresi ile büyük bir projede öldürür.
MIA

İşaret ettiğin birçok yönden seninle aynı fikirde değilim. Stil kontrolünün çalışma şeklini yapılandırabilirsiniz. İstediğim biçimlendirmeyi sağlayan kendi kurallarımın birkaçını bile uyguladım. Hız açısından harika olduğunu söyleyemem. ama iyi bir makinede gayet iyi çalışmalı. Sadece 90'ların başında C ++ copiler hızını düşünün, bu arada gidip bir fincan çay hazırlayabilirsiniz. Yapınız başarısız olmasına rağmen !!!!!! ;)
Robert Koritnik

Sadece nasıl gittiğini görmek StyleCop kullanmaya başladım ve bazen biraz sinir bozucu olsa da, aksi takdirde fark edilmeyecek hataları bir sürü bulmanıza yardımcı olur. Yapının bir parçası olarak çalıştırmanız gerekmez ve sadece yerel makinenizde çalıştırabilirsiniz, sadece tek dosyalar için. Böylece diğer geliştiricilerinizi rahatsız etmeden kullanabilirsiniz. Ayrıca, kuralları beğenmezseniz, bunları devre dışı bırakabilirsiniz, böylece gerçek bir zarar verilmez.
Anne Schuessler

+1 Bu açıkça StyleCop .. (StyleCop veya benzeri ) ile ilgili değildir. Ve bu çok iyi bir fikir. Bir kurallar kümesi tanımlayın, seçim aracınızı yapılandırın ve bu kurallarla sonsuza dek yapılmalıdır.
Bruno Schäpper

Bugünlerde bu adımı StyleCop'un geçmişte yaptığı gibi yapabilen Grunt, Gulp vb.
Robert Koritnik

0

Bu internette yeniden düzenleme hakkında konuşurken gördüğüm bir düşünce ve belki birileri neden daha iyi yapmak için kodunuza dokunsun açıklamak:

Neden?

Refactor'un iki ana nedeni vardır:

  1. Üstte inşa etmeden önce kodu / tasarımı geliştirmek için: İlk denemede iyi bir kod bulmak gerçekten zor. Herhangi bir başlangıç ​​tasarımını uygulamaya çalıştığımız ilk deneme bize mantığı yanlış yorumladığımızı veya unuttuğumuzu gösterecektir.

  2. Gereksinimlerdeki değişikliklere uyum sağlamak. Yazılım geliştirmede değişiklik olur; değişime duyarlı olmak iyi bir kod tabanına sahip olmak daha iyidir. Her iki senaryo için de iki seçeneğimiz var: kodu yollayın veya yeniden düzenleyin. Kodun yamalanması bizi sürdürülemez koda götürecek ve teknik borcumuzu artıracak, her zaman refactor için daha iyi.

Ne zaman?

  1. Ne kadar çabuk o kadar kolay.

  2. Kodun neredeyse tamamlanması için yeniden denetleyiciyi beklemek yerine, yeniden düzenlenmiş bir kod üzerinde yeniden düzenleme yapmak için daha hızlı ve daha az riskli.

Ne?

  1. Tüm kod ve tüm tasarım yeniden düzenleme için adaydır.

  2. Bir şeyi yeniden düzenlememenin istisnası, kalitesi düşük olan bir çalışma kodu olabilir, ancak son teslim tarihine yakın olması nedeniyle, planlamayı riske atmak yerine teknik borcumuzu korumayı tercih ediyoruz.

Her ikisi için de harika olacak ve gelecekte zaman kazanacaksa, elinden gelenin en iyisini yapmasına izin vermelisin!

şerefe

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.