Sau một thời gian dài làm việc trên ứng dụng iPhone, tôi nhận ra rằng mã của mình khá bẩn, chứa một số #import và các phương thức không được gọi hoặc hữu ích chút nào.
Tôi muốn biết nếu có bất kỳ chỉ thị trình biên dịch hoặc cách nào để phát hiện những dòng mã vô dụng đó. Xcode có bất kỳ công cụ nào để phát hiện điều này không?
Câu trả lời:
Xcode cho phép bạn (bỏ) kiểm tra cài đặt cho các cảnh báo trình biên dịch cụ thể có thể cảnh báo bạn về một số loại mã không sử dụng. (Chọn dự án trong danh sách nguồn và Tệp> Nhận Thông tin, sau đó chọn tab Xây dựng.) Dưới đây là một số (hiển thị cho Clang và GCC 4.2 đối với tôi) có thể quan tâm:
Tôi không thấy bất kỳ tùy chọn nào để phát hiện các lần nhập chưa sử dụng, nhưng điều đó đơn giản hơn một chút - cách tiếp cận công nghệ thấp chỉ là nhận xét các câu lệnh nhập cho đến khi bạn gặp lỗi / cảnh báo biên dịch.
Các phương thức Objective-C không được sử dụng khó phát hiện hơn nhiều so với các hàm C không được sử dụng vì các thông báo được gửi động. Một cảnh báo hoặc một lỗi có thể cho bạn biết rằng bạn có một sự cố tiềm ẩn, nhưng việc thiếu một cảnh báo không đảm bảo rằng bạn sẽ không gặp phải lỗi thời gian chạy.
Chỉnh sửa: Một cách hay khác để phát hiện các phương thức không được sử dụng (có khả năng) là kiểm tra độ bao phủ của mã từ các lần thực thi thực tế. Điều này thường được thực hiện song song với kiểm thử đơn vị tự động, nhưng không nhất thiết phải như vậy.
Bài đăng trên blog này là một giới thiệu tốt về kiểm thử đơn vị và phạm vi mã bằng Xcode. Phần trên gcov(nhân tiện chỉ hoạt động với mã do GCC tạo ra) giải thích cách lấy Xcode để xây dựng mã công cụ có thể ghi lại tần suất nó đã được thực thi. Nếu bạn sử dụng một bản dựng công cụ của ứng dụng để quay trong trình mô phỏng, sau đó chạy gcov trên đó, bạn có thể xem mã nào đã được thực thi bằng cách sử dụng một công cụ như CoverStory (một GUI khá đơn giản) hoặc lcov(Perl script để tạo báo cáo HTML) .
Tôi sử dụng gcovvà lcovcho CHDataStructures.framework và tự động tạo báo cáo phạm vi sau mỗi cam kết SVN. Một lần nữa, hãy nhớ rằng không khôn ngoan nếu coi phạm vi bảo hiểm được thực thi như một thước đo xác định về mã nào là "chết", nhưng nó chắc chắn có thể giúp xác định các phương pháp mà bạn có thể điều tra thêm.
Cuối cùng, vì bạn đang cố gắng xóa mã chết, tôi nghĩ bạn cũng sẽ thấy câu hỏi SO này thú vị:
Chúng tôi đã sử dụng một số mã Ruby cây nhà lá vườn, hiện được trích xuất thành một viên đá quý có tên là fui: https://github.com/dblock/fui
Gần đây tôi đã viết một tập lệnh để tìm các #importcâu lệnh không được sử dụng (hoặc trùng lặp) : https://gist.github.com/Orangenhain/7691314
Tập lệnh lấy một tệp ObjC .m và bắt đầu nhận xét #importlần lượt từng dòng và xem liệu dự án có còn biên dịch hay không. Bạn sẽ phải thay đổi BUILD_DIR & BUILD_CMD.
Nếu bạn đang sử dụng findlệnh để cho tập lệnh chạy trên nhiều tệp, hãy đảm bảo sử dụng BUILD_CMD thực sự sử dụng tất cả các tệp đó (hoặc bạn sẽ thấy một tệp có nhiều câu lệnh nhập không sử dụng).
Tôi đã viết cái này mà không biết AppCode có một tính năng tương tự, tuy nhiên khi tôi thử nghiệm AppCode, nó không kỹ lưỡng như tập lệnh này (nhưng nhanh hơn [cho toàn bộ dự án]).
Như paddydub đã nói, AppCode làm điều này rất tốt. Tôi đã thử và chỉ mất 10 phút:
Đi tới Code > Optimize Imports..., hoặc^ + ⌥ + O
Đây là video mô tả cách thực hiện việc này: Phát hiện phương thức và phương thức nhập không sử dụng trong AppCode
Bạn có thể sử dụng Xcode Analyzer để tìm ra vấn đề đó và các vấn đề khác.
http://help.apple.com/xcode/mac/8.0/#/devb7babe820
Ngoài ra, bạn có thể đi tới dự án và xây dựng mục tiêu và thêm các tùy chọn cảnh báo thay đổi trong cài đặt xây dựng. Xem hướng dẫn này:
http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/
Gần đây, tôi đã thay đổi một dự án lớn từ Carbon sang Cocoa. Cuối cùng, có khá nhiều tệp mồ côi đã không còn được sử dụng. Tôi đã viết một kịch bản để tìm chúng về cơ bản đã làm điều này:
Đảm bảo rằng tất cả nguồn đã được đăng ký vào subversion (tức là sạch) Đảm bảo rằng nó hiện đang xây dựng mà không có lỗi (tức là xcodebuild trả về trạng thái 0) Sau đó, đối với mỗi tệp nguồn trong thư mục, trống (tức là xóa nội dung, cắt bớt độ dài) nguồn và tệp tiêu đề, hãy thử một bản dựng, nếu nó không thành công, hãy hoàn nguyên các tệp, nếu không, hãy để chúng trống.
Sau khi chạy, hãy hoàn nguyên và sau đó xóa tất cả các tệp đã làm trống, biên dịch và sau đó xóa tất cả các lỗi #imports.
Tôi cũng nên nói thêm, bạn cần tránh các tệp được tham chiếu từ tệp .xib hoặc .sdef và có thể có các trường hợp liên kết động khác, nhưng nó vẫn có thể cung cấp cho bạn một hướng dẫn tốt về những gì có thể bị xóa.
Kỹ thuật tương tự cũng có thể được sử dụng để xem có thể loại bỏ #import nào - thay vì cắt bớt tệp, hãy xóa lần lượt từng #import trong tệp và xem bản dựng có bị lỗi không.
idhoặc tạo một bộ chọn để gọi trong thời gian chạy, thì trình phân tích tĩnh không thể đảm bảo rằng mã thực sự không được sử dụng. Nếu mã vẫn cần thiết bị xóa, đó là nơi bạn sẽ gặp lỗi thời gian chạy. Tui bỏ lỡ điều gì vậy?