Katkıda bulunanlar için AOSP Java kodu stili

Bu sayfadaki kod stilleri, Android Açık Kaynak Projesi (AOSP). Android platformuna katkılar bu kurallara uymayan içerikler genellikle kabul edilmez. Biz tüm mevcut kodların bu kurallara uymadığını, ancak tüm kodların yeni bir kod snippet'i eklemeniz gerekir. Saygılı bir şekilde kodlama bölümüne bakın. başlıklı video dizimize göz atın.

Tutarlı olun

En basit kurallardan biri TUTARLI OLUN. Kodu düzenliyorsanız birkaç dakikalar içinde kodu inceler ve stilini belirler. Eğer kodu if yan tümcelerini boşluk kullanıyorsa sizin de eklemeniz gerekir. Kod yorumların etrafında küçük kutular varsa yorumlarınıza yıldızlarla dolu olduğunu fark etmişsiniz.

Stil kurallarına sahip olmanın amacı, Böylece okuyucular, kod yazmak yerine söylediklerinize yoğunlaşabilir. ve açıklamanız gerekir. Burada genel stil kurallarını sunuyoruz. Bu kurallar sayesinde, aynı zamanda yerel stil de önemlidir. Eklediğiniz kod etrafındaki mevcut koddan büyük ölçüde farklı görünmesi durumunda okuyanları tekrar dinlemek zorunda kalıyor. Şunları deneyin: bundan kaçının.

Java dil kuralları

Android, standart Java kodlama kurallarına ek olarak bakın.

İstisnaları göz ardı etmeyin

Aşağıdaki gibi istisnaları yok sayan bir kod yazmak cazip gelebilir:

  void setServerPort(String value) {
      try {
          serverPort = Integer.parseInt(value);
      } catch (NumberFormatException e) { }
  }

Bunu yapmayın. Kodunuzun bu sorunla asla karşılaşmayacağını düşünebilirsiniz veya ele alınmasının önemli olmadığını söyleyerek, söz konusu hatanın özel durum, kodunuzda madenler oluşturur. Böylece, bir gün tetikleyebilir. Kodunuzdaki her istisnayı ilkeli bir şekilde çalışır. duruma göre nasıl ele alınması gerektiği de duruma göre değişir.

"Ne zaman boş bir Catch ifadesi olan birileri, hissedebilir. Bir şeyin gerçekten doğru olduğu ancak en azından bunun üzerinde düşünmelisiniz. Java'da bu ürkütücü hisden kaçmam gerekiyor." - Cemal Gosling

Kabul edilebilir alternatifler (tercih sırasına göre) şunlardır:

• İstisnayı, yönteminizin çağırıcısına verin.

    void setServerPort(String value) throws NumberFormatException {
        serverPort = Integer.parseInt(value);
    }

• Soyutlama düzeyinize uygun yeni bir istisna ekleyin.

    void setServerPort(String value) throws ConfigurationException {
      try {
          serverPort = Integer.parseInt(value);
      } catch (NumberFormatException e) {
          throw new ConfigurationException("Port " + value + " is not valid.");
      }
    }

• Hatayı etraflıca ele alın ve catch {} blok.

    /** Set port. If value is not a valid number, 80 is substituted. */
  
    void setServerPort(String value) {
      try {
          serverPort = Integer.parseInt(value);
      } catch (NumberFormatException e) {
          serverPort = 80;  // default port for server
      }
    }

• İstisnayı yakalayın ve yeni bir RuntimeException örneği gönderin. Bu tehlikelidir. O yüzden yalnızca bu eylemde bulunulduğunda hatası oluşursa yapılacak uygun şey kilitlenmedir.

    /** Set port. If value is not a valid number, die. */
  
    void setServerPort(String value) {
      try {
          serverPort = Integer.parseInt(value);
      } catch (NumberFormatException e) {
          throw new RuntimeException("port " + value " is invalid, ", e);
      }
    }

• Son çare olarak, istisnayı göz ardı etmenin daha iyi bir deneyim bunları göz ardı edebilirsiniz ancak iyi bir neden.

  /** If value is not a valid number, original port number is used. */
  
  void setServerPort(String value) {
      try {
          serverPort = Integer.parseInt(value);
      } catch (NumberFormatException e) {
          // Method is documented to just ignore invalid user input.
          // serverPort will just be unchanged.
      }
  }

Genel istisnaları yakalamayın

İstisnaları yakalayıp zaman çizelgesine sadık kalmak için şunun gibi bir şey:

  try {
      someComplicatedIOFunction();        // may throw IOException
      someComplicatedParsingFunction();   // may throw ParsingException
      someComplicatedSecurityFunction();  // may throw SecurityException
      // phew, made it all the way
  } catch (Exception e) {                 // I'll just catch all exceptions
      handleError();                      // with one generic handler!
  }

Bunu yapmayın. Neredeyse her senaryoda genel anahtar kelimeler kullanmak Exception veya Throwable (tercihen Throwable değil) çünkü bir Error istisna). Bu tehlikelidir çünkü istisnai durumlar asla beklemediğiniz (ClassCastException gibi çalışma zamanı istisnaları dahil) Bu durum, uygulama düzeyinde hatalara yakalanabilir. Hatayı kapatır ve özelliklerini işlemesi (ör. biri koda yeni bir tür kod istisna olarak çalışırsanız derleyici, ihtiyacınız olan bir hata olduğunu belirtmiştik. Çoğu durumda farklı tür istisnaları aynı şekilde ele alınmamalıdır.

Bu kuralın nadir istisnası, test kodu ve gösterilmesini engellemek için, her tür hatayı yakalamak bir toplu işin çalışır durumda tutulmasını sağlar). Bu tür durumlarda, genel Exception (veya Throwable) ile ilişkilidir ve hatayı uygun şekilde işler. Ancak bunu yapmadan önce iyi düşünün ve yorumlara yazın güvenli olduğunu açıklayacağım.

Genel istisnaları yakalamaya alternatifler:

• Her istisnayı, bir çoklu yakalama blokunun parçası olarak ayrı ayrı yakalayın. Örneğin:

  try {
      ...
  } catch (ClassNotFoundException | NoSuchMethodException e) {
      ...
  }

• Daha ayrıntılı hata işlemesi için kodunuzu deneme bloğudur. KS'yi ayrıştırmadan ayırın ve hataları işleyin her durum için ayrı ayrı gösterilir.
• İstisnayı yeniden yazın. Çoğu zaman bir sorunu çözmek için bu düzeyde bir istisna olsa da, yöntemin iptal etmesine izin verin.

İstisnaların sizin için önemli olduğunu unutmayın. Derleyici, web sitesi yakalanmamak, pes etmeyin. Gülümseyin! Derleyici tarafından çalıştırıldı kodunuzda çalışma zamanı sorunlarını yakalamanızı kolaylaştırır.

Sonlandırıcıları kullanma

Sonlandırıcılar, bir nesne başarıyla sonlandırıldığında bir kod parçasının yürütülmesinin emin olmanız gerekir. Kesinleştiriciler temizlik için elverişli olsa da (özellikle dış kaynaklarda), projenin ne zaman bir sonlandırıcı çağrılır (hatta çağrılacaktır).

Android, sonleştiricileri kullanmaz. Çoğu durumda, istisnaları yönetebilirsiniz. Bir sonleştiriciye ihtiyacınız varsa bir close() yöntemi (veya benzeri) tanımlayıp tam olarak ne zaman yönteminin çağrılması gerekir (bkz. InputStream) tıklayın. Böyle durumlarda beklenilmediği sürece finalizer'ı kullanabilirsiniz.

Tüm koşulları karşılayan içe aktarmalar

foo paketindeki Bar sınıfını kullanmak istediğinizde iki sınıf vardır: içe aktarmanın olası yolları şunlardır:

• import foo.*;

  İçe aktarma ifadelerinin sayısını potansiyel olarak azaltabilir.

• import foo.Bar;

  Hangi sınıfların kullanıldığını ve kodun daha uygun olduğunu gösterir. okunabilir olması gerekir.

Tüm Android kodlarını içe aktarmak için import foo.Bar; kullanın. Java standart kitaplıkları (java.util.*, java.io.* vb.) ve birim test kodu (junit.framework.*).

Java kitaplığı kuralları

Android'in Java kitaplık ve araçlarını kullanmayla ilgili kurallar vardır. İçinde bazı durumlarda kurallar önemli ölçüde değişmiştir ve eski kod kullanımdan kaldırılan bir kalıp veya kitaplık kullanabilir. Bu tür bir kodla çalışırken mevcut stile devam edebilirsiniz. Yeni bileşenler oluştururken ancak kullanımdan kaldırılmış kitaplıkları asla kullanmayın.

Java stili kuralları

Javadoc standart yorumlarını kullan

Her dosyanın üst kısmında bir telif hakkı bildirimi, paket ve içe aktarma ifadeleri (boş satırla ayrılmış her blok) ve son olarak sınıf veya arayüz bildirimi. Javadoc yorumlarında, sınıfın veya arayüzün ne yaptığını açıklar.

/*
 * Copyright (C) yyyy The Android Open Source Project
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package com.android.internal.foo;

import android.os.Blah;
import android.view.Yada;

import java.sql.ResultSet;
import java.sql.SQLException;

/**
 * Does X and Y and provides an abstraction for Z.
 */

public class Foo {
    ...
}

Yazdığınız her sınıf ve basit olmayan herkese açık yöntem şunları içermelidir: en az bir cümleyle sınıfın neyle ilgili olduğunu açıklayan bir Javadoc yorumu bir yöntem vardır. Bu cümle üçüncü bir kişi ile başlamalıdır betimleyici fiildir.

Örnekler

/** Returns the correctly rounded positive square root of a double value. */

static double sqrt(double a) {
    ...
}

veya

/**
 * Constructs a new String by converting the specified array of
 * bytes using the platform's default character encoding.
 */
public String(byte[] bytes) {
    ...
}

Şu gibi basit alma ve ayarlama yöntemleri için Javadoc yazmanıza gerek yoktur: Javadoc'unuzda "sets Foo" yazarsa setFoo(). Eğer yöntem daha karmaşık bir işlem (ör. bir kısıtlamanın veya önemli bir yan etkisi varsa) belgelemeniz gerekir. Değilse "Foo" özelliğinin ne olduğu çok açık bunu belgelemelisiniz.

Herkese açık olsun ya da olmasın, yazdığınız her yöntem Javadoc'tan faydalanır. Herkese açık yöntemler bir API'nin parçasıdır ve bu nedenle Javadoc gerektirir. Android Javadoc yazmak için belirli bir stili zorunlu kılmaz. Ancak Javadoc Aracı için Doküman Yorumları Yazma'daki talimatları uygulamanız gerekir.

Kısa yöntemler yazın

Mümkün olduğunda yöntemleri kısa ve odaklanmış tutun. Biliyoruz ki, yöntemler bazen uygun olduğundan, yönteme kesin bir sınırlama konmaz. seçeceğiz. Bir yöntem 40 veya daha fazla satırı aşıyorsa bu yöntemlerin bölünmesini istemeyiz.

Standart yerlerde alanları tanımlayın

Dosyanın üst kısmında veya yöntemlerine göz atacağız.

Değişken kapsamını sınırlama

Yerel değişkenlerin kapsamını minimumda tutun. Bu kodunuzun okunabilirliğini ve bakımını artırır ve riskleri kabul eder. En içteki her değişkeni tanımlayın değişkenin tüm kullanımlarını kapsayan blok.

Yerel değişkenleri ilk kullanıldıkları noktada bildirin. Neredeyse her yerel değişken bildirimi bir başlatıcı içermelidir. Bir değişkeni başlatmak için henüz yeterli bilginiz yoksa lütfen, bunu yapana kadar beyanı erteleyin.

Bunun tek istisnası, dene-yakala ifadeleridir. Bir değişken işaretli istisnayı atlayan bir yöntemin döndürülen değeri; deneme bloğunda başlatıldı. Değerin bloğu kullanmayı deneyin, bulunduğunda try bloğundan önce bildirilmelidir. henüz ilk kullanıma hazırlanamıyor:

// Instantiate class cl, which represents some sort of Set

Set s = null;
try {
    s = (Set) cl.newInstance();
} catch(IllegalAccessException e) {
    throw new IllegalArgumentException(cl + " not accessible");
} catch(InstantiationException e) {
    throw new IllegalArgumentException(cl + " not instantiable");
}

// Exercise the set
s.addAll(Arrays.asList(args));

Ancak, deneme yakalamayı test ederek bu durumun önüne geçebilirsiniz. bir yöntemde engelleme:

Set createSet(Class cl) {
    // Instantiate class cl, which represents some sort of Set
    try {
        return (Set) cl.newInstance();
    } catch(IllegalAccessException e) {
        throw new IllegalArgumentException(cl + " not accessible");
    } catch(InstantiationException e) {
        throw new IllegalArgumentException(cl + " not instantiable");
    }
}

...

// Exercise the set
Set s = createSet(cl);
s.addAll(Arrays.asList(args));

Belirli bir durum söz konusu olmadığı sürece for ifadesindeki döngü değişkenlerini Bunun geçerli bir nedeni vardır:

for (int i = 0; i < n; i++) {
    doSomething(i);
}

ve

for (Iterator i = c.iterator(); i.hasNext(); ) {
    doSomethingElse(i.next());
}

Sipariş içe aktarma ifadeleri

İçe aktarma ifadelerinin sırası:

1. Android içe aktarmaları
2. Üçüncü taraflardan içe aktarmalar (com, junit, net, org)
3. java ve javax

IDE ayarlarıyla tam olarak eşleşmesi için içe aktarma işlemleri:

• Her grupta alfabetik olarak, küçükten önce büyük harfle yazılmış büyük/küçük harf kullanımı (örneğin, a'dan önce Z)
• Her ana gruplandırma arasında boş bir satırla ayrılmış olmalıdır (android, com, junit, net, org, java, javax)

Başlangıçta sipariş vermeyle ilgili bir stil şartı yoktu. Yani IDE'ler, ya sıralamayı sürekli değiştiriyorlardı ya da IDE geliştiricilerinin otomatik içe aktarma yönetimi özelliklerini devre dışı bırakıp hazırlanır. Bu durum kötü olarak değerlendirildi. Java stili sorulduğunda stillere göre çeşitlilik gösterdi ve Android'in basitçe "bir sipariş seçin ve tutarlı olun." Bu yüzden bir stil seçtik. stil kılavuzunu güncelledi ve IDE'lerin bu kılavuza uymasını sağladı. Proje yöneticisinin IDE kullanıcıları kod üzerinde çalışır, tüm paketlerdeki içe aktarmalar bununla eşleşir kullanarak kolayca oluşturabilirsiniz.

Bu stili, şu şekilde seçtik:

• Kullanıcıların ilk başta bakmak istediği içe aktarma işlemleri genellikle üstte olur. (android).
• Kullanıcıların bakmak istediği içe aktarma işlemleri en azından alt kısımda yer alır (java).
• İnsanlar bu stili kolayca takip edebilir.
• IDE'ler bu stile uygun olabilir.

Statik içe aktarmaları içe aktarmanızı sağlar.

Girinti için boşluk kullanma

Bloklar ve hiçbir zaman sekmeleri için dört (4) boşluk girintisi kullanırız. Şüpheye düştüğünüzde etrafındaki kodla tutarlı olmasını sağlayın.

Satır sarmalama için, işlev çağrıları dahil sekiz (8) boşluk girintisi kullanırız ve ödevler.

Önerilen

Instrument i =
        someLongExpression(that, wouldNotFit, on, one, line);

Önerilmeyen

Instrument i =
    someLongExpression(that, wouldNotFit, on, one, line);

Alan adlandırma kurallarına uyma

• Herkese açık olmayan, statik olmayan alan adları m ile başlar.
• Statik alan adları s ile başlar.
• Diğer alanlar küçük harfle başlar.
• Statik son alanlar (sabit değerler, tamamen sabit olmayan) ALL_CAPS_WITH_UNDERSCORES şeklindedir.

Örnek:

public class MyClass {
    public static final int SOME_CONSTANT = 42;
    public int publicField;
    private static MyClass sSingleton;
    int mPackagePrivate;
    private int mPrivate;
    protected int mProtected;
}

Standart küme ayracı stilini kullan

Ayraçları kendi satırlarına değil, önlerindeki kodla aynı satıra yerleştirin:

class MyClass {
    int func() {
        if (something) {
            // ...
        } else if (somethingElse) {
            // ...
        } else {
            // ...
        }
    }
}

Koşullu ifadeye ilişkin ifadelerin başına ve sonuna ayraç eklenmesi gerekir. İstisna: Eğer koşulun tamamı (koşul ve gövde) tek bir satıra sığarsa (zorunlu olmamakla birlikte) her şeyi bir satıra sığdırabilir. Örneğin, kabul edilir:

if (condition) {
    body();
}

Bu kabul edilebilir bir durumdur:

if (condition) body();

ancak bu kabul edilmez:

if (condition)
    body();  // bad!

Satır uzunluğunu sınırla

Kodunuzdaki her metin satırı en fazla 100 karakter uzunluğunda olmalıdır. Bu kural birçok tartışmayla ele alsa da karar değişmedi en fazla 100 karakter uzunluğunda istisnalar söz konusudur:

• Yorum satırı daha uzun bir örnek komut veya düz URL içeriyorsa varsa, söz konusu satır her metin için 100 karakterden kesme ve yapıştırma kolaylığı.
• Kullanıcılara nadiren gösterildiği için içe aktarma satırları sınırı aşabilir (bu aynı zamanda araçla yazmayı da basitleştirir).

Standart Java ek açıklamalarını kullanma

Ek açıklamalar, aynı dil için diğer değiştiricilerden önce gelmelidir öğesine dokunun. Basit işaretçi ek açıklamaları (örneğin, @Override) dil öğesiyle aynı satırda gösterilir. Birden fazla ek açıklama varsa veya parametre haline getirilmiş ek açıklamaları kullanın, bunları alfabetik olarak sıralayabilirsiniz.

Java'daki önceden tanımlanmış üç ek açıklama için Android standart uygulamaları şunlardır:

• @Deprecated ek açıklamasını kullanın kullanılması önerilmez. Şunu kullanıyorsanız: @Deprecated ek açıklaması için @deprecated Javadoc etiketine sahip olmalı ve alternatif bir uygulama adlandırmalıdır. Ayrıca, @Deprecated yönteminin yine de işe yaraması gerektiğini unutmayın. @deprecated Javadoc etiketine sahip eski bir kod görürseniz @Deprecated ek açıklaması.
• @Override ek açıklamasını istediğiniz zaman kullanın bir yöntem, API'den alınan bir üst sınıf. Örneğin, @inheritdocs Javadoc etiketini kullanıyorsanız ve bir sınıftan (arayüzden değil) türetildiğinde, yöntem, üst sınıfın yöntemini geçersiz kılar.
• @SuppressWarnings ek açıklamasını kullanın yalnızca belli bir ekip üyesinin bir uyarıyı kaldırın. Bu uyarının sonunda yok et" @SuppressWarnings ek açıklaması olmalıdır tüm uyarıların sistemdeki gerçek sorunları yansıttığından girin.

  @SuppressWarnings ek açıklaması zorunlu olduğunda başında bir TODO yorum bulunur ve bu açıklama “yine yok et" koşul. Bu, normalde rahatsız edici bir sınıfı tanımlar garip bir arayüze sahip. Örnek:

  // TODO: The third-party class com.third.useful.Utility.rotate() needs generics
  @SuppressWarnings("generic-cast")
  List<String> blix = Utility.rotate(blax);

  @SuppressWarnings ek açıklaması gerekli olduğunda kodu yeniden düzenleyin ek açıklamanın yer aldığı yazılım öğelerini geçerli olur.

Kısaltmaları kelime olarak ele alın

Kısaltmaları, adlandırma değişkenleri ve yöntemlerinde kelime olarak ele alın. ve sınıfları düzenleyerek adları daha okunaklı hale getirin:

JDK ve Android kod tabanları arasında tutarsızlık olduğundan başlı başına kısaltmalar söz konusu olduğunda, bu modelle tutarlı bir etrafındaki kod. Bu nedenle, kısaltmaları her zaman kelime olarak ele alın.

TODO yorumlarını kullanma

Geçici, kısa vadeli bir çözüm veya çözüm amaçlı kodlar için TODO yorumlarını kullanın. ama mükemmel değil. Bu yorumlar, tüm satırlarda TODO dizesini içermelidir. büyük harf ve ardından iki nokta üst üste işareti eklendi:

// TODO: Remove this code after the UrlTable2 has been checked in.

ve

// TODO: Change this to use a flag instead of a constant.

TODO metriğiniz "İleri bir tarihte bir şey yapın" biçimindeyse emin olmak için belirli bir tarih ("Kasım 2005'e kadar düzeltin") veya belirli bir etkinlik ("Tüm üretim mikserlerinden sonra bu kodu kaldır daha iyi anlayacaksınız.").

Tutkulu şekilde günlüğe kaydedin

Günlük kaydı gerekli olsa da makul düzeyde tutulmaması halinde yararlılığını kaybeder tereddüt et. Ağaç kesme tesisleri, beş farklı düzeyde günlük kaydı sağlar:

• ERROR: Önemli bir şey olduğunda kullanın. bir öğenin kullanıcı tarafından görülebilen sonuçları olur ve kurtarılamaz uygulamaların yüklemesini kaldırmadan, veri bölümlerinin temizlenmesi veya tüm cihazın yeniden yüklenmesi (veya daha kötüsü). Bu seviye her zaman günlüğe kaydedilir. Bu sayfada birtakım günlük kaydının ERROR düzeyi, bir uzmana bildirilmek için uygun adaylardır istatistik toplama sunucusu.
• WARNING: Ciddi ve beklenmedik bir şey olduğunda kullanın kullanıcı tarafından görülebilecek ancak bazı işlemler gerçekleştirerek veri kaybı olmadan kurtarılabilir. bir uygulamayı tamamen beklemek veya yeniden başlatmak gibi açık bir işlem sürümünü yeniden indirmek veya olanak tanır. Bu seviye her zaman günlüğe kaydedilir. Günlük kaydını gerekçelendiren sorunlar WARNING seviyesindeki bir kullanıcı, istatistik toplama sunucusu.
• INFORMATIVE: İlginç bir şeyi not etmek için kullanın durum, yani bir durum tespit edildiğinde geniş çaplı bir etkisi olacak ancak her zaman bir hata olması gerekmez. Böyle bir yalnızca en yetkin olduğundan emin olun (yinelenmesi önlemek için) yetkili olmayan bileşenler tarafından günlüğe kaydedilmesi). Bu seviye her zaman günlüğe kaydedilir.
• DEBUG: beklenmedik şekilde araştırmak ve hata ayıklamak için kullanılabilir cihaz ve bunları kontrol etmenizi sağlar. Yalnızca yeterli miktarda veri toplamak için gerekli olanları günlüğe kaydedin bileşeninde ne olduğuyla ilgili bilgi verir. Hata ayıklamanız günlükler günlüğe hakimse, daha fazla ayrıntı için günlük kaydı.

  Bu seviye, sürüm derlemelerinde bile kaydedilir ve zorunludur. bir if (LOCAL_LOG) veya if LOCAL_LOGD) bloğu içine alınır (burada LOCAL_LOG[D] tanımlanır) olduğundan emin olun. Böylece, yeniden devre dışı bırakmanızı sağlar. Dolayısıyla, ekibinizin kullandığı if (LOCAL_LOG) blokta. Bu dizideki tüm dizeler günlüğün, aynı zamanda if (LOCAL_LOG) blok. Günlük kaydı çağrısını yeniden düzenlemeyin bir yöntem çağrısına aktarmanızı sağlarsa binanın dışında yürütülecek dize if (LOCAL_LOG) blok.

  Hâlâ if (localLOGV) yazan bir kod var. Bu kabul edilir ancak ad standart değildir.

• VERBOSE: Diğer her şey için kullanın. Bu seviye yalnızca hata ayıklama derlemelerinde günlüğe kaydedilir ve için if (LOCAL_LOGV) blok (veya eşdeğeri) varsayılan olarak derlenir. Herhangi bir dize yapısı ve uygulamanızın içindeki if (LOCAL_LOGV) blok.

Notlar

• VERBOSE düzeyi hariç belirli bir modülde, hata mümkünse yalnızca bir kez bildirilmelidir. Şu zincirin içinde: çağrısını yoksa yalnızca en içteki fonksiyona hatası döndürür ve aynı modülde arayanlar yalnızca sorunu tespit etmeye yardımcı oluyorsa bazı günlük kayıtları.
• Bir modül zincirinde, VERBOSE düzeyi dışında bir alt düzey modül, üst düzey bir modülden geçersiz veri geldiğini saptar alt düzey modül ise bu durumu yalnızca DEBUG günlüğü ve yalnızca günlük kaydında arayana ulaşabileceksiniz. Daha net bir şekilde belirtmek gerekirse istisnanın atıldığı günlük durumları (istisna, tüm alakalı bilgileri içermemesi) ya da yalnızca bilginin bir hata kodunda yer alıyor. Bu, özellikle Çerçeve ve uygulamalar arasındaki etkileşimin önemli olduğunu üçüncü taraf uygulamalarının neden olduğu üst sınırdan daha yüksek düzeyde bir günlük kaydını tetiklememelidir. DEBUG seviye. Yalnızca Bir modül veya uygulama, algılandığında INFORMATIVE veya daha yüksek bir düzey veya daha düşük bir düzeyden gelen bir hatadır.
• Normalde bir miktar günlük kaydı işlemini gerekçelendirecek bir koşul, bu tür durumlara yol açacak bazı sonuçlara ulaşmak için günlüklerin taşmasını önlemek için uygulanan aynı (veya çok benzer) bilgilerin yinelenen kopyaları
• Ağ bağlantısı kaybı yaygın olarak kabul edilir ve ve nedensiz olarak günlüğe kaydedilmemelidir. Ağ kaybı bir uygulama içinde sonuçları olan bağlantı şu adreste günlüğe kaydedilmelidir: DEBUG veya VERBOSE düzeyini (değişkenliğin bir sürüme kaydedilebilecek kadar ciddi ve beklenmedik sonuçlar derleme)
• Kullanıcıların erişimine açık veya açık olan bir dosya sisteminde tam dosya sistemine sahip olma kaydı yapılmamalıdır. daha yüksektir.
• Güvenilmeyen bir kaynaktan gelen geçersiz veriler (buradaki tüm dosyalar dahil) paylaşılan depolama alanı veya bir ağ üzerinden gelen veriler bağlantısı) beklenen bir durum olarak kabul edilir ve DEBUG daha yüksek bir düzeyde günlük kaydı yapılır. geçersiz (hatta günlük kaydı da mümkün olduğunca sınırlı olmalıdır).
• String nesne üzerinde kullanıldığında + operatörü dolaylı olarak varsayılan değerde bir StringBuilder örneği oluşturur arabellek boyutu (16 karakter) ve potansiyel olarak diğer geçici String nesneler'i tıklayın. Dolayısıyla, StringBuilder nesnelerini açıkça oluşturmak maliyeti, varsayılan + operatörüne daha verimli hale getirebilirsiniz). Unutmayın ki, Log.v(), sürüm derlemelerinde derlenir ve yürütülür günlükler okunmuyor olsa bile dizelerin oluşturulması buna dahildir.
• Başkaları tarafından okunması amaçlanan günlük kayıtları sürüm derlemelerinde sunulan sistemler şifreli değil, kısa olmalıdır. ve anlaşılabilir olmalıdır. Buna, tüm günlük kayıtları DEBUG seviyesine kadar.
• Mümkün olduğunda, tek bir satırda giriş yapmaya devam edin. 80 veya 100 karaktere kadar olan satır uzunlukları kabul edilir. 130 veya 160 karakteri aşan uzunluklardan kaçının. (etiketin uzunluğu dahil) kullanın.
• Günlük kaydı başarılı olursa bu raporları asla daha üst düzeylerde kullanmayın VERBOSE oranından.
• Belirlenmesi zor bir sorunu teşhis etmek için geçici günlük kaydı kullanıyorsanız yeniden oluşturun, DEBUG veya VERBOSE düzeyinde tutun ve içine, derleme zamanıdır.
• Günlükten geçen güvenlik sızıntılarına karşı dikkatli olun. Günlük kaydını gizli tutmaktan kaçının ekleyebilirsiniz. Özellikle, korunan içerikle ilgili bilgileri günlüğe kaydetmekten kaçının. Bu adım, özellikle de önceden bilmek kolay olmadığından çerçeve kodunu yazmanıza yardımcı olur. Ayrıca, gizli bilgi veya korumalı içerik olmamalıdır.
• Hiçbir zaman System.out.println() (veya şu süre için printf()) kullanmayın: yerel kod) girin. System.out ve System.err /dev/null adresine yönlendirildiğinden basılı ekstrelerinizde görünür efektler. Ancak bu satır öğeleri için gerçekleşen tüm dize bu çağrılar yürütülmeye devam eder.
• Günlük kaydını tutmanın en önemli kuralı, günlüklerinizin diğer günlüklerin gerektiği şekilde arabellekten çıkarılmasına neden olabilir. kendi özgeçmişinizi de ortaya koyun.

Javatest stili kuralları

Test yöntemi adlandırma kurallarını izleyin ve ayırmak için alt çizgi kullanın nelerin test edildiğini görebilirsiniz. Bu stil test edildiğini görmenizi sağlar. Örnek:

testMethod_specificCase1 testMethod_specificCase2

void testIsDistinguishable_protanopia() {
    ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
    assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
    assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
}