Takip etmek zorunda kaldığınız en garip kodlama standart kuralı neydi? [kapalı]


173

Bu soruyu sorduğumda neredeyse her zaman kesin bir evet aldım, kodlama standartlarına sahip olmalısınız.

Takip etmek zorunda kaldığınız en garip kodlama standart kuralı neydi?

Ve en garip olarak, en komik, en kötü ya da sadece tuhaf demek istiyorum.

Her cevapta lütfen hangi dili, takım büyüklüğünüzün ne olduğunu ve size ve takımınıza hangi olumsuz etkileri verdiğini belirtin.


19
Bu listeyi okuduktan sonra aniden bu zorla standart boktan kaçınmak için çok şanslı bir kariyerim olduğunu hissediyorum!
matt b

Bir dahaki iş için görüşme yaptığımda, "Kırmızı Bayrak. Koş!" Olarak hizmet etmek için bu soruya göz atacağım. gösterge. Gerçekten standart anti-kalıpları kodlamak.
Stu Thompson

5
Ve kariyerimin çok erken saatlerinde, bir takıma cevaplardan birini dayattığımı itiraf etmekten utanıyorum. Çok üzgünüm beyler.
JasonFruit

Yanıtlar:


434

Ben nefret birden getiri kullanılması yasaklanmıştır ne zaman.


26
Bu kuralın varsayılan noktası nedir? Şahsen başka bir dönüş koyarak daha kolay okunabilir kod için bir kod inceleme başarısız olur.
Mark Baker

22
Öte yandan, başlangıçta "if (param == null) return null" gibi bir seçeneği kaldırmak, kodunuzu biraz temizleyebilir, bunun yerine bunu yasaklamak yerine biraz suçlu olabilir.
Bill K

39
Geçici çözüm: if (! Initialize ()) {RetVal = ERR_BADINIT; ReturnPoint'e git; } (çok daha fazla kod) ReturnPoint: return RetVal; } Sorun çözüldü! ;)
Marc Bernier

9
Yakın zamana kadar, birden fazla geri dönüş yasaklandı. Daha sonra bu, C ++ RAII tarafından eskimiş hale gelen ve 15 satırdan daha küçük boyutlu fonksiyonların C'den arta kalacağı ortaya çıktı. O zamandan beri, Braveheart gibi: "ÖZGÜRLÜK !!!!" ... :-p ...
paercebal

122
Seçiminiz: birden çok iade veya daha fazla iç içe ifadeler. Birden fazla geri dönüş alacağım.
Lance Fisher

333

ters girinti. Örneğin:

    for(int i = 0; i < 10; i++)
        {
myFunc();
        }

ve:

    if(something)
        {
// do A
        }
    else
        {
// do B
    }

152
Aman tanrım ... Bunu ortaya çıkaran sosyopat ile tanışabilir miyim? Bana yanlışlık hakkında bir iki şey öğretebilirdi.
John Rudy

23
Bu muhtemelen doğru olamaz.
Dane

191
Girintiyi her tersine çevirdiğinizde, Tanrı bir bakım geliştiricisini öldürür.
Chris Vest

14
Aman Tanrım, dalga mı geçiyorsun?
Andrea Ambu

21
değerli bayt tasarruf ... paha biçilmez, çok kullanın
Spikolynn

326

Belki alacağınız en tuhaf değil, ama 'tbl' ile veritabanı tablo adlarını önceden yazmak zorunda kaldığımda gerçekten nefret ediyorum


5
DB'ler için sadece Macarca gösterim değil mi?
ARKBAN

19
Değişkenlerin var önekine sahip olması gibi değil mi?
Brian R. Bondy

26
Benzer bir şekilde, veritabanlarındaki kimlik sütunları tablo adının önüne eklenirken nefret ediyorum, örneğin ürün tablosunda bir ürün kimliği sütunu olurdu. Bazen ORM olmadan senaryoyu olması gerekenden daha fazla baş ağrısına dönüşen fazlalık
Andrew Ingram

30
Aslında ID sütununun tablo adıyla önek olmasını tercih ederim. Yazma sorgularını biraz kolaylaştırır. Ve yabancı anahtarlar için yabancı anahtar alanı anahtar alanı ile aynı olabilir.
Craig

38
Benzer bir notta, tablo isimlerinin tekil olması gerektiğinden nefret ediyorum. İçgüdüm, "Müşteri" değil, "Müşteri" değil, müşterileri tutan bir tabloya isim vermektir. Eğer "[İşlem]" yerine "İşlemler" olarak isimlendirebilseydiniz, kurtaracağınız tüm sıkıntıyı anlayana kadar küçük geliyor.
Atario

248

Hemen hemen her türlü Macar notasyonu.

Macarca gösterimle ilgili sorun, çok sık yanlış anlaşılmasıdır. Orijinal fikir, değişkenin önüne anlam koymak ve anlamın net olmasıydı. Örneğin:

int appCount = 0; // Number of apples.
int pearCount = 0; // Number of pears.

Ancak çoğu insan türü belirlemek için kullanır.

int iAppleCount = 0; // Number of apples.
int iPearCount = 0;  // Number of pears.

Bu kafa karıştırıcıdır, çünkü her iki sayı da tamsayı olmasına rağmen, herkes bilir, elmaları armutla karşılaştıramazsınız.


71
Nasıl bu Joel Yazılım yayınına bakın doğru hataları azaltmaya yardımcı olabilir Macar notasyonu kullanımı: joelonsoftware.com/articles/Wrong.html
flicken

9
Tabii ki C yerine C ++ kullanarak kod yazabilirsiniz böylece derleyici elma armut karşılaştırırken bir hata verir.
Andreas Magnusson

5
Evet, Joel doğru anladı. Keşke derleyiciler Joel'in versiyonunu zorlamak için yapılabilseydi.
Loren Pechtel

9
"İnt cntApples = 0; int cntPeas = 0;" olmamalı mı? Yani. Önek "kind" değişkenidir.
Blorgbeard

42
En azından birincisi doğrudur ... İçinde "Apple" olan her şeyin "i" ile ön ekine sahip olması gerekir. ;)
Johannes Charra

240

Şu anda çalıştığım yerde üçlü bir operatöre izin verilmiyor:

int value = (a < b) ? a : b;

... çünkü herkes "anlayamaz". Bana "Yapmayın çünkü yapılar çok karmaşık hale geldiğinde onları yeniden yazmak zorunda kaldık" demeyin (iç içe üçlü operatörler, kimse?), O zaman anlıyorum. Ama bana bazı geliştiricilerin onları anlamadığını söylediğinde ... um ... Tabii.


235
Herkes tarafından patronunuz kendini ifade eder.
Brian R. Bondy

13
Eskiden bu kampa girerdim ... Ama ondan büyüdüm ve şartlı operatörü sevmeyi öğrendim (uygun olduğunda).
John Rudy

22
Bir şey varsa, kural "her zaman üçlü operatörü kullan", saf güzellik operatörü olmalıdır :)
Bobby Jack

16
Onu seviyorum, ancak en sık kullanmamanın nedeni, "insanlar bunu anlamayacak" deneyiminizle aynı. Benim
iddiam

7
Tamamen yeni bir işlev yazmadan sabit bir değişkeni başka bir şekilde nasıl başlatırsınız (bu, okunabilirlik için pek iyi olmaz). Yerel "değişkenler" için const kullanımı, kodu anlamak ve izlemek için üçlü operatörün yasaklanmasından çok daha iyidir.
Andreas Magnusson

239

Değişiklik yaparken ASLA hiçbir kodu kaldırmayın. Tüm değişiklikleri yorumlamamız istendi. Kaynak kontrolü kullandığımızı unutmayın. Bu politika uzun sürmedi çünkü geliştiriciler bu konuda ve kodun nasıl okunamaz hale geleceğiyle ilgili bir karışıklık yaşıyorlardı.


3
Gerçekten bundan nefret ediyorum ... burada bunu yapan birkaç kişi var (standart ya da başka bir şey değil)
chills42

7
Bunun gibi kurallar ben başkalarından miras olarak kaynak kod yazdırmak için bir GEREK hissediyorum bu yüzden renkli. Bir kuruşta, bu benim şirketim için çok hoş değil - ama yazdırmam gerekirse okuyabilmemin tek yolu bu. (Bu kurala uyan çok şey miras aldık ...)
John Rudy

3
Bir kural gibi ön kaynak kontrolü geliştirdi. Ya da sadece haftada bir kez kontrol eden programcılar nedeniyle.
Craig

6
Bu cevapları okumayı seviyorum çünkü işimi 100 kat daha iyi gösteriyor.
rjh

2
Sizi hissedin ... 4 yıldan fazla bir süredir SVN'deyiz, ancak üst düzey geliştirici bundan nefret ediyor ve yaklaşık iki ayda bir kontrol ediyor, sonraki üç günü kırık kod hakkında şikayet ederek geçiriyor: /
Viktor Svub

204

Bir zamanlar Mighty VB Kralı'nın zulmü altında çalıştım .

VB Kral MS Excel ve VBA yanı sıra veri tabanlarının (saf ustası geliştiriciler derleyici ile çalıştı ederken Excel ile oynadı ve veritabanları onu zorlu kariyeriniz üzerinde zararlı etkileri olabilir ...: Dolayısıyla onun soyadını ).

Tabii ki, muazzam becerileri ona benzersiz bir geliştirme sorunları ve proje yönetimi çözümleri vizyonu verdi : Standartları en katı anlamda kodlamasa da, VB King düzenli olarak denediği "kodlama standartları" ve "en iyi uygulamalar" hakkında yeni fikirlere sahipti (ve çoğu zaman başarılı oldu) bize empoze etmeyi. Örneğin:

  • Tüm C / C ++ dizileri 0 yerine indeks 1'de başlayacaktır. Gerçekten de, bir dizinin ilk dizini olarak 0 kullanımı geçersizdir ve Visual Basic 6'nın içgörülü dizi dizin yönetimi tarafından geçersiz kılınmıştır.

  • Tüm işlevler bir hata kodu döndürmelidir: VB6'da istisna yoktur, neden bunlara ihtiyacımız olsun ki? ( yani C ++ ile )

  • "Tüm işlevler bir hata kodu döndürmelidir" anlamlı türler döndüren işlevler için pratik olmadığından, tüm işlevlerin ilk [giriş / çıkış] parametresi olarak bir hata kodu olmalıdır.

  • Tüm kodlarımız hata kodlarını kontrol edecek ( bu benim kariyerimde gördüğüm en kötü VBScript iflasına yol açtı ... Tabii ki, "else" cümleleri asla ele alınmadığı için, çok geç olana kadar hiçbir hata bulunmadı ).

  • Bu güne başlayarak C ++ / COM ile çalıştığımız için, tüm DOM yardımcı program fonksiyonlarımızı Visual Basic'te kodlayacağız.

  • ASP 115 hataları kötüdür. Bu nedenle, bunları önlemek için VBScript / ASP kodumuzda On Error Resume Next'i kullanacağız.

  • XSL-T nesneye yönelik bir dildir. Sorunlarınızı çözmek için kalıtım kullanın ( aptal sürpriz neredeyse bir gün çenemi kırdı ).

  • İstisnalar kullanılmaz ve bu nedenle kaldırılmalıdır. Bu nedenle, istisna gevşemesi durumunda yıkıcı çağrısı isteyen onay kutusunun işaretini kaldıracağız ( bir uzmanın tüm bu hafıza sızıntılarının nedenini bulması günler aldı ve isteyerek göz ardı ettiklerini öğrendiğinde neredeyse çılgına döndü (ve gizli) seçeneği tekrar kontrol etmekle ilgili teknik notu, haftalar önce bir avuç gönderdi ).

  • COM modüllerimizin COM arayüzündeki tüm istisnaları yakalayın ve sessizce atın ( bu şekilde, çökmek yerine, bir modül sadece daha hızlı görünecektir ... Parlak! ... Yukarıda açıklanan über hata işlemeyi kullandığımız için, gerçekte ne olduğunu anlamak biraz zamanımızı aldı ... Hem hız hem de doğru sonuçlara sahip olamazsınız, değil mi? ).

  • Bugünden itibaren kod tabanımız dört şubeye ayrılacak. Senkronizasyonlarını yöneteceğiz ve tüm hata düzeltmelerini / evrimlerini elle entegre edeceğiz.

Tüm ancak C / C ++ diziler , VB DOM fayda fonksiyonları ve cepten dili olarak XSL-T bizim protestolarına rağmen uygulanmıştır. Tabii ki, zamanla, bazıları keşfedildi, ahem , kırıldı ve tamamen terk edildi.

Tabii ki, VB King güvenilirliği asla bunun için acı çekmedi: Yüksek yönetim arasında "en iyi silah" teknik uzmanı olarak kaldı ...

Bu, bağlantıyı takip ederek görebileceğiniz gibi bazı eğlenceli yan etkiler üretti. Şimdiye kadar karşılaştığınız kaynak kodundaki en iyi yorum nedir?


28
Re: 1 indeksleme. Bazen ayağa kalkıp "aptalca ve yanlış" gibi güçlü bir şey söylemeniz gerekir. Kuma bir çizgi çizin. Egoları yatıştırmayı unutun ve söyleyin. Neredeyse her değerli programcının hemen başını
sallamaya

31
@jrista: Metnimin yazımını yorumlamıyorsanız, lütfen aşağıdakileri göz ardı edin ... ... ... ... ... ... ... ... Metnimi yorumluyorsanız, lütfen (1) düzeltmeler önermek, (2) yazımı kendiniz düzeltmek veya (3) dünyadaki her geliştiricinin (ondan uzak) anadili İngilizce olmadığını düşünün, bu yüzden yanlış yazımlara tolerans göstermenin yapabileceğiniz minimum olduğunu düşünüyorum, or FRENCH IN doğru çeviri göndererek daha iyi yapabileceğinizi kanıtlayın ... ^ _ ^ ...
paercebal

4
Bu adam benim patronum olsaydı, iyi yazılmış ve belgelenmiş bir şikayet listesi ile doğrudan üst yönetimin her üyesine giderdim ve kovuldum. Topların kendinize karşı durmaması için -1.
muusbolla

34
@muusbolla: Şikayet etmediğimizi kim söyledi? İki heyet (ben dahil) sorunu açıklamak için doğrudan CEO'ya gidene kadar tırmandı. Ama size adaletin hüküm sürdüğü idealist bir dünya ile bazı patronların “yönetimin asla yanlış olduğu zaman bile yönetimin yanlış olduğuna” inandığı gerçek dünya arasında bir fark olduğunu söylemek zorunda olduğum için üzgünüm. bu dogmaya karşı çıkmaya cesaret edecek. O zamandan beri sahip olduğum tek mutlu hatıra, neredeyse üç yıl önce istifa ettiğim gün ve o günden beri daha mutlu bir adamım. Her neyse, eğer doğruysa, downmod nedeniniz topal. Afedersiniz.
paercebal

7
@paercebal: En générale, c'est düzeltme écrit, sauf que quelques petits erreurs: «squatch»: ça doit être «squash»; «Bu bir gün»: en ce bağlam-là, dirait «o gün»; «Stoklanmış prosedürler»: «stok prosedürleri»; «Takoz» s'écrit «kısık». Aussi, dans les yorumcuları, vous utilisez ° bahsedildi », ce qui doit être« bahsetti »Mais vraiment, tout ça ne justifie pas une telle plainte. Au contraire, vous y montrez une excellente maîtrise de l'anglais; félicitations!
2010'da

131

80'lerde / 90'larda FORTRAN kullanan bir uçak simülatörü şirketinde çalıştım. FORTRAN derleyicimizin değişken adları için 8 karakter sınırı vardı. Şirketin kodlama standartları ilk üçünü Macar notasyonu stil bilgisi için ayırdı. Bu yüzden sadece 5 karakterle anlamlı değişken isimleri yaratmaya çalıştık!


17
Lüks: sadece 6 karakterimiz vardı; paketin g ile başlayan isimleri vardı; iç fonksiyonların tümü başladı gk; Fortran adının geri kalanı için bize iki karakter bırakarak, 0p gibi kodlara sahip iş istasyonu sürücüleri vardı (bu yüzden gk0p başlangıçtı). gk0paa, gk0pab, ...
Jonathan Leffler

103
"Ben senin yaşındayken, sadece 2 karakterimiz vardı! Ve büyük / küçük harfe duyarsızdı!"
pookleblinky

53
Sabah yatmadan 3 saat önce sabah 2'de kalkmamız, sonra kendi derleyicimizi yazmamız ve işe gitme ayrıcalığı için şirkete ödeme yapmamız gerekiyordu. Değişken isimlerimiz için sadece A harfine izin verildi. Sonra patronumuz kodumuzu siler ve şükürler şarkı söyleyen danslarımızda dans ederdi.
David Arno

12
"50 olası tanımlayıcı herkes için yeterli olmalıdır": p
Chris Vest

5
Heck, uzun zaman önce birlikte çalıştığımız BASIC tercümanların iki karakterli değişken isimleri vardı. Neden 5 şikayetçi?
David Thornley

107

İki şirket arasında birleşme olan bir yerde çalıştım. 'Baskın' olanın K&R C (yani ANSI öncesi) ile yazılmış büyük bir sunucusu vardı. Java ekiplerini (her iki ofisden de - muhtemelen toplamda 20 devs) bu formatı kullanmaya zorladılar.

if ( x == y ) 
    {
    System.out.println("this is painful");
    x = 0;
    y++;
    }

18
C ve Java arasındaki görsel ayrımı sürdürmenin geçişleri kolaylaştıracağını düşünürdüm. (1 için "ve çılgın düz gider.")
Jeffrey L Whitledge

4
Petzold - go figürü tarafından orijinal 'Programlama Pencerelerinde' kullanılan Whitesmiths stiline benziyor! ;)
Bobby Jack

7
Bunu en akıllı ayraç tarzı buluyorum. Ne yazık ki, çoğu insan bunu kullanmaz. Diş telleri semantik anlamı varsa, bir satırın sonuna yapışıp göz ardı edilmemelidir.
Ryan Lundy

7
@Kyralessa. Kabul etmiyorum ... Parantezlerin semantik anlamı olup olmadığını bilmiyorum, ancak desen eşleştirmesini ve boşluk hissini kesinlikle etkileyebilirler. IMO, bu sürüm tamamen kaybeder. Örneğin, yer işaretimin kitabın dışına çıkmasını istiyorum, sayfalarla aynı hizada olmamak.
Michael Easter

6
Bu aslında benim tercih ettiğim tarz, ancak dünyadaki her şey (özellikle Visual Studio) varsayılan olarak diğer modlara ayarlandı, bu yüzden vazgeçtim. Neden beğendim? Parantez vardır içerdiği kod "parçası" - onlar için tek bir deyimi "gibi bir görünüm" zorlamak, eğer beklediği budur.
Atario

104

Yasak:

while (true) {

İzin:

for (;;) {

4
Diğerleri for (;;) {bunun bir C Deyim olduğunu iddia ettiler .
Robert P

69
Modern, yeni suratlı suratları doğru anlarsam, bu standart yoksulları, ifadeyi ağlamak için çok fazla çalıştırıyor!
Ben Blank

15
Bu fiili bir kuraldır. VC6, derleyici hakkında while (true) uyarısı verir, ancak (;;) hakkında değil. Aksi takdirde denktirler. Bu yüzden uyarısız olanı seçiyoruz.
user9876

22
Bjarne S. kitabında "(;;) sonsuza kadar okunmalı" dedi. C ++ 'ın yaratıcısı için yeterince iyiyse, sizin için yeterince iyi olmalıdır. :-)
Frank Krueger

58
Çalıştığım ilk C programında, birisi #define (;;) ekledi, böylece "sonsuza kadar {...}" diyebilirsiniz
James Curran

101

bir arkadaşım - ona CodeMonkey diyeceğiz - ilk işini üniversiteden çıkardı [ birçok yıllar önce] COBOL içi geliştirme yapıyor. İlk programı 'standartlarımıza uymama' olarak reddedildi çünkü ... [titreme!]

kodlama standartları iç içe IF ifadelerinin kullanımını yasakladı

Şimdi, CodeMonkey utangaç değildi ve yeteneklerinden emindi, bu yüzden herkese zincirin üstünde ve koridorda bu kuralın neden var olduğunu sormaya devam etti. Çoğu bilmediklerini iddia etti, bazıları 'okunabilirlik' hakkında bir şeyler yaptı ve sonunda bir kişi orijinal nedeni hatırladı: kullandıkları COBOL derleyicisinin ilk sürümünde bir hata vardı ve iç içe IF ifadelerini doğru şekilde işlemedi.

Bu derleyici hatası, elbette, en az on yıldır düzeltildi, ancak hiç kimse standartlara meydan okumamıştı . [baaa!]

CodeMonkey standartların değiştirilmesinde başarılı oldu - sonunda!


7
Steven, bu bana maymun deney hikayesini hatırlatıyor: o) freekvermeulen.blogspot.com/2008/08/…
Nick Dandoulakis

5
@ [Nick D]: evet, ben de - kod adı "CodeMonkey" ;-)
Steven A. Lowe


Nedeni yanlış olabilir, ancak iç içe geçmekten
manojlds

97

Bir zamanlar alt çizgilerin yasaklandığı bir proje üzerinde çalıştı. Demek istediğim tamamen yasaklandı. Bu yüzden ac # winforms uygulamasında, yeni bir olay işleyici (örneğin bir düğme için) eklediğimizde, buttonName_Click () 'den varsayılan yöntem adını başka bir şeye yeniden adlandırmamız gerekir, sadece kodlamayı yazan adamın egosunu tatmin etmek için standartları. Bu güne kadar alçakgönüllü alt çizgilere karşı ne olduğunu bilmiyorum


23
Belki _ klavyesinde kırıldı;)
Roman Plášil

139
buttonNameUnderscoreClick ()
vitule

9
Hata ayıklama için FILE ve LINE kullanımını önlemenin talihsiz yan etkisi vardır . Ve başlık dosyalarında #if __cplusplus extern "C". Ve stdint.h'deki integral türleri. Ve size_t.
Steve Jessop

8
İyi bir şey bu oldu C # then
configurator


92

Tamamen yararsız veritabanı adlandırma kuralları. Her tablo adının bir sayı ile başlaması gerekir. Sayılar tabloda hangi tür verilerin bulunduğunu gösterir.

  • 0: her yerde kullanılan veriler
  • 1: yalnızca belirli bir modül tarafından kullanılan veriler
  • 2: arama tablosu
  • 3: takvim, sohbet ve posta
  • 4: günlüğe kaydetme

Bu, yalnızca adının ilk harfini biliyorsanız bir tablo bulmayı zorlaştırır. Ayrıca - bu bir mssql veritabanı olduğu için - tablenames'i her yerde köşeli parantez içine almamız gerekiyor.

-- doesn't work
select * from 0examples;

-- does work
select * from [0examples];

65
Üzgünüm, çok üzgünüm ...
Kirk Strauser

1
Vay canına - iyi olan. Mektuplar kullanmak söz konusu değildi sanırım? Bu da iyi bir fikir değil, ama en azından tüm tablo adlarını alıntılamak zorunda değilsiniz.
Mark Brittingham

akıl almaz ... bunu kim buldu? dba?
dotjoe

90

Bir C ++ projesi yapıyorduk ve takım lideri Pascal'dı.

Bu yüzden tüm bu sinir bozucu C ve C ++ sözdizimini yeniden tanımlamak için bir kodlama standardı dosyası vardı:

#define BEGIN {
#define END }

ama bekle daha var!

#define ENDIF }
#define CASE switch

Bunca zaman sonra hatırlamak zor.

Bu, mükemmel bir şekilde okunabilen C ++ kodunu aldı ve takım lideri hariç herkes için okunaksız hale getirdi.

Ayrıca ters Macarca gösterim kullanmak zorunda kaldık, yani

MyClass *class_pt  // pt = pointer to type

UINT32 maxHops_u   // u = uint32

garip bir şekilde buna rağmen büyüdüm.


22
Gelecek için sürdürülemez kod oluşturma
rshimoda

2
Doğru şekilde yapılan Macarca gösterim doğru. Yanlış yapıldı ... Uygun tipte bir sistem her ikisini de yener.
Thelema

5
Biliyor musun, bence seninleyim. Macar siğilleri bu şekilde sona erdiğinde neredeyse sakıncalı değil.
TED

haha beni Pascal'dan C ++ 'a (yaklaşık 16 yıl önce) geçtiğim günlere götürüyor. Her gördüğümde {zihinsel olarak kendime "{BEGIN demek" demek zorunda kaldım. En azından benim için sadece kafamdaydı.
thomasrutter

6
MS VC ++ desteğinde çalıştığımda, birkaç müşterinin bu şekilde yazılmış repro kod göndermesini sağladık. Bunun aslında C ++ 'da olduğunu fark etmemiz biraz zaman aldı (#defines içermiyorlardı).
JBRWilkinson

88

Eski bir işte:

  • "Normal" tablolar T_ ile başlar
  • "Sistem" tabloları (genellikle aramalar) TS_ ile başlar (biri o gün böyle hissetmediği için hariç)
  • Çapraz referans tabloları TSX_ ile başlar
  • Tüm alan adları F_ ile başlar

Evet bu doğru. Tüm alanlar, her tabloda. Böylece bunun bir alan olduğunu söyleyebiliriz.


ve birincil anahtar alanlar için özel bir ön ekiniz yoktu ???
Czimi

2
@Czimi: Bundan bahsetmeyi unuttum. Her tablonun birincil anahtar olarak FI_ID adlı bir alanı vardır.
Jeromy Irvine

31
Holy sh ... Bu kabusu icat eden T_guy bir F_gun ile öldürülmeli ve TSX_hell'e gönderilmelidir.
Sergey Skoblikov

3
Tüm alanlar ve tablolar için tbl ve fld vardı. Tamamen yararsız ...
yapılandırıcı

5
@configurator: Tüm alanlar için “tbl” ve tüm tablolar için “fld” kullandınız mı? :-)))
Timwi

84

Bir arkadaşım bir devlet işinde çalışırken bu kuralla karşılaştı. ++ (öncesi veya sonrası) kullanımı tamamen yasaklandı. Nedeni: Farklı derleyiciler bunu farklı yorumlayabilir.


5
Pointţte bu noktada vazgeçebilirsin deđil mi?
Kirk Strauser

90
Bazıları postfix ve önek arasındaki farkı anlamadan ısırıldı, derleyici hatası iddia etti, sonra diğer insanlara verdi, diye düşünüyor.
Bernard

5
Aslında, bazı durumlarda haklıydılar. Banning biraz üst üzerinde görünüyor. Örneğin, şu satırı alalım: a [i] = i ++; i indekslemek için kullanılmadan önce veya sonra artırılabilir. Dil bunu tanımlamıyor.
TED

9
Haklı - ifadenin başka bir yerinde aynı değişkeni kullandığınızda işlem sırası garanti edilmez. Yine de, tüm belirsiz kodları kullanmanın potansiyel olarak belirsiz kodunu yasaklayın!
Loren Pechtel

2
=Tanımlanmamış davranışa neden olmak için kullanılabileceği gibi yasak da olabilir.
yapılandırıcı

81

Takımın yarısı dört boşluklu girinti tercih etti; diğer yarısı iki boşluklu girinti destekliyordu.

Tahmin edebileceğiniz gibi, kodlama standardı "hepsini eşit derecede kırmak" için üç zorunludur (doğrudan bir alıntı).


42
Bu yüzden sekme tanıma çok büyük. Herkes editörünün boyutunu değiştirebilir;)
xardias

41
Evet, sekme girintisi harika ... bir başkasının dosyasını gerçekten açana ve yanlış hizalanmış şeyler bulana kadar boşluklar olmaması gereken yerde karıştığından veya olması gereken yerde karışmadıkça. Sonra otomatik olarak yeniden biçimlendirirsiniz ve sürüm kontrolü farkları çirkinleşir. Ugh.
Alan Hensel

41
bu yüzden girintilemek için sadece sekmeler ve hizalamak için yalnızca boşluklar kullanmanız gerekiyor ve asla ikilinin buluşmayacağı. ve bir dosyadaki boşlukta değişiklik yapacaksanız, söz konusu check-in için yaptığınız tek değişiklik bu olmalıdır.
joh6nn

16
... ve bu asla işe yaramıyor. : P
Robert P

10
"Her şeyi eşit derecede kırmak" ... Bayıldım. Bir dahaki sefere bir girinti standardizasyon savaşına karıştığımda bunu hatırlamak zorunda kalacağım.
Michael Burr

74

Yönetici'nin çok fazla 'büyü' içerdiğini iddia ettiği gibi Yansıma'yı kullanamamak.


10
Evet, büyüyü korumak zor, görünüşte;) LOL olsa.
Rik

19
Muhtemelen bu, yanlış nedenlerden dolayı doğru kural :)
Bobby Jack

71
'sihirli' okuma performansı için sürdürülemez belirsiz kabus kodu öldürmek. O haklı.
gbjbaanb

4
Sanırım .Net'te kod yazmanıza izin verilmedi. Sonuçta, çerçevenin nasıl yürütüldüğünün birçoğu yansımadır.
NotMe

5
Aşağı o büyücüler !! Her zaman sihirleriyle işimizi çalıyor, kadınlarımızı baştan çıkarıyor ve çocuklarımızı yozlaştırıyoruz!
Ocak'ta ZJR

71

Sahip olduğum en garip olanı ve devirmek için biraz zamanımı alan bir şirketimiz yeni ürünümüzün sadece IE olmasını istedi. FireFox üzerinde çalışabiliyorsa, sorun değil, sadece IE olması gerekiyordu.

Küçük bir kusur dışında bu çok garip gelmeyebilir. Tüm yazılım, Linux üzerinde çalışan ısmarlama bir sunucu yazılım paketi içindi ve müşterimizin satın aldığı tüm istemci kutuları Linux'tur. Şarap (o günlerde, çok güvenilmez) almak ve tüm bu kutuları üzerinde çalışan ve IE çalıştıran ve yöneticileri Şarap sorunları nasıl hata ayıklamak için eğitim görüp göremeyeceğimizi anlamaya çalışırken kısa, sadece mümkün değildi sahibinin isteğini karşılamak için. Sorun, Web tasarımını yapması ve Web sitelerinin FireFox ile nasıl uyumlu hale getirileceğini bilmiyor olmasıydı.

Muhtemelen şirketimizin iflas ettiğini bilmek sizi şok etmeyecektir.


1
Diyorum ki, bu oldukça garip.
Brad Gilbert

14
Kapitalizm için üç şerefe!
starblue

46
En uygun olanın hayatta kalması için Yay ... bu adam kendi yazılım işini yönetmeyi hak etmedi.
Mark Brittingham

10
Son cümle harikaydı. Birisi böyle kararlar alırken nasıl ciddiye alınabilir?
Bay Shickadance

54

Genel numaralı tanımlayıcı adlarını kullanma

Şu anki işimde gerçekten anlamlı iki kuralımız var:

Kural 1: Bir veritabanı tablosunda her yeni alan oluşturduğumuzda, ileride kullanmak için ek rezerv alanları eklememiz gerekir. Bu rezerv alanları numaralandırılmıştır (kimse bir gün hangi verileri tutacağını bilmediği için) Bir sonraki yeni alana ihtiyaç duyduğumuzda, önce kullanılmayan bir rezerv alanı ararız.

Böylece customer.reserve_field_14, müşterinin e-posta adresini içeririz.

Bir gün patronumuz yedek masaları tanıtmayı düşündü , ama neyse ki onu yapmamaya ikna edebiliriz.

Kural 2: Ürünlerimizden biri VB6 ile yazılmıştır ve VB6 farklı tanımlayıcı adlarının toplam sayısında bir sınıra sahiptir ve kod çok büyük olduğundan, sürekli olarak bu sınıra giriyoruz. Bir "çözüm" olarak tüm yerel değişken adları numaralandırılır:

  • Lvarlong1
  • Lvarlong2
  • Lvarstr1
  • ...

Bu, tanımlayıcı sınırını etkili bir şekilde atlasa da, bu iki kural birleştirilmiş güzel kodlara yol açar:

...

If Lvarbool1 Then
  Lvarbool2 = True
End If

If Lvarbool2 Or Lvarstr1 <> Lvarstr5 Then
  db.Execute("DELETE FROM customer WHERE " _ 
      & "reserve_field_12 = '" & Lvarstr1 & "'")
End If

...

Eski veya başka birinin kodunu düzeltmenin ne kadar zor olduğunu hayal edebilirsiniz ...

Son güncelleme: Artık özel üyeler için de "rezerv prosedürleri" kullanıyoruz:

Private Sub LSub1(Lvarlong1 As Long, Lvarstr1 As String)
  If Lvarlong1 >= 0 Then 
    Lvarbool1 = LFunc1(Lvarstr1)
  Else
    Lvarbool1 = LFunc6()
  End If
  If Lvarbool1 Then
    LSub4 Lvarstr1
  End If
End Sub

EDIT: Bu kod paterni giderek daha popüler hale geliyor gibi görünüyor. Daha fazla bilgi için günlük WTF yayınına bakın : Astigmatizm :)


10
Şaka yapmıyorum. Bahsetmek sonsuza kadar sürüp tüm bu SQL enjeksiyonlarını kaldırmak için aldı. ;-)
Kirk Strauser

Bu saf kötülük. Eminim patronunuz / TL'niz sadece fırsatını bekleyen bir derebeyi.
Manuel Ferreria

5
Aman tanrım, kim böyle kurallar getirecek ??? en önemlisi: ekibiniz nasıl kodlamayı başarıyor?
hasen

2
Sanırım tüm alanları varsayılan olarak seçeceğiniz anlamına geliyordu, böylece hepsini belirtmeye gerek kalmadan tüm 'rezerv' alanlarını da aldınız.
Bay Shickadance

2
); Eğer '% s / e-posta / reserve_field_12 / g' gibi somegtinh derlemeden önce anlamlı değişkenler adları kullanarak kod yazmak ve ardından "Doğru olanlar" ile değiştirin nerede, preprosessing kodu kullanabilirsiniz maibe
João Portela

53

Benim C ++ günlerde biz ==,> =, <=, &&, vb kullanmak için izin verilmedi. Bunun için makrolar vardı ...

if (bob EQ 7 AND alice LEQ 10)
{
   // blah
}

bu açıkça "koşullu hatadaki eski kazara atama" ile başa çıkmaktı, ancak "sabitleri değişkenlerin önüne koy" kuralı da vardı, bu yüzden

if (NULL EQ ptr); //ok
if (ptr EQ NULL); //not ok

Hatırladım, şimdiye kadar duyduğum en basit kodlama standardı "Bir sonraki bakıcı nerede yaşadığınızı bilen kısır bir psikopatmış gibi kod yaz" idi.


1
rofl .. C.'de yazma fortran
Robert Paulson

i hala null == değişken c #. Endişelenmem gerekmediğini biliyorum, ama kendime yardım edemiyorum. başka türlü görürsem gerginim. eski alışkanlıklar zor bırakılır.
Troy Howard

Psikopatla ilgili sonuncusu, bazı insanları hemen öldürecekti.
Bay Shickadance

31
Kısır psikopat için +1.
rcollyer

Forumlara kod gönderirken, operatörlerin HTML olarak sıkıştırılmasını önlemek için bazen LT ve SHL gibi şeyler kullanacağım.
supercat

45

Genel olarak Macarca gösterim.


11
Bir sayfada kontrol için H / N'yi seviyorum. Aramam gereken tek şey txtFooBar olduğunda IntelliSense açılır listesindeki tüm metin kutusu denetimlerini bulmak çok daha kolay.
cciotti

20
Macar notasyonu değil kötülük, sadece düzgün kullanılması gereken edilir joelonsoftware.com/articles/Wrong.html
Czimi

1
Kontroller konusunda hemfikir olacağım. O zaman Macarca gösterim yararlı olabilir. Genel olarak, Macarca gösterimin eski olduğunu ve genellikle yanlış kullanıldığını düşünüyorum. Orijinal niyetinden uzaklaştı.
vfilby

9
Korkunç bir şekilde yanlış kullanılmış, evet. Yanlış, hayır.
Loren Pechtel

2
Birçok insan bir I bir arayüz adını başlatmak, IEnumerable ılist ... In Net framework arkadaşları arayüzleri bir I. ile başlar
tuinstoel

43

Çok aptalca oldum kurallarým var, ama düpedüz garip saydýđým kadar deđil.

En saçma 90'ların başında çalıştığım bir NASA işindeydi. Bu, üzerinde 100'den fazla geliştirici bulunan büyük bir işti. Kodlama standartlarını yazan deneyimli geliştiriciler, her kaynak dosyanın dört harfli bir kısaltma ile başlaması gerektiğine karar verdiler ve ilk harfin dosyadan sorumlu olan grubu temsil etmesi gerekiyordu. Bu, muhtemelen alıştıkları eski FORTRAN 77 projeleri için harika bir fikirdi.

Ancak, bu güzel bir hiyerarşik kütüphane yapısına sahip bir Ada projesiydi, bu yüzden hiç mantıklı değildi. Her dizin aynı harfle başlayan dosyalarla doluydu, ardından 3 daha saçma izin, alt çizgi ve daha sonra önemli olan dosya adının bir parçası geldi. Tüm Ada paketleri aynı beş karakterli siğil ile başlamak zorundaydı. Ada "use" cümleciklerine de izin verilmiyordu (normal şartlar altında tartışmasız iyi bir şey), bu da bu kaynak dosyada yerel olmayan herhangi bir tanımlayıcıya atıf anlamına geliyordu bu işe yaramaz siğili içermesi gerekiyordu. Muhtemelen bu konuda bir ayaklanma olmalıydı, ancak tüm proje genç programcılar tarafından görevlendirildi ve yeni kolejlerden (kendim ikincisi) taze.

Tipik bir atama ifadesi (Ada'da zaten ayrıntılı), bunun gibi bir şeye bakacaktır:

NABC_The_Package_Name.X := NABC_The_Package_Name.X + 
  CXYZ_Some_Other_Package_Name.Delta_X;

Neyse ki en azından 80'den fazla sütuna izin verecek kadar aydınlandılar! Yine de, tesis siğili, siğilden kurtulmak için Ada "isimlerini" kullanmak için herkesin kaynak dosyalarının üstündeki kaynak plakası haline gelmesinden nefret ediyordu. İçe aktarılan her ("withed") paket için bir yeniden adlandırma olacaktır. Bunun gibi:

package Package_Name renames NABC_Package_Name;
package Some_Other_Package_Name renames CXYZ_Some_Other_Package_Name;
--// Repeated in this vein for an average of 10 lines or so

Aramızda daha yaratıcı olan şey, siğilleri akut olarak mantıklı (veya aptalca) bir paket adı yapmak için kullanmaya çalışmaktı . (Ne düşündüğünü biliyorum, ama açıklayıcılara izin verilmedi ve sana utanmadı! Bu iğrenç). Örneğin, C ommon kod grubundaydım ve W orkstation grubuyla arayüz oluşturmak için bir paket yapmam gerekiyordu . İş İstasyonu çalışanıyla yapılan bir beyin fırtınası seansından sonra, paketlerimizi adlandırmaya karar verdik, böylece her ikisine de ihtiyaç duyan biri yazmak zorunda kalacaktı:

with CANT_Interface_Package;
with WONT_Interface_Package;

1
Tüm bunlar ve NASA hala kilometre veya mil
cinsinden

16
Lanet olsun, ve gerçekten dışarı çıkıp bir CUN * _ ve W * NK_ paket adlandırma kuralı kullanacağınızı düşündüm. Üzgünüm, yavaş yanan, patlayıcı, metinsel turetlerim var. Ama seninki çok daha komikti!
defmeta

41

Bir yerde çalışmaya başladığımda ve kodumu kaynak kontrolüne girmeye başladığımda, patronum birdenbire bana geldi ve böylesine fazla iş yapmayı bırakmamı istedi. Bana, bir geliştirici için günde 1'den fazla taahhütte bulunmanın cesaretini kırdığını söyledi çünkü kaynak kontrolünü hafifletiyor. Sadece ona baktım ...

Daha sonra, bu konuda bana gelmesinin nedeninin SVN sunucusunun birisinin yaptığı her taahhüt için bir posta (ve 10 daha yüksek yönetici) göndermesi gerektiğinden anladım. Kaynak kontrolünü alt ederek posta kutusuna bahsettiğini tahmin ettim.


E-postayı vurgulayın, sil'i tıklayın, bitti
TheLQ

Kesinlikle değilim değil sözde "tıknaz check-in işlemlerinde" hayranı. Değişikliğiniz tamamlandığında taahhüt verin, bu kadar basit. Ayrıca iş gününün sonunda, kodumun derlenebilir olması ve ertesi sabah diğer kodlayıcılar için projenin geri kalanıyla en azından çalıştırılabilir olması gerektiğini aklımda zorladığından emin olmak istiyorum.
Jesse C. Slicer

2
Her iki dünyanın en iyisini elde edin - Bir şey kaybetmek istemediğinizde yerel şubenize bağlı kalın. Efendi haline getirmeye hazır olduğunuzda bu taahhütleri yeniden oluşturun ve ezin. (git terminolojisini affet - eminim ki mercurial ve diğer sistemler de mümkün)
Michael Anderson

Yukarıdakilerin hepsine katılıyorum. Bu, sürüm kontrolüne yaklaşmanın köklü bir problemidir. Teknolojik bir çözümü yok. Yerel bir depoyla çalışmamı ve sonra işleri SVN deposuna aktarmamı sağlayacak git-svn'e taşınmayı düşündüm, ancak bu, büyük bir toplu işte tüm günüm taahhütleri için postaları gönderecekti ve çözülecekti. patronlarım için hiçbir şey.
Avihu Turzion

34

Sql Server 2000'de saklı yordamlar aracılığıyla tüm veritabanı sorgularını yapmak. Karmaşık çok tablolu sorgulardan aşağıdaki gibi basit sorgulara:

select id, name from people

Usulleri destekleyen argümanlar:

  • Verim
  • Güvenlik
  • İdame

Prosedür konusunun oldukça tartışmalı olduğunu biliyorum, bu yüzden cevabımı olumsuz puanlamaktan çekinmeyin;)


2
Tablo ve sütun adları benzersiz değilse, ancak SP adları doğruysa geliştirilebilir. Bu, kod referanslarının bulunmasını kolaylaştırabilir. Başka, daha iyi bakım avantajları varsa, bunların farkında değilim. Güvenlik, SP'leri kullanmanın ana nedenidir.
Jeffrey L Whitledge

2
Genel amaçlar için% 100 wtf olmadığını kabul ediyorum, ancak bu bağlantıya bakın: codinghorror.com/blog/archives/000292.html
azkotoki

2
"Güvenlik, SP'leri kullanmanın ana nedenidir." Hayır. SQL Server'daki SP'ler hakkında hiçbir şey daha güvenli değildir. Yalnızca, dinamik SQL ile de yapılabilen bir paremeterleştirilmiş sorgular olarak adlandırıldığında güvenlidirler.
Flory

4
Hayır: sproks yararlıdır. Zaman zaman bir acı olabilir, ancak daha iyi, daha yeniden kullanılabilir bir veritabanı arayüzü yazıyorsunuz. DBA'larınız ayrıca performans sorunlarını analiz etmek için daha kolay bir zaman alabilir ve uygulama kodu değişikliği olmadan bir üretim sistemini güncelleyebilir. Gerçi sproklarda biz mantığını savunmuyorum.
Robert Paulson

4
derlenmiş kod sorgulama böyle bir acı, ben sadece soyutlama için% 100 sprocs politikasının% 100 arkasındayım
annakata

33

1000 kod satırı başına 165 birim testi (otomatik olması gerekmez) olmalıdır. Bu, yaklaşık her 8 satır için bir testte işe yarar.

Söylemeye gerek yok, bazı kod satırları oldukça uzun ve fonksiyonlar zincirlemeye izin vermek için bu işaretçileri döndürüyor.


Birim testi nasıl otomatikleştirilmez.
pupeno

Sihirli sayı 8'i nasıl buldular?
Rohit

1
164'ünüz varsa ne olur? 166?
Daniel Daranas

8
Daha çok 6 satır gibi.
özyinelemeli

1
Sanırım testlerinizin ne kadar ince taneli olduğuna bağlı. Ben düşünün function(x).should == 2diğerleri birlikte olanların 10 paket ve tek bir test çağırır oysa tek bir test olması.
Orion Edwards

30

Sınıflardaki tüm fonksiyonları "kolay bulunabilmeleri" için alfabetik olarak sıralamamız gerekiyordu. Unutma, IDE'nin bir düşüşü vardı. Bu çok fazla tıklama aldı.

(aynı teknoloji adayı kaynak kodumuzdaki tüm yorumları kaldırmak için bir uygulama yazdı).


3
Tabii ki, çünkü yorumlar sonuçta sadece karmaşıktır ... ve ön işlemcinin derleme zamanında kaç döngü kaydettiğini düşünün! (Uygulama kuraldan bile daha komik. İyi bir.)
ojrac

7
Elbette! Geliştiricilerin kod yazmaları gerekiyor, yorum yazmak için zaman kaybetmeyin :)
Daniel Rikowski

2
Evet! Ve yorumlar yapıyı yavaşlatır!
Greg D

2
Bununla birlikte, üyeleri türe (alanlar, özellikler, yöntemler) ve ada göre sıralamak için iyi bir kural olduğunu düşünüyorum
abatishchev

3
Yöntemleri, üyeleri, vb. Kendi grupları içinde hem başlık hem de kaynak olarak alfabetik olarak sıralıyorum ... ama sadece saplantılı olduğum için.
Jon Purdy

29

1987'de beni işe alan bir şirkette işe başladım çünkü Vahiy'i nasıl kullanacağını bilen küçük bir avuç insandan biriydim. Vahiy, daha önce hiç duymadıysanız, esasen Pick işletim sisteminin PC tabanlı bir uygulamasıydı - daha önce hiç duymadıysanız, adını muhteşem bir şekilde adlandırılan Dick Pick olan mucidinden aldı. Pick OS hakkında çok şey söylenebilir, çoğu iyi. Bazı süper satıcılar (en azından Prime ve MIPS) Pick'ı veya kendi özel uygulamalarını kullandı.

Bu şirket bir Prime shop'du ve şirket içi sistemleri için Information kullandılar. (Hayır, bu gerçekten onun adıydı: Prime'ın Pick uygulamasıydı.) PC tabanlı bir sistem kurmak için devletle bir sözleşmesi vardı ve tüm işi yapmadan önce Vahiy projelerine yaklaşık bir yıl sürmüşlerdi, aynı zamanda MIS direktörü olan ve artık her iki işi de yapmayacağına karar verdi ve beni işe aldı.

Her halükarda, Prime tabanlı yazılımları için birçoğu iki temel koşuldan türetilen bir dizi kodlama standardı oluşturdu: 1) 80 sütunlu aptal terminallerin kullanımı ve 2) Prime'ın Görsel bir editörü yok, kendi yazarını yazmıştı. Pick kodunun sihirli taşınabilirliği nedeniyle, editörünü Vahiy'e indirdi ve tüm projeyi kullanarak PC'ye inşa etti.

Vahiy, elbette, PC tabanlı olmak, mükemmel bir tam ekran editörüne sahipti ve 80. sütunu geçtiğinizde itiraz etmedi. Ancak, ilk birkaç ay boyunca oradaydım, editörünü kullanmamda ısrar etti ve onun standartları.

İlk standart, her kod satırının yorumlanması gerektiğiydi. Her hat. İstisna yok. Bunun mantığı, yorumunuz tam olarak kodda yazdıklarınızı söylemiş olsa bile, yorum yapmak zorunda kalmanız, en azından iki kez çizgi hakkında düşündüğünüz anlamına geliyordu. Ayrıca, neşeyle işaret ettiği gibi, editöre her bir kod satırını biçimlendiren bir komut ekledi, böylece bir satır sonu yorumu ekleyebilirsiniz.

Oh evet. Her kod satırını yorumladığınızda, satır sonu yorumlarıyla oldu. Kısacası, her satırın ilk 64 karakteri kod içindi, sonra noktalı virgül vardı ve sonra 64 karakterinizin ne yaptığını açıklamak için 15 karakteriniz vardı. Kısacası, Pick / Basic kodumuzu biçimlendirmek için bir montaj dili kuralı kullanıyorduk. Bu, şöyle görünen şeylere yol açtı:

EVENT.LIST[DATE.INDEX][-1] = _         ;ADD THE MOST RECENT EVENT
   EVENTS[LEN(EVENTS)]                 ;TO THE END OF EVENT LIST

(Aslında, 20 yıl sonra nihayet R / Basic'in satır devam sözdizimini unuttum, bu yüzden farklı görünebilirdi. Ama fikri anladınız.)

Ayrıca, çok satırlı yorumlar eklemek zorunda kaldığınızda, kural bir çiçek kutusu kullanmanızdı:

************************************************************************
**  IN CASE YOU NEVER HEARD OF ONE, OR COULDN'T GUESS FROM ITS NAME,  **
**  THIS IS A FLOWER BOX.                                             **
************************************************************************

Evet, her bir satırda yıldız işaretleri olması gerekiyordu. Sonuçta, editörünü kullandıysanız, bir çiçek kutusu eklemek sadece basit bir editör komutuydu.

Revelation'ın yerleşik editörünü kullanmamı ve onu bırakmama izin vermek oldukça savaştı. İlk başta ısrarlıydı, çünkü bunlar sadece kurallardı. A) Vahiy editörünü zaten biliyordum b) editöründen önemli ölçüde daha işlevsel olduğunu, c) diğer Vahiy geliştiricilerinin aynı bakış açısına sahip olacağını, editöründe eğitim almazsam yapamayacağımı söyledi. ikimizin de bildiği gibi, cehennem donmadan kaldığı sürece gerçekleşmeyecek olan Prime kod tabanı üzerinde çalışabildik. Sonunda teslim oldu.

Ancak kodlama standartları en sonuncuydu. Özellikle çiçek kutusu yorumları aptalca bir zaman kaybıydı ve bana diş ve çivi ile savaştı, eğer sadece onları korumak için doğru editörü kullanırsam çok kolay olacağını söyledi. (Her şey oldukça pasif agresif oldu.) Sonunda sessizce verdi ve o zamandan beri kod kodlarına getirdiğim tüm kodlardan değerli çiçek kutusu yorumları vardı.

Bir gün, birkaç ay işe başladım, kendimi yetkinliğimden çok daha fazla kanıtladığımda (özellikle orada çalışırken o ofisten geçen diğer kodlayıcıların olağanüstü geçit törenine kıyasla), çalıştı ve çiçek kutusu yorumları kullanmadığımı fark etti. Oh, dedim, çıktılarımı yazdığımda yorumlarımı tarzınıza dönüştüren bir kaynak kodu formatlayıcı yazdım. Onları editörde tutmaktan daha kolaydır. Ağzını açtı, bir an düşündü, kapattı, gitti, ve bir daha asla kodlama standartlarından bahsetmedik. Bundan sonra her iki işimiz de kolaylaştı.


14
Yazdırırken yorum biçimlendirici için +1
BradC

1
Çiçek kutusu ASLA aşırı kullanılmamalıdır. Ben kod boyunca okurken nefret ediyorum, tamam güzel yorum, sonra "BU BU VE BU VE BU YAPAR" çığlık bir çiçek kutusu görmek
TheLQ

26

İlk işimde, ne kadar basit veya karmaşık olursa olsun, tüm C programlarının sadece dört işlevi vardı. Sırasıyla diğer üç işlevi çağıran ana sisteme sahiptiniz. İsimlerini hatırlayamıyorum, ancak başlangıç ​​(), orta () ve bitiş () çizgileri boyunca bir şeydi. begin () açılmış dosya ve veritabanı bağlantıları, end () onları kapattı ve middle () her şeyi yaptı . Söylemeye gerek yok, middle () çok uzun bir işlevdi.

Ve sadece işleri daha da iyi hale getirmek için tüm değişkenlerin küresel olması gerekiyordu.

Bu işin en gururlu anılarımdan biri, bu standartların yok olmasına yol açan genel isyanın bir parçası olması.


2
Bir toplantı odasında kağıt üzerinde sanırım iyi geliyordu, ama onu takip etmek zorunda programcı yazık
TheLQ

Bir İngilizce öğretmeni tarafından tasarlanmış olmalı.
yodie

Bir COBOL programcısı tarafından tasarlanmış olmalıdır.
bruno

Çok fazla kullanılmış olmalı goto.
yeni123456

26

'Yerleşik operatör önceliğine güvenmeyin, her zaman parantez kullanın' kuralına sahip harici olarak yazılmış bir C kodlama standardı

Yeterince adil, bariz niyet yasaklamaktı:

a = 3 + 6 * 2;

lehine:

a = 3 + (6 * 2);

Şey, bu '=', '==', 'C sözdizimi kurallarına uyan bir araç tarafından zorlandı. ve dizi erişimi operatörlerdir. Yani kodu şöyle:

a[i].x += b[i].y + d - 7;

şöyle yazılmak zorundaydı:

((a[i]).x) += (((b[i]).y + d) - 7);

2
belki (((a) [(i)]). x) + = (((((b) [(i)]). y) + (d)) - (7)); ?
Behrooz
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.