Bagaimana saya bisa tahu bagian mana dalam kode yang tidak pernah digunakan?

Saya memiliki kode warisan C ++ yang seharusnya saya hapus dari kode yang tidak digunakan. Masalahnya adalah bahwa basis kode besar.

Bagaimana saya bisa mengetahui kode mana yang tidak pernah dipanggil / tidak pernah digunakan?

Ada dua jenis kode yang tidak digunakan:

• yang lokal, yaitu, dalam beberapa fungsi beberapa jalur atau variabel tidak digunakan (atau digunakan tetapi tidak berarti, seperti ditulis tetapi tidak pernah dibaca)
• yang global: fungsi yang tidak pernah dipanggil, objek global yang tidak pernah diakses

Untuk jenis pertama, kompiler yang baik dapat membantu:

• -Wunused(GCC, Dentang ) harus memperingatkan tentang variabel yang tidak terpakai, analisis dentang yang tidak terpakai bahkan telah ditambahkan untuk memperingatkan tentang variabel yang tidak pernah dibaca (meskipun digunakan).
• -Wunreachable-code(GCC yang lebih lama, dihapus pada 2010 ) harus memperingatkan tentang blok lokal yang tidak pernah diakses (ini terjadi dengan pengembalian awal atau kondisi yang selalu dinilai benar)
• tidak ada pilihan yang saya tahu untuk memperingatkan tentang catchblok yang tidak digunakan , karena kompiler umumnya tidak dapat membuktikan bahwa tidak ada pengecualian yang akan dilemparkan.

Untuk jenis kedua, ini jauh lebih sulit. Secara statis itu memerlukan analisis seluruh program, dan meskipun optimasi waktu tautan sebenarnya dapat menghapus kode mati, dalam praktiknya program ini telah begitu banyak berubah pada saat dilakukan sehingga hampir tidak mungkin untuk menyampaikan informasi yang bermakna kepada pengguna.

Karena itu ada dua pendekatan:

• Teoretisnya adalah menggunakan penganalisa statis. Sepotong perangkat lunak yang akan memeriksa seluruh kode sekaligus dengan sangat terperinci dan menemukan semua alur alur. Dalam praktiknya saya tidak tahu ada yang bisa digunakan di sini.
• Yang pragmatis adalah menggunakan heuristik: gunakan alat cakupan kode (dalam rantai GNU itu gcov. Perhatikan bahwa flag tertentu harus dilewati selama kompilasi agar berfungsi dengan baik). Anda menjalankan alat cakupan kode dengan input beragam yang baik (tes unit atau tes non-regresi), kode mati harus dalam kode yang belum terjangkau ... sehingga Anda dapat mulai dari sini.

Jika Anda sangat tertarik pada subjek, dan punya waktu dan kecenderungan untuk benar-benar mengerjakan alat sendiri, saya sarankan menggunakan perpustakaan Dentang untuk membangun alat seperti itu.

1. Gunakan perpustakaan Dentang untuk mendapatkan AST (pohon sintaksis abstrak)
2. Lakukan analisis mark-and-sapuan dari titik masuk dan seterusnya

Karena Dentang akan mem-parsing kode untuk Anda, dan melakukan resolusi kelebihan, Anda tidak perlu berurusan dengan aturan bahasa C ++, dan Anda akan dapat berkonsentrasi pada masalah yang dihadapi.

Namun jenis teknik ini tidak dapat mengidentifikasi penimpaan virtual yang tidak digunakan, karena mereka dapat dipanggil dengan kode pihak ketiga yang tidak dapat Anda alasankan.

Untuk kasus seluruh fungsi yang tidak digunakan (dan variabel global yang tidak digunakan), GCC sebenarnya dapat melakukan sebagian besar pekerjaan untuk Anda asalkan Anda menggunakan GCC dan GNU ld.

Saat mengkompilasi sumber, gunakan -ffunction-sectionsdan -fdata-sections, lalu saat menautkan gunakan -Wl,--gc-sections,--print-gc-sections. Linker sekarang akan mendaftar semua fungsi yang bisa dihapus karena mereka tidak pernah dipanggil dan semua global yang tidak pernah direferensikan.

(Tentu saja, Anda juga dapat melewati --print-gc-sectionsbagian tersebut dan membiarkan tautan menghapus fungsi secara diam-diam, tetapi menyimpannya di sumbernya.)

Catatan: ini hanya akan menemukan fungsi lengkap yang tidak digunakan, itu tidak akan melakukan apa pun tentang kode mati dalam fungsi. Fungsi yang dipanggil dari kode mati dalam fungsi langsung juga akan disimpan.

Beberapa fitur khusus C ++ juga akan menyebabkan masalah, khususnya:

• Fungsi virtual. Tanpa mengetahui subclass mana yang ada dan mana yang sebenarnya dipakai pada saat run time, Anda tidak bisa tahu fungsi virtual mana yang Anda butuhkan untuk ada di program akhir. Linker tidak memiliki informasi yang cukup tentang itu sehingga harus menjaga mereka semua tetap ada.
• Global dengan konstruktor, dan konstruktor mereka. Secara umum, tautan tidak dapat mengetahui bahwa konstruktor untuk global tidak memiliki efek samping, jadi ia harus menjalankannya. Jelas ini berarti global itu sendiri juga perlu dijaga.

Dalam kedua kasus, apa pun yang digunakan oleh fungsi virtual atau konstruktor variabel global juga harus dijaga.

Peringatan tambahan adalah bahwa jika Anda sedang membangun pustaka bersama, pengaturan default di GCC akan mengekspor setiap fungsi di pustaka bersama, menyebabkannya untuk "digunakan" sejauh menyangkut linker. Untuk memperbaikinya Anda perlu mengatur default untuk menyembunyikan simbol alih-alih mengekspor (menggunakan misalnya -fvisibility=hidden), dan kemudian secara eksplisit memilih fungsi yang diekspor yang perlu Anda ekspor.

Nah jika Anda menggunakan g ++ Anda bisa menggunakan flag ini -Wunused

Dokumentasi menurut:

Memperingatkan kapan saja suatu variabel tidak digunakan selain dari deklarasi, setiap kali suatu fungsi dinyatakan statis tetapi tidak pernah didefinisikan, setiap kali label dideklarasikan tetapi tidak digunakan, dan setiap kali pernyataan menghitung hasil yang secara eksplisit tidak digunakan.

http://docs.freebsd.org/info/gcc/gcc.info.Warning_Options.html

Sunting : Ini adalah bendera lain yang berguna -Wunreachable-code Menurut dokumentasi:

Opsi ini dimaksudkan untuk memperingatkan ketika kompiler mendeteksi bahwa setidaknya seluruh baris kode sumber tidak akan pernah dieksekusi, karena beberapa kondisi tidak pernah puas atau karena itu setelah prosedur yang tidak pernah kembali.

Pembaruan : Saya menemukan topik serupa Deteksi kode mati dalam proyek C / C ++ lama

Saya pikir Anda sedang mencari alat cakupan kode . Alat cakupan kode akan menganalisis kode Anda saat sedang berjalan, dan itu akan memberi tahu Anda baris kode mana yang dieksekusi dan berapa kali, serta yang mana yang tidak.

Anda bisa mencoba memberikan alat cakupan kode sumber terbuka ini kesempatan: TestCocoon - alat cakupan kode untuk C / C ++ dan C #.

Jawaban sebenarnya di sini adalah: Anda tidak pernah benar-benar tahu pasti.

Paling tidak, untuk kasus nontrivial, Anda tidak bisa memastikan Anda mendapatkan semuanya. Pertimbangkan hal berikut dari artikel Wikipedia tentang kode yang tidak terjangkau :

double x = sqrt(2);
if (x > 5)
{
  doStuff();
}

Seperti yang dicatat Wikipedia dengan benar, kompiler yang cerdik mungkin dapat menangkap sesuatu seperti ini. Tetapi pertimbangkan modifikasi:

int y;
cin >> y;
double x = sqrt((double)y);

if (x != 0 && x < 1)
{
  doStuff();
}

Akankah kompiler menangkap ini? Mungkin. Tetapi untuk melakukan itu, perlu melakukan lebih dari menjalankan sqrtterhadap nilai skalar yang konstan. Itu harus mencari tahu yang (double)yakan selalu menjadi bilangan bulat (mudah), dan kemudian memahami kisaran matematika sqrtuntuk himpunan bilangan bulat (keras). Kompiler yang sangat canggih mungkin dapat melakukan ini untuk sqrtfungsi, atau untuk setiap fungsi dalam math.h , atau untuk fungsi input-tetap yang domainnya dapat dicari tahu. Ini menjadi sangat, sangat kompleks, dan kompleksitas pada dasarnya tidak terbatas. Anda dapat terus menambahkan lapisan kecanggihan ke kompiler Anda, tetapi akan selalu ada cara untuk menyelinap dalam beberapa kode yang tidak dapat dijangkau untuk set input yang diberikan.

Dan kemudian ada set input yang tidak pernah dimasukkan. Input yang tidak masuk akal dalam kehidupan nyata, atau diblokir oleh logika validasi di tempat lain. Tidak ada cara bagi kompiler untuk mengetahui hal itu.

Hasil akhir dari ini adalah bahwa sementara perangkat lunak yang disebutkan orang lain sangat berguna, Anda tidak akan pernah tahu pasti bahwa Anda telah menangkap semuanya kecuali Anda pergi melalui kode secara manual sesudahnya. Meski begitu, Anda tidak akan pernah yakin bahwa Anda tidak melewatkan apa pun.

Satu-satunya solusi nyata, IMHO, adalah sedapat mungkin waspada, gunakan otomatisasi yang Anda inginkan, refactor di mana Anda bisa, dan terus-menerus mencari cara untuk meningkatkan kode Anda. Tentu saja, itu ide yang baik untuk melakukan itu.

Saya belum menggunakannya sendiri, tetapi cppcheck , mengklaim menemukan fungsi yang tidak digunakan. Ini mungkin tidak akan menyelesaikan masalah yang lengkap tetapi mungkin ini merupakan permulaan.

Anda dapat mencoba menggunakan PC-lint / FlexeLint dari Gimple Software . Itu mengklaim

temukan makro yang tidak digunakan, typedef, kelas, anggota, deklarasi, dll. di seluruh proyek

Saya telah menggunakannya untuk analisis statis dan menemukannya sangat baik tetapi saya harus mengakui bahwa saya belum menggunakannya untuk menemukan kode mati secara spesifik.

Pendekatan normal saya untuk menemukan barang yang tidak digunakan adalah

1. pastikan sistem build menangani pelacakan ketergantungan dengan benar
2. mengatur monitor kedua, dengan jendela terminal layar penuh, menjalankan build berulang dan menampilkan screenful pertama dari output. watch "make 2>&1"cenderung melakukan trik pada Unix.
3. menjalankan operasi temukan-dan-ganti pada seluruh pohon sumber, tambahkan "//?" di awal setiap baris
4. perbaiki kesalahan pertama yang ditandai oleh kompiler, dengan menghapus "//?" di baris yang sesuai.
5. Ulangi sampai tidak ada kesalahan yang tersisa.

Ini adalah proses yang agak panjang, tetapi memberikan hasil yang baik.

Tandai sebanyak mungkin fungsi dan variabel publik sebagai privat atau terlindungi tanpa menyebabkan kesalahan kompilasi, saat melakukan ini, coba juga refactor kodenya. Dengan membuat fungsi-fungsi pribadi dan sampai batas tertentu dilindungi, Anda mengurangi area pencarian Anda karena fungsi-fungsi pribadi hanya dapat dipanggil dari kelas yang sama (kecuali ada makro bodoh atau trik lain untuk menghindari pembatasan akses, dan jika itu masalahnya saya sarankan Anda cari pekerjaan baru). Jauh lebih mudah untuk menentukan bahwa Anda tidak memerlukan fungsi pribadi karena hanya kelas yang sedang Anda kerjakan yang dapat memanggil fungsi ini. Metode ini lebih mudah jika basis kode Anda memiliki kelas-kelas kecil dan secara longgar digabungkan. Jika basis kode Anda tidak memiliki kelas kecil atau memiliki kopling sangat ketat, saya sarankan membersihkannya terlebih dahulu.

Selanjutnya akan menandai semua fungsi publik yang tersisa dan membuat grafik panggilan untuk mencari tahu hubungan antara kelas-kelas. Dari pohon ini, cobalah untuk mencari tahu bagian mana dari cabang yang sepertinya dapat dipangkas.

Keuntungan dari metode ini adalah Anda dapat melakukannya berdasarkan modul, sehingga mudah untuk tetap lulus dari unittest Anda tanpa memiliki periode waktu yang besar ketika Anda mendapatkan basis kode yang rusak.

Jika Anda menggunakan Linux, Anda mungkin ingin melihat ke dalam callgrind, alat analisis program C / C ++ yang merupakan bagian dari valgrindsuite, yang juga berisi alat yang memeriksa kebocoran memori dan kesalahan memori lainnya (yang harus Anda gunakan juga). Ini menganalisis contoh menjalankan program Anda, dan menghasilkan data tentang grafik panggilannya, dan tentang biaya kinerja node pada grafik panggilan. Biasanya digunakan untuk analisis kinerja, tetapi juga menghasilkan grafik panggilan untuk aplikasi Anda, sehingga Anda dapat melihat fungsi apa yang dipanggil, serta peneleponnya.

Ini jelas melengkapi metode statis yang disebutkan di tempat lain di halaman, dan itu hanya akan membantu untuk menghilangkan kelas, metode, dan fungsi yang sama sekali tidak digunakan - itu juga tidak membantu menemukan kode mati di dalam metode yang sebenarnya disebut.

Saya benar-benar belum menggunakan alat apa pun yang melakukan hal seperti itu ... Tapi, sejauh yang saya lihat di semua jawaban, tidak ada yang pernah mengatakan bahwa masalah ini tidak dapat dihitung.

Apa yang saya maksud dengan ini? Bahwa masalah ini tidak dapat diselesaikan dengan algoritma apa pun di komputer. Teorema ini (bahwa algoritma semacam itu tidak ada) adalah akibat wajar dari Turing's Halting Problem.

Semua alat yang akan Anda gunakan bukan algoritma tetapi heuristik (yaitu bukan algoritma yang tepat). Mereka tidak akan memberi Anda persis semua kode yang tidak digunakan.

Salah satu caranya adalah menggunakan fitur debugger dan kompiler untuk menghilangkan kode mesin yang tidak digunakan selama kompilasi.

Setelah beberapa kode mesin dihilangkan, debugger tidak akan membiarkan Anda meletakkan breakpojnt pada baris kode sumber yang sesuai. Jadi, Anda meletakkan breakpoints di mana-mana dan memulai program dan memeriksa breakpoints - yang ada dalam status "tidak ada kode untuk sumber ini" sesuai dengan kode yang dihilangkan - baik kode yang tidak pernah dipanggil atau telah diuraikan dan Anda harus melakukan beberapa minimum analisis untuk menemukan yang mana dari dua yang terjadi.

Setidaknya begitulah cara kerjanya di Visual Studio dan saya kira toolet lain juga bisa melakukannya.

Itu banyak pekerjaan, tapi saya kira lebih cepat daripada menganalisis semua kode secara manual.

CppDepend adalah alat komersial yang dapat mendeteksi jenis, metode, dan bidang yang tidak digunakan, dan melakukan lebih banyak lagi. Ini tersedia untuk Windows dan Linux (tetapi saat ini tidak memiliki dukungan 64-bit), dan dilengkapi dengan uji coba 2 minggu.

Penafian: Saya tidak bekerja di sana, tetapi saya memiliki lisensi untuk alat ini (dan juga NDepend , yang merupakan alternatif yang lebih kuat untuk kode .NET).

Bagi mereka yang ingin tahu, berikut adalah contoh aturan bawaan (yang dapat disesuaikan) untuk mendeteksi metode mati, ditulis dalam CQLinq :

// <Name>Potentially dead Methods</Name>
warnif count > 0
// Filter procedure for methods that should'nt be considered as dead
let canMethodBeConsideredAsDeadProc = new Func<IMethod, bool>(
    m => !m.IsPublic &&       // Public methods might be used by client applications of your Projects.
         !m.IsEntryPoint &&            // Main() method is not used by-design.
         !m.IsClassConstructor &&      
         !m.IsVirtual &&               // Only check for non virtual method that are not seen as used in IL.
         !(m.IsConstructor &&          // Don't take account of protected ctor that might be call by a derived ctors.
           m.IsProtected) &&
         !m.IsGeneratedByCompiler
)

// Get methods unused
let methodsUnused = 
   from m in JustMyCode.Methods where 
   m.NbMethodsCallingMe == 0 && 
   canMethodBeConsideredAsDeadProc(m)
   select m

// Dead methods = methods used only by unused methods (recursive)
let deadMethodsMetric = methodsUnused.FillIterative(
   methods => // Unique loop, just to let a chance to build the hashset.
              from o in new[] { new object() }
              // Use a hashet to make Intersect calls much faster!
              let hashset = methods.ToHashSet()
              from m in codeBase.Application.Methods.UsedByAny(methods).Except(methods)
              where canMethodBeConsideredAsDeadProc(m) &&
                    // Select methods called only by methods already considered as dead
                    hashset.Intersect(m.MethodsCallingMe).Count() == m.NbMethodsCallingMe
              select m)

from m in JustMyCode.Methods.Intersect(deadMethodsMetric.DefinitionDomain)
select new { m, m.MethodsCallingMe, depth = deadMethodsMetric[m] }

Itu tergantung pada platform yang Anda gunakan untuk membuat aplikasi Anda.

Misalnya, jika Anda menggunakan Visual Studio, Anda bisa menggunakan alat seperti .NET ANTS Profiler yang dapat mengurai dan profil kode Anda. Dengan cara ini, Anda harus segera mengetahui bagian mana dari kode Anda yang benar-benar digunakan. Eclipse juga memiliki plugin yang setara.

Jika tidak, jika Anda perlu tahu apa fungsi aplikasi Anda yang sebenarnya digunakan oleh pengguna akhir Anda, dan jika Anda dapat melepaskan aplikasi Anda dengan mudah, Anda dapat menggunakan file log untuk audit.

Untuk setiap fungsi utama, Anda dapat melacak penggunaannya, dan setelah beberapa hari / minggu baru saja mendapatkan file log itu, dan melihatnya.

Saya tidak berpikir itu bisa dilakukan secara otomatis.

Bahkan dengan alat cakupan kode, Anda perlu menyediakan data input yang cukup untuk dijalankan.

Mungkin alat analisis statis yang sangat kompleks dan mahal seperti dari Coverity's atau compiler LLVM bisa membantu.

Tapi saya tidak yakin dan saya lebih suka review kode manual.

DIPERBARUI

Yah .. hanya menghapus variabel yang tidak digunakan, fungsi yang tidak digunakan tidak sulit sekalipun.

DIPERBARUI

Setelah membaca jawaban dan komentar lain, saya lebih yakin bahwa itu tidak bisa dilakukan.

Anda harus mengetahui kode untuk memiliki ukuran cakupan kode yang bermakna, dan jika Anda tahu bahwa banyak pengeditan manual akan lebih cepat daripada menyiapkan / menjalankan / meninjau hasil cakupan.

Saya mempunyai seorang teman yang menanyakan pertanyaan ini kepada saya hari ini, dan saya melihat-lihat beberapa perkembangan Clang yang menjanjikan, misalnya ASTMatcher dan Static Analyzer yang mungkin memiliki visibilitas yang cukup pada kejadian-kejadian selama kompilasi untuk menentukan bagian kode mati, tetapi kemudian saya menemukan ini:

https://blog.flameeyes.eu/2008/01/today-how-to-identify-unused-exported-functions-and-variables

Cukup banyak deskripsi lengkap tentang cara menggunakan beberapa bendera GCC yang tampaknya dirancang untuk tujuan mengidentifikasi simbol yang tidak direferensikan!

Masalah umum jika beberapa fungsi akan dipanggil adalah NP-Complete. Anda tidak dapat mengetahui sebelumnya secara umum apakah suatu fungsi akan dipanggil karena Anda tidak akan tahu apakah mesin Turing akan pernah berhenti. Anda bisa mendapatkan jika ada beberapa jalur (statis) yang beralih dari main () ke fungsi yang Anda tulis, tetapi itu tidak menjamin Anda bahwa itu akan pernah dipanggil.

Nah jika Anda menggunakan g ++ Anda bisa menggunakan flag ini -Digunakan

Dokumentasi menurut:

Warn whenever a variable is unused aside from its declaration, whenever a function is declared static but never defined, whenever a label is declared but not used, and whenever a statement computes a result that is explicitly not used.

http://docs.freebsd.org/info/gcc/gcc.info.Warning_Options.html

Sunting: Berikut ini adalah flag lain yang berguna -Wunreachable-code Menurut dokumentasi:

This option is intended to warn when the compiler detects that at least a whole line of source code will never be executed, because some condition is never satisfied or because it is after a procedure that never returns.