เหตุใดจึงลบคำสั่งที่ไม่ได้ใช้ออกโดยใช้ C #

ฉันสงสัยว่ามีสาเหตุใดบ้าง (นอกเหนือจากการจัดเก็บซอร์สโค้ด) ทำไมนักพัฒนาจึงใช้Usingsฟีเจอร์"Remove Unused " ใน Visual Studio 2008

มีเหตุผลบางประการที่คุณต้องการนำออก

• มันไม่มีจุดหมาย พวกเขาไม่เพิ่มมูลค่า
• มันสับสน กำลังใช้อะไรจากเนมสเปซนั้น?
• หากคุณไม่ทำเช่นนั้นคุณจะค่อยๆสะสมusingข้อความที่ไม่มีจุดหมายเมื่อรหัสของคุณเปลี่ยนแปลงไปตามกาลเวลา
• การวิเคราะห์แบบคงที่ช้ากว่า
• การคอมไพล์โค้ดช้าลง

ในทางกลับกันไม่มีเหตุผลมากมายที่จะทิ้งไว้ฉันคิดว่าคุณช่วยตัวเองไม่ได้ที่จะต้องลบทิ้ง แต่ถ้าคุณขี้เกียจแสดงว่าคุณมีปัญหาใหญ่ขึ้น!

ฉันจะพูดในทางตรงกันข้าม - การลบคำสั่งที่ไม่จำเป็นและไม่จำเป็นออกไปนั้นมีประโยชน์มาก

ลองนึกภาพว่าคุณต้องกลับไปที่รหัสของคุณใน 3, 6, 9 เดือนหรือมีคนอื่นมายึดรหัสของคุณและดูแลรักษารหัสของคุณ

หากคุณมีรายการซักผ้ายาวมากเกี่ยวกับการใช้คำสั่งที่ไม่จำเป็นจริงๆการดูรหัสอาจทำให้สับสนได้ เหตุใดจึงใช้ในนั้นหากไม่มีการใช้งานจากเนมสเปซนั้น ??

ฉันเดาว่าในแง่ของการบำรุงรักษาในระยะยาวในสภาพแวดล้อมระดับมืออาชีพฉันขอแนะนำอย่างยิ่งให้รักษารหัสของคุณให้สะอาดที่สุดเท่าที่จะเป็นไปได้ - และรวมถึงการทิ้งสิ่งที่ไม่จำเป็นออกไป ความยุ่งเหยิงน้อยลงเท่ากับความสับสนน้อยลงและทำให้การบำรุงรักษาสูงขึ้น

มาร์ค

สำหรับฉันแล้วนี่ดูเหมือนว่าจะเป็นคำถามที่สมเหตุสมผลมากซึ่งผู้คนที่ตอบกลับได้รับการปฏิบัติอย่างไม่ค่อยมีเหตุผล

ฉันจะบอกว่าการเปลี่ยนแปลงซอร์สโค้ดต้องมีเหตุผล การเปลี่ยนแปลงเหล่านี้อาจมีค่าใช้จ่ายแอบแฝงและผู้ที่ตั้งคำถามต้องการทราบเรื่องนี้ พวกเขาไม่ได้ขอให้เรียกว่า "ขี้เกียจ" เหมือนที่คนคนหนึ่งดูถูกดูแคลน

ฉันเพิ่งเริ่มใช้ Resharper และกำลังเริ่มให้คำเตือนและคำแนะนำสไตล์เกี่ยวกับโครงการที่ฉันรับผิดชอบ ในหมู่พวกเขาคือการลบซ้ำซ้อนโดยใช้คำสั่ง แต่ยังมีคุณสมบัติซ้ำซ้อนการใช้ตัวพิมพ์ใหญ่และอื่น ๆ อีกมากมาย สัญชาตญาณในการทำงานของฉันคือการทำให้รหัสเป็นระเบียบและแก้ไขคำแนะนำทั้งหมด แต่หัวหน้าธุรกิจของฉันเตือนฉันเกี่ยวกับการเปลี่ยนแปลงที่ไม่ยุติธรรม

เราใช้กระบวนการสร้างอัตโนมัติดังนั้นการเปลี่ยนแปลงใด ๆ กับที่เก็บ SVN ของเราจะสร้างการเปลี่ยนแปลงที่เราไม่สามารถเชื่อมโยงกับโปรเจ็กต์ / จุดบกพร่อง / ปัญหาและจะทริกเกอร์บิวด์และรีลีสอัตโนมัติซึ่งไม่มีการเปลี่ยนแปลงการทำงานกับเวอร์ชันก่อนหน้า

หากเราดูที่การลบคุณสมบัติที่ซ้ำซ้อนสิ่งนี้อาจทำให้นักพัฒนาเกิดความสับสนเนื่องจากคลาสโดเมนและชั้นข้อมูลของเราแตกต่างกันตามคุณสมบัติเท่านั้น

ถ้าฉันดูการใช้ตัวพิมพ์ใหญ่ของ anachronyms อย่างเหมาะสม (เช่น ABCD -> Abcd) ฉันต้องคำนึงว่า Resharper ไม่ได้ refactor ไฟล์ Xml ใด ๆ ที่เราใช้ชื่อคลาสอ้างอิงนั้น

ดังนั้นการปฏิบัติตามคำแนะนำเหล่านี้จึงไม่ตรงไปตรงมาอย่างที่ปรากฏและควรปฏิบัติด้วยความเคารพ

นอกจากเหตุผลที่ระบุแล้วยังป้องกันความขัดแย้งในการตั้งชื่อโดยไม่จำเป็น พิจารณาไฟล์นี้:

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

โค้ดนี้ไม่คอมไพล์เนื่องจากทั้งเนมสเปซ System.IO และ System.Windows แต่ละรูปร่างมีคลาสที่เรียกว่า Path เราสามารถแก้ไขได้โดยใช้พา ธ คลาสเต็ม

        private static string temporaryPath = System.IO.Path.GetTempFileName();

หรือเราสามารถลบเส้นusing System.Windows.Shapes;ออก

ตัวเลือกน้อยลงในป๊อปอัป Intellisense (โดยเฉพาะอย่างยิ่งถ้าเนมสเปซมีวิธีการขยายจำนวนมาก)

Intellisense ในทางทฤษฎีควรเร็วกว่าด้วย

ลบออก โค้ดน้อยลงเพื่อดูและสงสัยเกี่ยวกับการประหยัดเวลาและความสับสน ฉันหวังว่าคนอื่น ๆ จะรักษาสิ่งที่เรียบง่ายเรียบร้อยและเป็นระเบียบเรียบร้อย มันเหมือนกับว่ามีเสื้อและกางเกงสกปรกอยู่ในห้องของคุณ มันน่าเกลียดและคุณต้องสงสัยว่าทำไมถึงอยู่ที่นั่น

นอกจากนี้ยังช่วยป้องกันการอ้างอิงแบบวงกลมที่ผิดโดยสมมติว่าคุณสามารถลบการอ้างอิง dll / project บางส่วนออกจากโปรเจ็กต์ของคุณได้หลังจากลบการใช้งานที่ไม่ได้ใช้แล้ว

โค้ดคอมไพล์ได้เร็วขึ้น

เมื่อเร็ว ๆ นี้ฉันได้รับเหตุผลอีกประการหนึ่งว่าทำไมการลบการนำเข้าที่ไม่ได้ใช้จึงมีประโยชน์และสำคัญมาก

ลองนึกภาพคุณมีชุดประกอบสองชุดโดยที่ชุดหนึ่งอ้างอิงอีกชุดหนึ่ง (ตอนนี้ขอเรียกชุดแรกAและชุดที่อ้างอิงB) ตอนนี้เมื่อคุณมีรหัสใน A ซึ่งขึ้นอยู่กับ B ทุกอย่างเรียบร้อยดี อย่างไรก็ตามในบางขั้นตอนในกระบวนการพัฒนาของคุณคุณสังเกตเห็นว่าคุณไม่จำเป็นต้องใช้รหัสนั้นอีกต่อไป แต่คุณปล่อยให้คำสั่งใช้งานอยู่ที่เดิม ตอนนี้คุณไม่เพียง แต่มีความหมายusing-directive แต่ยังประกอบการอ้างอิงไปยังBที่ไม่ได้ใช้ที่ใดก็ได้ แต่ในคำสั่งที่ล้าสมัย ประการแรกเพิ่มระยะเวลาที่จำเป็นในการคอมไพล์Aเนื่องจากBต้องโหลดด้วย

ดังนั้นนี่คือไม่เพียง แต่เป็นปัญหาในการทำความสะอาดและง่ายต่อการอ่านรหัส แต่ยังเกี่ยวกับการรักษาประกอบการอ้างอิงในการผลิตรหัสที่ไม่ทั้งหมดของผู้ประกอบการอ้างอิงแม้อยู่

สุดท้ายใน exapmle ของเราเราต้องส่ง B และ A เข้าด้วยกันแม้ว่า B จะไม่ได้ใช้ที่ใดก็ได้ใน A แต่อยู่ในusing-section สิ่งนี้จะส่งผลอย่างมากต่อรันไทม์ - ประสิทธิภาพของAเมื่อโหลดแอสเซมบลี

อย่างน้อยในทางทฤษฎีถ้าคุณได้รับไฟล์ C # .cs (หรือไฟล์ซอร์สโค้ดโปรแกรมใด ๆ ) คุณควรจะสามารถดูโค้ดและสร้างสภาพแวดล้อมที่จำลองทุกสิ่งที่ต้องการได้ ด้วยเทคนิคการรวบรวม / แยกวิเคราะห์คุณอาจสร้างเครื่องมือขึ้นมาโดยอัตโนมัติ อย่างน้อยที่สุดหากคุณทำสิ่งนี้เสร็จแล้วคุณสามารถมั่นใจได้ว่าคุณเข้าใจทุกสิ่งที่ไฟล์โค้ดพูด

ลองพิจารณาดูว่าคุณได้รับไฟล์. cs ที่มีusingคำสั่ง1,000 คำสั่งซึ่งใช้งานจริงเพียง 10 รายการ เมื่อใดก็ตามที่คุณดูสัญลักษณ์ที่เพิ่งเปิดตัวในรหัสที่อ้างอิงถึงโลกภายนอกคุณจะต้องอ่าน 1,000 บรรทัดเหล่านั้นเพื่อดูว่ามันคืออะไร นี่เป็นการทำให้ขั้นตอนข้างต้นช้าลงอย่างเห็นได้ชัด ดังนั้นหากคุณสามารถลดให้เหลือ 10 ได้ก็จะช่วยได้!

ในความคิดของฉันusingคำสั่งC # นั้นอ่อนแอมากเนื่องจากคุณไม่สามารถระบุสัญลักษณ์ทั่วไปเพียงรายการเดียวโดยที่ไม่มีการสูญหายและคุณไม่สามารถใช้usingคำสั่งนามแฝงเพื่อใช้วิธีการขยายได้ นี่ไม่ใช่กรณีในภาษาอื่นเช่น Java, Python และ Haskell ในภาษาเหล่านั้นคุณสามารถระบุสิ่งที่คุณต้องการจากโลกภายนอกได้ (เกือบ) แต่ฉันจะแนะนำให้ใช้usingนามแฝงทุกครั้งที่ทำได้