Kodumu minimum süre incelemesi için nasıl belgeleyebilirim? [kapalı]


22

Kodumu belgelemek istiyorum, aylar sonra tekrar kodu okumak ve taramak için minimum gereksinim olacak.

Farklı dokümantasyon türleri olduğunu biliyorum (kaynak kodunda ve dışında, sıra diyagramları vb.).

Kodumu belgelemenin ne kadar etkili bir yol olduğunu bilmek istiyorum, böylece birkaç ay sonra kodumu görmek istediğimde, kodu okumak ve kod akışını anlamak için daha az zaman harcıyorum.


42
Daha sonra daha az zaman okuma kodu harcamak için en iyi yöntem, daha net ve daha anlaşılır bir kod yazmaktır .
Mael


Belgeler hedefe göre değişir. Geliştiricilere hitap ediyorsanız, koddaki yorumlar oldukça yararlı olacaktır. Analistlere hitap ediyorsanız, genel bakış diyagramları da faydalıdır. Teknoloji meraklısı bir kitleye hitap ediyorsanız, bir kullanım kılavuzu hazırlayın.
Laiv

@Laiv Kendi kodumun geliştiricisi ve belki de diğer geliştiriciler kodunun görünümü.
Hamed_gibago

En büyük şey kodu küçük tutmaktır. Sorun izleme sisteminizde bir öğeyi uygulamak için gereken kod büyükse, ekibinizin bu öğeyi nasıl daha fazla parçalayacağını öğrenmesi gerekebilir, böylece incelenen kod miktarı çok fazla olmamalıdır.
Berin Loritsch

Yanıtlar:


16

İtiraf etmeliyim ki diğer cevapların önerdiği bazı şeylerle aynı fikirde değilim, bu yüzden iki kuruş atacağım;

Yorumlar

Belgeler, kodunuzu okuyan yabancılar için son derece yararlıdır. Genellikle birçok şey derhal okunacak ve anlaşılacak kadar ayrıntılı olmayacaktır ve daha sonra ne yaptığınızı açıklamalısınız.

Düzenleme : Yorum bölümündeki tartışma, bir şeyin doğru olduğuna işaret etti - aşırı yorumlama genellikle kötü kod yazarken yapılır .

Çalışmanızın yorumlanması kesin ve asgari düzeyde olmalı, ancak bence kesinlikle mevcut olmalı. Her 15 kod satırı için en az bir yorum. Örneğin, koddaki blokların üstüne, ne yaptığınız hakkında bir satır ekleyin:

def login(username: str, password: str, create_session: bool = True):

    # Filter the user we need from the database
    hash = md5(password)
    users = db.table("users", db_entities.USER)
    results = [x for x in users.query(lambda c: c.get("username") == username and c.get("password_hash") == hash)]


    if len(results) == 0:
        return None, None
    else:
        # Create a login session record in the database.
        if create_session:
            sessions = db.table("sessions", db_entities.SESSION)
            ses = sessions.new()
            ses.set("username", username) \
                .set("expiery", 31536000 + time.time())
            sessions.update(ses)
            return results[0], ses
        else:
            return results[0], None

Neden ve ne yaptığınızı açıklayan çok az yorum , kod boyunca çok faydalıdır. Belirtilen cevaba katılmıyorum

Yorum içeren kodla karşılaşırsam en kötüsüne hazırlanırım: kodun kötü olması ve dürüst olmak gerekirse yorumların da kötü olması muhtemeldir.

Çoğu zaman, incelikle, iyi kod belgelenmiştir. Kötü programcıların "Tamam, benim kodum kötü, daha açık hale getirmek için birkaç cümle ekleyelim" gibi belgelerini gördükleri doğrudur.

Evet, bu oldukça fazla olsa da, temiz kod yazan iyi programcıların aynı zamanda kodlarına geri döndüklerinden ve işlevlerinin neden böyle davranmasını istediklerini veya neden ihtiyaç duyduklarını anlamalarını sağlamak istedikleri de doğru. biraz gereksiz görünen çizgi, vb ...

Evet, bariz şeyleri açıklayan yorumlar, net olmayan yorumlar, "bu kodun belgelenmesi, evet, her neyse", kod kokusu olduğundan emin olmak için bir araya getirilen yorumlar. Kodu okumayı zorlaştırıyor ve rahatsız ediyor. (Aşağıya bir örnek ekleme)

# Logging into Gmail when the module is imported
_client = login()
def get_client():
    global _client
    return _client

Örnek açıklama: "Hiçbir şey yok Sherlock. _client = login()Posta hizmetine giriş yapıyor mu? OMG!"

Daha fazla açıklama: login()Yöntemin login()yukarıdaki örnekteki yöntemle ilişkisi yoktur .

Ama bunu yorum, standartlarına uygun neden 's değil nasıl en açıklamak ve doğru soruları cevaplamak , çok çok ( çok yararlı).

Satır içi yorumlar

Bir şey yapmanız gerekir DEĞİL (ve bunu daha büyük, ben ederim yazabilirsiniz varsa) yapmak, kod aynı çizgide yorumlarınızı yazmaya. Kodunuzu yorumlamanın amacını tamamen özleyen yorumları çok çizgiye özgü kılar.

Örneğin, kötü satır içi yorumlar:

outer = MIMEText(details["message"]) # Constructing a new MIMEText object
outer["To"] = details["to"] # Setting message recipient
outer["From"] = "xAI No-Reply" # Setting message sender
outer["Subject"] = details["subject"] # Setting message subject
outer.preamble = "You will not see this in a MIME-aware mail reader.\n" # I don't know what I'm doing here, I copied this from SO.
msg = outer.as_string() # Getting the string of the message
_client = details["client"] # Assigning the client
_client.sendmail(SENDER, details["to"], msg) # Sending the mail

Bu kodu yorum yapmadan okumak ve anlamak daha kolay olurdu, bu da dağınık ve okunamaz hale getirir.

Bunun yerine, kodunuzun içindeki yorumlar kod üzerindeki blokların üstüne yerleştirilmeli ve kod bloğunu okurken ortaya çıkabilecek önemli soruları yanıtlamalıdır.

# Constructing the email object with the values 
# we received from the parameter of send_mail(details)
outer = MIMEText(details["message"])
outer["To"] = details["to"]
outer["From"] = "xAI No-Reply"
outer["Subject"] = details["subject"]
outer.preamble = "You will not see this in a MIME-aware mail reader.\n"
msg = outer.as_string()

# Sending the mail using the global client (obtained using login())
_client = details["client"]
_client.sendmail(SENDER, details["to"], msg)

Çok daha net, değil mi? Artık, login()işlevi kullanmanız ve send_mail()kullandığınız her şey için parametreleri sağlamanız gerektiğini de biliyorsunuz . Biraz yardımcı olur, ancak bir şey hala eksik.

İşlev dokümantasyonu

Yaygın bir şekilde tartışılmıştır. Her zaman okuyucularınızın, işlevinizin ne olduğunu, neden ve ne yaptığını bilmelerini sağlamalısınız. Bu nasıl yapılır, bu belgelere değil, fonksiyonun dipnotlarına da aittir.

Parametrelerinizin ne olacağını ve belirli bir yöntemle elde edilmelerini / oluşturulmalarını istiyorsanız açık bir şekilde tanımlamalısınız. İşlevin ne döndüreceğini, ne işe yaradığını vb.

Yine, kodumu yazarken bu benim fikrim ve metodoloji. Sadece onlar değil, bunlar hakkındaki diğer cevapları kabul edemediğim şeylerden sadece birkaçı. Tabii ki, sadece yorumlar kodunuzu değil, kodunuzun da kendisini okur. Anlaşılır ve bakımı yapılabilir temiz kod yazın . Kodlama yaparken geleceğin özünü düşün ;-)


5
Verilen bir örneğe katılmıyorum - tek bir büyük fonksiyona çok sayıda yorum yazmak yerine, onu yorum niteliği taşıyan açıklayıcı isimlerle birçok küçük fonksiyondan oluşturmalısınız. Kodun gerçekte ne yaptığını senkronize etme riski olmadan .
kullanici11153

6
Sonunda biraz akıl sağlığı. Bir yorumu kullanabilecek her kod parçasını kendi işlevine çıkarmak, yüzlerce dosyaya yayılmış binlerce işlevle nasıl sonuçlanacağınızdır.
user369450

2
İkinci örnek güzel.
Monica

7
İkinci örnekteki yorumlar çok fazla ayrıntılı. Bunlardan bazıları (örneğin, "Bir şey bulduk mu?") Kodun ne dediğini ve daha iyi kaldırılması gerektiğini tekrarlar. Diğer için, yeniden döngüleme yaparak, döngü koşulunu (stream.is_empty ()) yapmak veya accept_literals kontrolünü dışarıda taşımak gibi daha fazla okunabilirlik elde edebilirsiniz.
Frax

3
@cpburnz, "Neler olduğunu ve neden olduğunu açıklayan yorumları takdir etmek için herhangi bir kod yorumu olmadan çok sayıda eski projeyi ve üçüncü taraf kütüphaneleri kazmak zorunda kaldım". baştan beri tam olarak benim açımdan: yorumlar bok kodunu açıklamak için orada. "Okunması kolay bir kod nasıl yazarım" sorusu olduğu için, ilk olarak iyi bir kod yazmak yerine, kötü kodun açıklanması için yorum yazmaya odaklandığından, bu cevap açıkça yanlıştır.
David Arno

55

IMO en iyi dokümantasyon, gerçekten ihtiyacınız olmayan dokümantasyondur. Ayrıca belgeler ve yorumlar yazmaktan nefret ediyorum.

Bununla birlikte:

  • Okunabilir ve konuşan isimleri seçin. Kullanmayın n, numberOfItemsFoundörneğin bunun yerine .
  • Hesaplamanın parçalarını her şeyi bir satıra itmek yerine sabit bir değişkende saklamaktan çekinmeyin.
  • Kısmi görevleri şubelerden kendi (satır içi) işlevlerine taşıyın, eğer onları yeniden kullanıyorsanız veya ana işlev takip etmek uzun ve sıkıcı hale gelir.
  • Daha ayrıntılı olun ve yalnızca gerçekten gerekli olduğunda okunabilirlik üzerine kodu optimize edin.

19
İşte belgeler için iyi bir ölçüm (zorunlu bağlantı).
Neil

4
Bu da listede olmalı: kodunda neden yaptığınız şeyleri yaptığınızı açıklayın .
t3chb0t


4
numberOfItemsFoundolsa da oldukça ayrıntılı; çok ayrıntılı da bir konudur.
Matthieu M.

6
@MatthieuM., Nadiren kod adları ile bir sorun "çok ayrıntılı" dır. Çok özlü veya kriptik olsa da çok yaygın bir sorundur.
David Arno

25

Kodunuzu dokümantasyon olarak kabul edin

Kodunuz birincil belgelerinizdir. Sonuçta ortaya çıkan uygulamanın, kütüphanenin veya her neyin gerçekte ne yaptığını tam olarak açıklar. Bu nedenle, bu kodun anlaşılmasını hızlandıran herhangi bir girişim kodun kendisiyle başlamalıdır.

Okunabilir kodun nasıl yazılacağı hakkında çok sayıda yazı var, ancak bazı önemli noktalar:

  • hatalı kodu açıklamak, kodu daha iyi hale getirmek ve yorumlardan kurtulmak için yorumlara güvenmeyin,
  • Kısa odaklı fonksiyonlar, yöntemler, sınıflar vb. yazar.
  • Bağlama uygun isimler kullanın (örneğin n, bir döngü için iyidir, daha geniş kapsamı olan öğeler için daha uzun tanımlayıcı isimler gerekir),
  • işlev isimlerini yorum yapmış gibi ele al, örneğin, isim olarak kullanılabildiğinde UpdtTbltabloyu verilen kurallarla güncellediğini açıklayan bir yorum ile kullanma UpdateTableContentsWithSuppliedRules,
  • değişkenlikten kaçının. Bir değişkenin içeriğini her değiştirdiğinizde, kodun karmaşıklığını arttırırsınız. Bu yeni değeri, mümkün olduğunda yeni bir değişkene (iyi bir isimle) atayın.
  • son olarak ve en önemlisi "zeki" koddan kaçının. Tek gerçek akıllı kod, okunması kolay koddur. Biraz karmaşık bir kod yazıp kendinizi "vay, burada zekice değil miyim?" Diye düşünürseniz, cevabın "hayır, değilsin" olduğu neredeyse kesindir.

Kod okurken daha iyi ol

Kod okumak, ne kadar basit olursa olsun, öğrenilmiş bir beceridir. Hiç kimse kod okumada doğal olarak iyi değildir. Pratik alır; çok fazla pratik. Örneğin, Github'a veya her neyse gidin ve yalnızca bu kütüphaneleri kullanmak yerine kullandığınız kütüphanelerin kodunu okuyun. Okumak ve okumak için kod bulun.

Yorumlar bir kod kokusu

Ancak o zaman başka tür belgelere ulaşabiliriz. Öncelikle, daha önce belirtildiği gibi yorum yapmaktan kaçının. Yorum içeren kodla karşılaşırsam en kötüsüne hazırlanırım: kodun kötü olması ve dürüst olmak gerekirse yorumların da kötü olması muhtemeldir. Kodla iyi iletişim kuramayan birinin doğal dille daha iyi iletişim kurabilmesi pek mümkün değildir.

Otomatikleştirilmiş API dokümantasyonuna dikkat edin

Ayrıca, otomatikleştirilmiş API belgelerine de dikkat edin. Bu tür belgeleri okumak için başvurmam gerekiyorsa, kodunuzun okunması çok zor olduğu için olur. Yine, kodu basitleştirin ve doğrudan okuyabilirim.

Testler de dokümanlar

Testler de dokümantasyondur. Bu yüzden birim testlerinizi bir angarya olarak kabul etmeyin. Onlara, kodun nasıl çalıştığını ve kullanılmasını amaçlayan olarak başkalarıyla iletişim kurmanın bir yolu olarak (altı ayınız sonra buraya dahil edilir) davranın.

Yardımcı olursa resim çizin

UML'den hoşlanıyorsanız, elbette kendinize iyi bir araç bulun ve kodunuzdan UML diyagramları oluşturun. Sadece hiç bir zaman asla kod üretmek için kullanmaya çalışmayın. Bir tasarım aracı olarak iyi değil ve sonuçta korkunç bir kodla sonuçlanacak.

"1000ft" görünüm belgesine sahip olmak

Son olarak, kendinize bir genel bakış belgesi yazın. Uygulama ne yapar? Bunu nasıl yapıyor? Başka hangi sistemlere bağlanıyor? Bunun gibi şeyler. Burada kod yapısını tarif etmeye çalışmayın. Kod bunu yapsın. Bu belgenin size kodu neden ilk başta yazdığınızı hatırlatmasına izin verin.


14
Yorumlarınızın yeri olması dışında, tüm amacınıza katılıyorum. Ben gibi yorumlarda anlamı yok kabul ederken add 1 to i, yorumlar açıklamalıdır neden kodu ne yaptığını yapıyor. Örneğin, kod if (!something.Exists()) {...}gibi bir yorum kullanabilirsiniz: // something exists only when (explanation of the broader scenario).
Jonathan

16
// increment x x++;Hiçbir yararı olmayan yorum payımızı hepimiz gördük , ancak bebeği banyo suyuyla atmak ve yorumların her zaman kötü olduğunu ilan etmek yanlıştır. Örneğin, formun yorumları // this case should never happen because xyz throw exception "unreachable".
öfkeyle

7
Çok güzel bir liste. Ama @Jonathan gibi. Yorumlara katılmıyorum. Bazen, üçüncü parti çerçevelerindeki hataları hesaba katmanız gerekir. Bu, kendi işlevine göre yeniden yapılandırılabilirken, geçici çözümün (bugunumber veya bugname / hatanın açıklaması) neden gerekli olduğuna dair bir açıklama yapmak yine de güzeldir.
magu_

16
@DavidArno Ama bir şey oldu nedenini açıklayan bir yorum için bunu yapamaz değil yapılır. Gibi //XXX: Not using straight-forward method Foo here because .... Bu tür yorumlar son derece değerli olabilir, ancak bariz nedenlerden dolayı kodla iletmek imkansızdır.
cmaster - monica

7
Daha dramatik olmasını seviyorum: Her yorum, kodunuzu iyi ifade edemediğiniz bir başarısızlık . Örneğin, bir yöntemde 4 satırlık bir yorumum var, 3. parti bir hatanın geçici çözümünü açıklıyorum. Bunu kodda iyi ifade etmedim, bu yüzden bir yorumda bulunuyor . Okunabilirliği zorlaştırdığını söyleyebilirim, çünkü herhangi birinin çok uzun ve çok açıklayıcı bir yöntem adı okumak için yatay kaydırma yapmaktan zevk alacağından şüpheliyim . "Yorumlar bir kod kokusudur" - evet, ama koklayan her şeyin sh * t olmadığını hatırlamamız gerekiyor.
R. Schmitz

5

Bir kapak mektubu sağlayın

Çok teknik bir alanda değilseniz, kodun etrafındaki soruların çoğu 'nasıl' değil, 'neden' veya 'ne' ile ilgili olacaktır.

Bu nedenle, insanların kodunuza bakmalarını önlemenin yolu, bunun kısa bir açıklamasını yazmaktır. Bunun avantajı, tanımlara genel bir bakışı oldukça kolay bir şekilde derleyebilmeniz ve bunun çok daha güvenilir olması. (Kodu görmeyen / almayan kişiler için bile).

İnsanlar teknik olsalar bile, kapak mektubu nerede bir şeyler aramaları gerektiği konusunda rehberlik etmelidir.

Basit son derece minimalist noktalar:

  1. Giriş, bu kod neden var?
  2. Kod altkümesi hangi işlevi yerine getirir?
  3. Kod nerede (örneğin komut dosyası adı)

Örnek

  1. Bu komut dizileri StackOverflow'u sıyırır ve Dennis Jaheruddin tarafından yanıtları artırır.
  2. a. Bu betik, html'nin ayrıştırılmasından sorumludur ve doğru kullanıcı olup olmadığını analiz eder.
  3. a. Betikte bulunur: ScrapeAndVote / RecognizeDennis.scr

1

Genelde, her biri, derleyen ve çalışan bir ara adımı temsil eden ayrı taahhütler oluştururken elde ettiğim en büyük hız kazancı.

Bu nedenle, belirli bir özelliği uygulamak için bir işleve yeni bir parametre eklemek zorunda kalırsam, parametreye bildirimde, tanımda ve tüm arama sitelerinde parametre eklemekten başka bir şey olmaz. Ardından, bir sonraki taahhüt işlevsellik sunar ve üçüncüsü, yeni özelliği kullanan arama sitelerini günceller.

Bunu anlamak kolaydır, çünkü tamamen mekanik değişiklikler hızlı bir şekilde gözden geçirilebilir ve yoldan çekilebilir.

Benzer şekilde, kodu yeniden biçimlendirirseniz, bu her zaman ayrı bir taahhüt olmalıdır.


1

Mevcut cevaplar arasında bir ya da iki belirgin anlaşmazlık noktası olmasına rağmen, sadece vurgu varken, genel tavsiyeyi herkesin nereden geldiğini net bir şekilde özetlemeye çalışacağım:

  1. İlk önce, temiz kod yazın; başka herhangi bir "dokümantasyon" bundan sonra kendiliğinden ilgilenecektir. Temiz kod ilk etapta öğrenilecek ilkeler bütünüdür: tek sorumluluk sınıfları, bir şeyi yapan kısa yöntemler, iyi değişken ve yöntem adları, metaforlara odaklanarak bunlardan daha iyi sınıf / tür adları (örneğin, bir MultiButtSupporter a. soda), gereksinimleri gösteren ünite testleri, KURU, KATI, tutarlı bir paradigma vb.
  2. Kod, kodun nasıl çalıştığını gösterir; Yorumlar, kodun neden çalıştığını açıklar. Örneğin, bir + 1'i "1 hatayla engellemeyi önler" veya "bu ders kitabında veya web sayfasında türetilmiş" olan bazı karmaşık formülü açıklayın.
  3. Yorumlarınızla ne yapıyorsanız yapın, yukarıdaki 1. madde temiz kodda bunu başarabilir. Yorumları başarısızlık / gerekli kötülükler olarak görün, hatta zamanla her ikisi de düzenlendiği gibi kodla senkronize edilmediklerinde bile yalan söyleyin. Yorumlar kötü yazılmış kodları telafi etmemelidir, çünkü yorumlar neden kodlardan daha fazla yetenek veya dikkatle yazılır?

Öte yandan, eğer bir şeyleri muhtemelen diğer tarafa çok errit edersem, neredeyse hiç yorum kullanmıyordum. Kod gözden geçirenleriniz, onlar için dengeyi yanlış bir yere getirdiyseniz size bildirecektir, ancak yukarıdaki 3-nokta planını takip etmek için bilinçli bir çaba gösterirseniz, muhtemelen yine de en uygun olanlarına yakın olacaksınız.


2
"+1 bir yazım hatası değil" veya "Programımdaki bir hatadan nasıl habersiz değilim" diyen bir yorumdan farklı bir "1'i kapalı bırakmayı önle" yorumu nasıl? (Yararlı yorumlar genellikle kaynak kodunda + 1'den büyük bir şeyle veya kaynak kodunun dışında bir şeyle ilgilidir.) Bu da yine de "2. Öyleyse 3 numaralı noktanız herhangi bir yorum yapmadan yeterince temiz kod kullanarak "bu kitapta veya web sayfasında türetilmiş" ifadesini ifade edebileceğinizi gösteriyor; vay canına, onu eylemde görmek isterdim.
Jirka Hanika

@JirkaHanika Belki de birer birer kötü bir örnek oldu. 3 gelince, demek istediğim "belki her" değil, "her olabilir"; bu yüzden hayır, kodun tek başına böyle şeyleri açıklığa kavuşturacağını sanmıyorum. (Pekala, Gaussian'danBuThisTextbookNames'ten değişken adı olarak yaklaşım deneyebilirsiniz, ama bu kötü bir fikir!)
JG
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.