Java programlama dili: statik analizle sıfır hata bulun

Portakalkafa

Global Mod
Global Mod


  1. Java programlama dili: statik analizle sıfır hata bulun

Yeni projeler, yeni zorluklar ve yeni bilgiler getirir. Mevcut projemde, yakın zamanda statik kod analizinde boş kontrolleri işlemek için bir tanım oluşturdum. Projedeki çoğu kişi için parametrelerin yalnızca çalışma zamanında kullanılmaması önemliydi, örneğin Objects.requireNonNull(…)) kontrol edilir, ancak doğrudan derleme sırasında da kontrol edilir. Bu nedenle, işlemeyi doğrulamak için statik kod analizini de kullanmaya karar verdik. null koymak.







Hendrik Ebbers (@hendrikEbbers), JCP Uzman Grubunun bir üyesi olan Java Şampiyonu ve birçok kez JavaOne’ın Rockstar Konuşmacısı olarak ödüllendirildi. Hendrik, Open Elements şirketi aracılığıyla şu anda Hedera Hashgraph’ın tasarlanmasına ve hizmetlerinin halka sunulmasına yardımcı oluyor. Hendrik, JUG Dortmund ve Cyberland’in kurucu ortağıdır ve dünya çapında Java üzerine dersler ve atölye çalışmaları yapmaktadır. “Mastering JavaFX 8 Controls” adlı kitabı Oracle Press tarafından 2014 yılında yayınlandı. Hendrik, JakartaEE veya Eclipse Adoptium gibi açık kaynaklı projelerde aktif olarak yer alıyor. Hendrik, AdoptOpenJDK TSC ve Eclipse Adoptium WG’nin bir üyesidir.







Statik kod analizi


Java için var olan kontrol ve kaydırılmış ek açıklama kitaplıklarına dalmadan önce, statik kod analizinin neyle ilgili olduğunu kısaca açıklamama izin verin. Burada program kodu derleme sırasında araçlar tarafından kontrol edilir. Şu anda Java’daki en yaygın araç, kesinlikle Maven veya Gradle ile yapılara entegre edilebilen ve sonuçları SonarCloud gibi platformlarda otomatik olarak yayınlanabilen SpotBugs’tır. Statik kod analizi ile bellek taşması, sonsuz döngü veya “Out of Bound” hataları gibi sorunları bulabilirsiniz. Basit bir örnek, 0’a bölmedir.Kodda böyle bir şey olursa, ayrıştırma bir uyarı verebilir veya yapılandırmaya bağlı olarak tüm derlemeyi hatalarla sonlandırabilir.Bizim projemizde GitHub’da böyle bir kontrol var. Sonuçları doğrudan SonarCloud’da görüntüleyen Actions ve bir çekme isteği.

Boş değerlerin uygun şekilde işlenmesi


Java ile programlama ile ilgili bir sorun kesinlikle ele alınması gereken bir sorundur. null. Şahsen ben bu kanaatteyim null programlamada sıfır referansının mucidi Tony Hoare şimdi bundan “trilyon dolarlık bir hata” olarak bahsetmesine rağmen, gerekçesi var.

Ancak, Java’da bir parametrenin boş olup olmayacağını tanımlamanın yerel bir yolu yoktur. Bu arada sınıf kitaplığındaki çeşitli araçlar kullanılarak bu problem çözülmeye çalışılmıştır. bunun için örnekler java.util.Optional, Objects.requireNonNull(…) hatta JSR305.


Boş referanslar için yerel desteği olan bir programlama dilinin iyi bir örneği Kotlin’dir. Null yapılabilir referanslar ile null olmayan referanslar arasında açıkça ayrım yapın. İkincisi varsayılandır, ancak böyle bir referansa sahip bir değişkene asla null atanamaz. Null tutabilen bir değişkene ihtiyacınız varsa, null yapılabilir bir referansla çalışmalısınız. Bu konuda olacak ? belirtilen karakterler Aşağıdaki kod, her iki referans için bir Kotlin örneği içerir:


var a: String = "abc" // Regular initialization means
// non-null by default
a = null // compilation error

var b: String? = "abc" // can be set to null
b = null // ok


Java’da böyle bir yerel destek olmadığı için, statik kod analizi kullanılarak mümkün olan en iyi şekilde entegre edilmeye çalışılır. Genel olarak, burada bir () ile iki ek açıklama gerekir.@Nullable) bir değerin veya değişkenin boş olabileceğini tanımlar ve diğer not, bir değerin veya değişkenin asla boş olmaması gerektiğini tanımlar (@NonNull).

Bir yöntemi tanımlayan ve ek açıklama yoluyla yöntemin dönüş değerinin asla döndürmediği bilgileri ekleyen bir kod örneği null olabilir:


@NonNull String getName() {
if(isUnique()) {
return „Item „ + getId();
} else {
return null;
}
}


Yöntemin uygulanmasında görebileceğiniz gibi, tamamen mümkündür. null geri gelmek. Bu, statik kod analizinin bir ihlali ortaya çıkardığı bir durum olacaktır. Örneğin, isterseniz IntelliJ’i bu tür sorunları doğrudan gösterecek şekilde yapılandırabilirsiniz.

Aşağıdaki kod, @Nullable Kullanılan açıklama, analizde bir uyarı oluşturur:


void check(@Nullable String value) {
Objects.hash(value.toLowerCase());
}


Bu örnekte, açıklama @Nullable değişken için value bunun değer olduğunu tanımlar null sahip olabilmek. Ancak, kodun değişkene doğrudan erişmesi potansiyel olarak aa’ya yol açar. NullPointerException çalışma zamanında. Bu, statik kod analizi tarafından da değerlendirilecek ve bir sorun olarak işaretlenecektir.

Kendi projesinde kurulum


Bu tür statik kod analizlerini projenize entegre etmek istiyorsanız, bazı basit gereksinimler oluşturmanız gerekir. Yapılacak ilk şey, bir veya daha fazla analiz aracı seçmektir. Burada Findbugs’ın halefi olan Spotbugs’u öneriyorum. Araç, komut satırından başlatılabilir veya bir Gradle veya Maven yapısına entegre edilebilir. Bulduğunuz sorunları analiz etmek için, bunları Spotbug swing istemcisinde veya örneğin Maven kullanılarak oluşturulmuş bir Maven sitesinin parçası olarak HTML tabanlı bir genel bakış olarak inceleyebilirsiniz. site-Hedef. Örneğin, sonuçları bir sonara veya SonarCloud’a yüklemek için aleti yapılandırabilirsiniz.

DSÖ @Nullable– VE @NonNull– projenizde ek açıklamaları kullanmak istiyorsanız, açıklama sağlayan bir kitaplık gerekir. Projeniz yalnızca derlenmekte olan kitaplığa bağlı olmalıdır. Burada da (maalesef) ek açıklamalar sağlayan bir dizi kitaplık var. Her bir kütüphaneyi artıları ve eksileri üzerinden incelemek ayrı bir yazının parçası olacaktır. Bu nedenle, öncelikle aşağıdaki Maven koordinatlarında bulunabilecek bir bağımlılık olarak Spotbug ek açıklamalarını öneriyorum:


<dependency>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-annotations</artifactId>
<version>4.7.3</version>
</dependency>


Ne yazık ki, araçların ve kitaplıkların bolluğu mükemmel, geleceğe yönelik kombinasyonu bulmayı kolaylaştırmıyor. Konunun derinliklerine indikçe, bu alandaki pek çok şeyin henüz yaygın olarak kullanılan standartlar veya en iyi uygulamalar tarafından tanımlanmamış olması beni şaşırttı. JSR305 gibi farklı yaklaşımlar olsa da, bunlar her zaman bir noktada başarısız oldu ve bugün bazen vahşi bir karışımda kullanılıyor. Bu nedenle yakın bir gelecekte bu konuya ayrı bir yazı ayıracağım.


(rm)



Haberin Sonu
 
Üst