ทำไมการใช้ System.out.println () แย่มาก? [ปิด]

แน่นอนว่าเป็นการดีมากที่จะใช้กรอบการบันทึกสำหรับข้อความแสดงข้อผิดพลาดหรือคำเตือน แต่บางครั้งฉันใช้ System.out.println () ถ้าฉันต้องการลองสิ่งใหม่ ๆ ในเวลาอันสั้น

การใช้ System.out.println () นั้นแย่มากจริง ๆ หรือไม่สำหรับการทดสอบอย่างรวดเร็ว?

ตามที่เปิดเผยในความคิดเห็นคำถามจริงที่ถูกถามคือทำไมเครื่องมือวิเคราะห์รหัสแบบคงที่ใช้ธงของ System.out.println?

เหตุผลคือการส่งข้อความไปยัง stdout มักไม่เหมาะสมในสภาพแวดล้อมการผลิต หากคุณกำลังเข้ารหัสไลบรารีไลบรารีควรส่งคืนข้อมูลไปยังผู้เรียกไม่ใช่พิมพ์ไปที่ stdout หากคุณกำลังเข้ารหัสแอป GUI ข้อมูลจะถูกนำเสนอให้กับผู้ใช้ไม่ใช่ตำแหน่งที่เกิด stdout สำหรับชี้ (ซึ่งอาจไม่มีที่ใด) หากคุณกำลังเข้ารหัสเซิร์ฟเวอร์ (หรือสิ่งที่ทำงานในคอนเทนเนอร์ฝั่งเซิร์ฟเวอร์) คุณควรใช้สิ่งอำนวยความสะดวกการบันทึกข้อมูลใด ๆ ที่เฟรมเวิร์กได้จัดเตรียมไว้ และอื่น ๆ

แต่ถ้าคุณใช้ println สำหรับการดีบั๊กหรือการพัฒนาหรือคุณกำลังเขียนโปรแกรมและอ่าน stdin และเขียนไปยัง stdout println ก็ใช้ได้อย่างสมบูรณ์แบบ ไม่มีอะไรผิดปกติสำหรับกรณีเหล่านั้น

ทั้งหมดได้stdoutรับการบัฟเฟอร์และเป็นไปได้ว่าโปรแกรมของคุณจะหยุดทำงานหลังจากที่คุณโทรprintln()แต่ก่อนที่จะถึงหน้าจอ

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

System.outBufferedOutputStreamเป็นเพียงการห่อ นี่จะคล้ายกับเฟรมเวิร์กการบันทึกใด ๆ ที่คุณจะใช้เฟรมเวิร์กเพียงแค่ให้การทำงานมากขึ้นในรูปแบบของการกำหนดค่าและปลายทางของล็อกเอาต์พุตของคุณ

มันไม่ดีถ้าคุณกำลังทำงานในโปรแกรมที่ไม่สำคัญและคุณ

• ใช้ System.out เป็น crutch แทนการทดสอบหน่วยอัตโนมัติ (JUnit)
• ใช้เวลามากมายในการสร้างและลบหรือแสดงความคิดเห็น / ไม่พูดคำสั่ง System.out

มีข้อควรระวังบางประการเกี่ยวกับการใช้System.outแม้ในรหัสการอนุญาต

ปัญหาหนึ่งที่สำคัญก็คือว่ามันมักจะช้า ตัวอย่างเช่นหากคุณกำลังพยายามหาแนวคิดคร่าวๆเกี่ยวกับความเร็วของโค้ดบางอัน (โปรดทราบว่าmicrobenchmarks นั้นยาก ) จากนั้นการเพิ่มซิงเกิ้ลSystem.out.println()ที่ใดก็ได้สามารถทำให้เวลาของคุณยุ่งเหยิงได้จริง ๆ (เพราะการซิงโครไนซ์ ปรากฏแก่ผู้ใช้ก่อนกลับมา)

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

บ่อยครั้งที่คำตอบคือ "ขึ้นอยู่กับ" หากแอปพลิเคชันของคุณมีกรอบการบันทึกอยู่แล้วคุณก็สามารถใช้มันได้เช่นกัน มันไม่สามารถมีความสามารถน้อยกว่าprintln()และคุณอาจได้รับประโยชน์จากคุณสมบัติอื่น ๆ ที่มีให้ - การติดตามสแต็กบริบทเพิ่มเติมการจัดรูปแบบที่ดีขึ้นและอื่น ๆ นอกจากนี้ยังมีความเป็นไปได้ที่แตกต่างกันที่เฟรมเวิร์กการบันทึกให้การกู้คืนข้อผิดพลาดได้ดีขึ้นทำให้มั่นใจได้ว่าบันทึกของคุณจะถูกเขียนได้สำเร็จแม้ในกรณีที่เกิดความล้มเหลวอย่างรุนแรง

ดังนั้นคำถามจะกลายเป็นเมื่อใดที่จะเพิ่มระบบการบันทึกในตอนแรก นี่เป็นการเรียกการตัดสิน: คุณไม่ต้องการที่จะเพิ่มเร็วเกินไปเพียงเพื่อจะพบว่าคุณไม่จำเป็นต้องใช้มัน คุณไม่ต้องการเพิ่มมันสายเกินไปและทำงานมากเกินไปที่จะแปลงจากโซลูชัน ad-hoc ของคุณ

หากคุณค้นพบว่าคุณกำลังทำการล็อกด้วยจำนวนมากแสดงprintln()ว่าโค้ดเบสของคุณพยายามบอกคุณว่ามันกำลังเจ็บปวด ณ จุดนี้มันคุ้มค่าที่จะลงทุนในการบันทึกที่เหมาะสม

ฉันมักจะมีปัญหาที่ System.out.print ใช้ codepage "ระบบเริ่มต้น" ซึ่งมักจะเป็น UTF-8 ภายใต้ Linux แต่บางสิ่ง MS crapped ใน Windows

สิ่งนี้อาจนำไปสู่ตัวอักษรยูนิโค้ดที่พิมพ์หรือไม่ถูกต้องไปยังหน้าจอทั้งนี้ขึ้นอยู่กับตำแหน่งที่โปรแกรมทำงาน

ฉันจึงชอบ PrintWriter ที่กำหนดเองมากกว่า System.out

มันไม่เลวเลย ความคิดอาจเกิดจากข้อเท็จจริงที่ว่ามันง่ายมากและไม่ซับซ้อนเท่าการใช้เฟรมเวิร์กการบันทึกเฉพาะในแอปพลิเคชันของคุณ

อย่างไรก็ตามนี่ไม่ได้เป็นการบอกว่ามันเป็นแนวทางที่ไม่ถูกต้อง ฉันใช้มันหลายครั้งเพื่อตรวจสอบการไหลเวียนของแอปพลิเคชั่นหลังจากเขียนโปรแกรม hijinks magic voodoo สีดำ

ไม่มีอะไรผิดปกติกับการใช้มันจะช่วยให้คุณคิดออกว่าเกิดอะไรขึ้น

แต่ถ้าเพื่อนร่วมงาน / devs / เครื่องมืออื่น ๆ ของคุณน่าหัวเราะคุณสามารถใช้Loggerหรือเริ่มทดสอบJunit ได้ตลอดเวลา !

ปัญหาที่ใหญ่ที่สุดที่เกิดขึ้นกับ Occational System.out.println อย่างที่ฉันเห็นคือมันเป็น "นิสัยที่ไม่ดี (tm)" หากคุณพบว่าตัวเองกำลังทำสิ่งนี้อยู่คุณอาจจะสามารถปรับปรุงประสิทธิภาพของตัวคุณเองได้โดยการใช้ตัวดีบักเกอร์ตัวโปรด

นอกจากนี้ด้วยดีบักเกอร์คุณทราบได้อย่างชัดเจนว่าเบรกพอยต์จะไม่ลื่นไหลในรหัสการผลิตของคุณในขณะที่อาจมี System.out.println

ในบันทึกย่อด้านข้างหากคุณเพียงแค่ทำการทดสอบอย่างรวดเร็วและยืนยันว่าไม่ได้ใช้ดีบักเกอร์ฉันคิดว่า System.out.println นั้นดีกว่าการใช้เฟรมเวิร์กการบันทึกเนื่องจากหากคุณทิ้งข้อความคำสั่ง log.debug ไว้โดยไม่ตั้งใจเมื่อคุณ เสร็จแล้วมันยากที่จะหยั่งรากออก

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

อันตรายของการลืมที่จะลบออกอาจเป็นสาเหตุที่ไม่เหมาะสม