คำถามติดแท็ก coding-standards

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

16
บล็อกอื่นเพิ่มความซับซ้อนของรหัสหรือไม่ [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา นี่คือมากตัวอย่างง่าย นี่ไม่ใช่คำถามเฉพาะภาษาและฉันขอให้คุณเพิกเฉยต่อวิธีการอื่น ๆ ที่สามารถเขียนฟังก์ชันและการเปลี่ยนแปลงที่เกิดขึ้นได้ . สีเป็นประเภทที่ไม่ซ้ำกัน string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } else { return "No you can't"; } } ผู้คนจำนวนมากที่ฉันได้พบ ReSharper และผู้ชายคนนี้ (ซึ่งความคิดเห็นเตือนฉันฉันกำลังมองหาที่จะถามในขณะนี้) จะแนะนำการ refactoring รหัสเพื่อลบelseบล็อกออกจากนี้: (ฉันจำไม่ได้ว่าคนส่วนใหญ่พูดอะไรฉันอาจไม่ได้ถามอย่างอื่น) string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } return …

3
“ สถานะ” หรือ“ สถานะ”? เมื่อใดที่ชื่อตัวแปรควรมีคำว่า "state" และเมื่อใดที่ชื่อตัวแปรควรมีคำว่า "สถานะ" แทน? [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา การอ่านรหัสและการอภิปรายเกี่ยวกับรหัสฉันมักจะเห็นคำว่า "สถานะ" และ "สถานะ" ใช้แทนกันได้ แต่มีแนวโน้มต่อไปนี้: เมื่อตัวแปรมีค่าไว้เพื่อแสดงว่ามีบางสิ่งอยู่ในสถานะหนึ่งชื่อของตัวแปรนั้นมักจะไม่ประกอบด้วยคำว่า "สถานะ" หรือตัวย่อของตัวแปรนั้น อย่างไรก็ตามเมื่อค่าส่งคืนของฟังก์ชันทำหน้าที่เพื่อระบุสถานะบางอย่างเรามักจะเรียกค่านั้นว่า "รหัสสถานะ" และเมื่อค่านั้นถูกเก็บไว้ในตัวแปรตัวแปรนี้มักมีชื่อว่า "สถานะ" หรือบางอย่างที่คล้ายกัน การแยกนั้นเป็นสิ่งที่ดีฉันเดา แต่เมื่อตัวแปรดังกล่าวเป็นจริงและตัวเลือกจะต้องเลือกที่เกี่ยวข้องกับความซับซ้อนในทางที่ผิดของภาษาอังกฤษ (หรือภาษามนุษย์โดยทั่วไป) อะไรคือรหัสมาตรฐานหรือแบบแผนที่เด่นชัดเมื่อพูดถึงการแก้ปัญหาระหว่างทั้งสอง หรือควรหลีกเลี่ยงหนึ่งในสองอย่างนี้เสมอ? คำถาม english.stackexchangeนี้เกี่ยวข้องด้วยฉันคิดว่า

1
แบบแผนการใช้อักษรตัวพิมพ์ใหญ่สำหรับฟิลด์ที่มีการป้องกัน C #
การใช้อักษรตัวพิมพ์ใหญ่สำหรับชื่อฟิลด์ที่ได้รับการป้องกันใน C # คืออะไร มัน _myVar (เช่นฟิลด์ส่วนตัว) หรือ MyVar (ชอบคุณสมบัติ) หรือไม่

9
วิธีนำโครงการพัฒนาโดยปราศจากความเชี่ยวชาญด้านเทคนิค
ฉันได้รับการพัฒนาบนมืออาชีพของฉันทั้งหมดและรักการทำงานกับรหัส ฉันไม่พอใจผู้นำทีมที่มีความเชี่ยวชาญเพียงเล็กน้อยหรือไม่มีเลยเกี่ยวกับเทคโนโลยีเฉพาะและยังยืนยันในการใช้งานบางอย่าง ตอนนี้ฉันพบว่าตัวเองอยู่อีกด้านหนึ่งของกระจกมอง ฉันเป็นผู้นำในการพัฒนาลูกค้าอ้วนที่จะนำไปใช้ใน C # อย่างไรก็ตามความเชี่ยวชาญของฉันคือการสร้างเว็บแอปพลิเคชัน Java ในขณะที่ฉันรู้ว่าฉันสามารถใช้ประโยชน์จากรูปแบบการออกแบบและกระบวนทัศน์ OO ในภาษาใด ๆ ฉันก็หลงทางเมื่อพูดถึงมาตรฐานการเข้ารหัสเครื่องมือวงจรชีวิตโครงการและขั้นตอนการเผยแพร่ / แจกจ่าย ฉันไม่สงสัยเลยว่าฉันจะสามารถรับพื้นฐานได้ภายในหนึ่งหรือสองเดือน แต่มีประสบการณ์บางอย่างที่สามารถรวบรวมได้ด้วยเวลาเท่านั้น ฉันควรทำอย่างไรและฉันจะหลีกเลี่ยงการเป็นผู้นำโครงการที่ฉันเกลียดเมื่อฉันพัฒนาได้อย่างไร

13
การใช้ #define เหมาะสมเพื่อให้การพิมพ์รหัสซ้ำง่ายขึ้นหรือไม่
มีความเห็นว่าการใช้ #define เพื่อกำหนดรหัสเต็มบรรทัดสำหรับการทำให้โค้ดง่ายขึ้นหรือไม่นั้นเป็นวิธีปฏิบัติที่ดีหรือไม่ดี? ตัวอย่างเช่นหากฉันต้องการพิมพ์คำจำนวนมากด้วยกันฉันจะรู้สึกรำคาญเมื่อพิมพ์ << " " << เพื่อแทรกช่องว่างระหว่างคำในคำสั่ง cout ฉันทำได้ #define pSpace << " " << และประเภท cout << word1 pSpace word2 << endl; สำหรับฉันแล้วสิ่งนี้ไม่ได้เพิ่มหรือลบออกจากความชัดเจนของรหัสและทำให้การพิมพ์ง่ายขึ้นเล็กน้อย มีอีกหลายกรณีที่ฉันสามารถนึกถึงว่าการพิมพ์จะง่ายกว่าที่ไหนมากสำหรับการดีบัก ความคิดใด ๆ เกี่ยวกับเรื่องนี้? แก้ไข: ขอบคุณสำหรับคำตอบที่ยอดเยี่ยม! คำถามนี้เพิ่งมาถึงฉันหลังจากทำการพิมพ์ซ้ำ ๆ จำนวนมาก แต่ฉันไม่เคยคิดเลยว่าจะมีมาโครตัวอื่นที่ใช้สับสนน้อยกว่า สำหรับผู้ที่ไม่ต้องการอ่านคำตอบทั้งหมดทางเลือกที่ดีที่สุดคือการใช้มาโครของ IDE เพื่อลดการพิมพ์ซ้ำ

8
'แก้ไขโดย' ความคิดเห็นแบบอินไลน์เป็นบรรทัดฐานในร้านค้าที่ใช้การควบคุมการแก้ไขหรือไม่
ผู้พัฒนาระดับสูงในร้านของเรายืนยันว่าเมื่อใดก็ตามที่มีการแก้ไขโค้ดโปรแกรมเมอร์ที่รับผิดชอบควรเพิ่มความคิดเห็นแบบอินไลน์ที่ระบุสิ่งที่เขาทำ ความคิดเห็นเหล่านี้มักจะดูเหมือน// YYYY-MM-DD <User ID> Added this IF block per bug 1234. เราใช้ TFS เพื่อควบคุมการแก้ไขและฉันคิดว่าความคิดเห็นของการเรียงลำดับนี้มีความเหมาะสมมากขึ้นในฐานะบันทึกการเช็คอินแทนที่จะเป็นเสียงอินไลน์ TFS ยังให้คุณเชื่อมโยงการเช็คอินกับบั๊กตั้งแต่หนึ่งข้อขึ้นไป ไฟล์คลาสที่เก่าและมีการแก้ไขบ่อยครั้งของเราบางคนดูเหมือนว่าพวกเขามีอัตราส่วนความคิดเห็นต่อ LOC ใกล้ถึง 1: 1 ในสายตาของฉันความคิดเห็นเหล่านี้ทำให้รหัสยากต่อการอ่านและเพิ่มค่าเป็นศูนย์ นี่เป็นวิธีปฏิบัติที่เป็นมาตรฐาน (หรืออย่างน้อยสามัญ) ในร้านค้าอื่นหรือไม่?

10
ความขัดแย้งกับโครงการนำมาตรฐานการเข้ารหัส [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้นี้ ปิดให้บริการใน3 ปีที่ผ่านมา ดังนั้นฉันจึงกำลังทำงานในโครงการใหม่พร้อมกับหัวหน้าโครงการของฉันในช่วง 1 ปีที่ผ่านมา ตอนแรกเรามีโปรเจคย่อยของเราที่อาศัยอยู่ใน repos git แยกกันฉันมีปฏิสัมพันธ์กับโค้ดของเขาน้อยดังนั้นกลิ่นโค้ดไม่ได้รบกวนฉัน ประมาณ 6 เดือนต่อมาฉันเริ่มรักษาและเพิ่มฟีเจอร์ในโค้ดของเขาเนื่องจากฉันมีบทบาทมากขึ้นในโครงการ ตอนนี้ฉันเป็นผู้พัฒนานำสำหรับทั้งโครงการย่อย (ทีมกำลังจะเติบโต; เขายังอยู่เหนือฉัน) สิ่งเหล่านี้รบกวนฉันและฉันต้องการดูแลพวกเขา แต่ถูกปฏิเสธ: ไม่มีเครื่องหมายปีกกา, ฟังก์ชันตัวพิมพ์ใหญ่, การใช้คำพูดแบบผสม (ตรรกะดับเบิลและเดี่ยวที่มีลอจิกซ่อน), ไม่ใช้ ===, คลาสเรียนขนาดใหญ่พร้อมฟังก์ชั่นมากมาย บรรทัดล่างอาจจะดีกว่า พึ่งพาตัวเลือกของ PHP เพื่อปิดการแจ้งเตือน / คำเตือน รหัสเต็มไปด้วยการใช้ตัวแปรและคีย์อาร์เรย์ ตัวแปรถูกนิยามไว้ภายใน ifs ข้อโต้แย้งเกี่ยวกับปัญหา 2 ข้อข้างต้น: ไม่ต้องการบังคับใช้รูปแบบการเข้ารหัสกับผู้คน ถือได้ว่าเป็นคุณสมบัติภาษาซึ่งยืมตัวเองเพื่อรหัสสั้น / มีประสิทธิภาพมากขึ้น ฉันเชื่อว่ากฎบางอย่างจำเป็นต้องมีและรหัสควรมีการป้องกัน ฉันเสนอให้ใช้การตั้งค่าเริ่มต้นของ PHPS สำหรับการจัดรูปแบบใช้เครื่องหมายปีกกาและการตั้งชื่อที่ชุมชนยอมรับ ฉันต้องการจัดแนวทั้งสองโครงการให้ใช้แนวทางเดียวกันเนื่องจากแยกกันไม่ออก …

5
มันหมายความว่าอย่างไรเมื่อเทคโนโลยีบางอย่างเป็น "มาตรฐาน"?
ฉันเริ่มเรียนรู้ Java EE 7 และฉันมักเจอคำว่า "มาตรฐาน" บ่อยครั้งและฉันก็ไม่เข้าใจว่ามันแปลว่าอะไร ตัวอย่างเช่นนี่คือใบเสนอราคาจากหนังสือเล่มนี้ : ตรงกันข้ามกับ SOAP และ WS- * stack ซึ่งขึ้นอยู่กับมาตรฐาน W3C REST ไม่มีมาตรฐานและเป็นเพียงรูปแบบของสถาปัตยกรรมที่มีหลักการออกแบบ แอปพลิเคชัน REST ใช้มาตรฐานอื่น ๆ มากมาย: HTTP, URI, URL ... ฉันมีความคิดเกี่ยวกับสิ่งที่อาจหมายถึง แต่ฉันไม่แน่ใจ คำอธิบายที่ดีที่สุดที่ฉันได้เจอคือความหมายจากที่นี่

6
การตรวจสอบความถูกต้องของพารามิเตอร์อินพุตในตัวเรียก: การทำสำเนารหัสหรือไม่
สถานที่ที่ดีที่สุดในการตรวจสอบความถูกต้องของพารามิเตอร์อินพุตของฟังก์ชัน: ในผู้โทรเข้าหรือในฟังก์ชั่นของตัวเอง? เนื่องจากฉันต้องการปรับปรุงรูปแบบการเข้ารหัสของฉันฉันพยายามค้นหาแนวทางปฏิบัติที่ดีที่สุดหรือกฎบางอย่างสำหรับปัญหานี้ เมื่อไรและอย่างไรดีกว่า ในโครงการก่อนหน้าของเราเราใช้ในการตรวจสอบและปฏิบัติต่อทุกพารามิเตอร์อินพุตภายในฟังก์ชั่น (ตัวอย่างเช่นถ้ามันไม่เป็นโมฆะ) ตอนนี้ฉันได้อ่านที่นี่ในคำตอบบางอย่างและในหนังสือเล่มโปรแกรมเมอร์ Pragmatic ว่าการตรวจสอบพารามิเตอร์อินพุตเป็นความรับผิดชอบของผู้โทร ดังนั้นหมายความว่าฉันควรตรวจสอบพารามิเตอร์อินพุตก่อนที่จะเรียกใช้ฟังก์ชัน มีการเรียกใช้ฟังก์ชันทุกที่ และนั่นทำให้เกิดคำถามหนึ่งข้อ: มันไม่ได้สร้างเงื่อนไขการตรวจสอบซ้ำทุกที่ที่มีการเรียกใช้ฟังก์ชันหรือไม่ ฉันไม่ได้สนใจเพียงแค่ในเงื่อนไขที่เป็นโมฆะ แต่ในการตรวจสอบตัวแปรอินพุตใด ๆ (ค่าลบเพื่อsqrtฟังก์ชั่นหารด้วยศูนย์การรวมรัฐและรหัสไปรษณีย์ผิดหรืออย่างอื่น) มีกฎบางอย่างในการตัดสินใจว่าจะตรวจสอบสภาพอินพุตอย่างไร ฉันกำลังคิดถึงข้อโต้แย้งบางอย่าง: เมื่อการรักษาของตัวแปรที่ไม่ถูกต้องอาจแตกต่างกันเป็นสิ่งที่ดีในการตรวจสอบในด้านของผู้โทร (เช่นsqrt()ฟังก์ชั่น - ในบางกรณีฉันอาจต้องการที่จะทำงานกับจำนวนที่ซับซ้อนดังนั้นฉันปฏิบัติต่อเงื่อนไขในการโทร) เมื่อเงื่อนไขการตรวจสอบเหมือนกันในผู้โทรทุกคนควรตรวจสอบภายในฟังก์ชั่นเพื่อหลีกเลี่ยงการซ้ำซ้อน การตรวจสอบความถูกต้องของพารามิเตอร์อินพุตในตัวเรียกเกิดขึ้นเพียงครั้งเดียวก่อนที่จะเรียกใช้ฟังก์ชันจำนวนมากด้วยพารามิเตอร์นี้ ดังนั้นการตรวจสอบความถูกต้องของพารามิเตอร์ในแต่ละฟังก์ชั่นจึงไม่มีประสิทธิภาพ วิธีการแก้ปัญหาที่เหมาะสมขึ้นอยู่กับกรณีเฉพาะ ฉันหวังว่าคำถามนี้จะไม่ซ้ำกันฉันค้นหาปัญหานี้และฉันพบคำถามที่คล้ายกัน แต่พวกเขาไม่ได้พูดถึงกรณีนี้อย่างแน่นอน

7
ใน C และ C ++ วิธีการใดที่สามารถป้องกันการใช้งานมอบหมาย (=) โดยไม่ได้ตั้งใจโดยที่จำเป็นต้องมีความเท่าเทียมกัน (==)
ใน C และ C ++ มันง่ายมากที่จะเขียนโค้ดต่อไปนี้พร้อมกับข้อผิดพลาดร้ายแรง char responseChar = getchar(); int confirmExit = 'y' == tolower(responseChar); if (confirmExit = 1) { exit(0); } ข้อผิดพลาดคือคำสั่ง if ควรได้รับ: if (confirmExit == 1) ดังที่เขียนไว้มันจะออกทุกครั้งเนื่องจากการกำหนดconfirmExitตัวแปรเกิดขึ้นจากนั้นconfirmExitจะถูกใช้เป็นผลลัพธ์ของการแสดงออก มีวิธีที่ดีในการป้องกันข้อผิดพลาดประเภทนี้หรือไม่?

10
ลักษณะการเขียนโปรแกรมที่ดีมีความสำคัญต่อการตัดสินใจจ้างโปรแกรมเมอร์หรือไม่ [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว แม้ในฐานะนักเรียนฉันก็ขอให้ตรวจสอบรหัสของโปรแกรมเมอร์ที่มี (ไม่) ผ่านการทดสอบ (สร้างรายการหมายเลขฟีโบนักชีบน Android) ในขณะที่ฉันเข้มงวดมากในการเข้ารหัสรูปแบบฉันเพิ่งอ่านเกี่ยวกับใครบางคน "บล็อก" สไตล์ใช้ (อ่านความคิดเห็น!) ในตำแหน่งของฉันฉันจะไม่แนะนำให้จ้างผู้ชายที่ใช้สไตล์แบบนี้ รหัสนี้ตรงกันข้ามกับรูปแบบการเข้ารหัสที่ใช้ใน บริษัท ของฉันอย่างสมบูรณ์ ในขณะที่ค้นหาสไตล์การเขียนโปรแกรมและวิธีการจัดการกับการขาดมันฉันอยากรู้เกี่ยวกับสิ่งหนึ่ง: ฉันควรจ้างผู้ชายที่จะมีปัญหาร้ายแรง ปรับรูปแบบการเข้ารหัสที่ใช้ใน บริษัท ? กรุณา: นี่ไม่ควรเป็นการอภิปรายเกี่ยวกับรูปแบบการเข้ารหัสโดยทั่วไปและดีกว่า มันเกี่ยวกับความสำคัญของรูปแบบการเข้ารหัสสำหรับการตัดสินใจจ้างใครบางคน! ข้อมูลมากกว่านี้: ฉันไม่ใช่คนที่ตัดสินใจได้ฉันแค่ให้ความเห็นตามรหัส คนที่แต่งตัวประหลาดต้องผ่านการสัมภาษณ์ที่หัวของเราตรวจสอบสิ่งที่อ่อนนุ่มทักษะ หากเขาผ่านสิ่งนี้ไปเขาจะต้องผ่านการทดสอบทักษะเล็ก ๆ น้อย ๆ ของเราและนั่นคือที่บางครั้งฉันถูกขอให้ตรวจสอบรหัสที่เขียน ฉันไม่ได้อยู่ในตำแหน่งที่จะบอกว่าใช่หรือไม่ ฉันแค่ต้องการทราบว่ารูปแบบการเข้ารหัสที่สำคัญสำหรับการตรวจสอบของฉัน ...

5
การสร้างเอกสารมาตรฐานการเข้ารหัส
ฉันทำงานใน บริษัท ระบบควบคุมซึ่งงานหลักคือSCADAและPLCพร้อมกับระบบควบคุมอื่น ๆ การพัฒนาซอฟต์แวร์ไม่ใช่สิ่งที่ บริษัท ทำจริงๆนอกเหนือจากที่นี่และที่นั่นจนกระทั่งมีการตัดสินใจที่จะสร้างการจัดการโครงการภายในและระบบการประเมินผล โครงการนี้ดำเนินการโดยผู้ที่มาที่นี่ในฐานะผู้ใช้ซอฟต์แวร์ แต่เดิมและเราส่วนใหญ่เป็นผู้น้อย โครงการเริ่มจากเล็กดังนั้นเราจึงบันทึกเฉพาะสิ่งต่าง ๆ เช่นการออกแบบสิ่งฐานข้อมูลเป็นต้น แต่เราไม่เคยเห็นด้วยกับรูปแบบการเข้ารหัส / อนุสัญญา เราเริ่มใช้StyleCopเพื่อให้แน่ใจว่าเรามีรหัสที่ดี แต่ฉันรู้สึกว่าเราจำเป็นต้องมีเอกสารอย่างเป็นทางการสำหรับการเข้ารหัสอนุสัญญา / การปฏิบัติเพื่อให้เราสามารถดำเนินการต่อในมาตรฐานที่ดีและหากมีงานพัฒนาที่สำคัญอีกต่อไปในอนาคต มีแผ่นฐานที่ดี ปัญหานั้นอยู่ที่ฉันไม่ทราบวิธีการร่างเอกสารสำหรับการเข้ารหัสการประชุมและมาตรฐานทั้งหมดที่ฉันคิดว่าเป็นตัวอย่างของการปฏิบัติที่ดีและไม่ดี (ตัวอย่างเช่นกรณีอูฐเมื่อตั้งชื่อตัวแปรหลีกเลี่ยงสัญกรณ์ฮังการี ฯลฯ ) เราทุกคน โปรแกรมเมอร์ที่เก่งพอสมควร (ชัด) แต่เราก็ไม่มีกฎบัตรสำหรับเนื้อหาประเภทนี้ คำถามของฉันคืออะไรประเด็นสำคัญและเนื้อหาของเอกสารมาตรฐานการเข้ารหัสที่ดีมีอะไรบ้าง

2
ตอนนี้ไม่ใช่ว่าการประกาศเมธอดทั้งหมดใน Java Interface นั้นเป็นนามธรรมสาธารณะควรจะประกาศเมธอดด้วยตัวดัดแปลงเหล่านี้หรือไม่?
เริ่มต้นด้วย Java 8 defaultมีการนำวิธีการมาใช้ในอินเตอร์เฟส ได้อย่างมีประสิทธิภาพที่นี้หมายถึงว่าไม่ทุกวิธีการในการให้มีinterfaceabstract เริ่มต้นด้วย Java 9 (อาจ) privateวิธีการจะได้รับอนุญาต ซึ่งหมายความว่าไม่ทุกวิธีการในการให้มีinterfacepublic abstract คำถาม "ควรประกาศวิธีการในส่วนต่อประสาน Java โดยมีหรือไม่มีpublicตัวแก้ไขการเข้าถึงหรือไม่" ถูกถามที่ Stack Overflow ที่/programming/161633/should-methods-in-a-java-interface-be-declared-with-or-without-a-public-access-m คำตอบส่วนใหญ่แย้งว่าpublic abstractไม่ควรใช้เพราะไม่มีวิธีการใดที่interfaceสามารถเป็นอย่างอื่นpublic abstractได้ นี่ไม่ใช่กรณีอีกต่อไป ดังนั้นด้วยคุณสมบัติใหม่ของอินเทอร์เฟซเหล่านี้ควรใช้public abstractคีย์เวิร์ดในการประกาศเมธอดของอินเตอร์เฟส Java หรือไม่? ในสภาพแวดล้อมเฉพาะของฉันเราจะมีคนที่มีประสบการณ์วิศวกรซอฟต์แวร์ แต่ไม่เคยมีประสบการณ์ใน Java อ่านโค้ด Java เป็นครั้งคราว ฉันรู้สึกว่าการละทิ้งpublic abstractคำหลักจะสร้างจุดสับสนเพิ่มเติมสำหรับผู้ที่ไม่คุ้นเคยกับประวัติว่าอินเตอร์เฟสมีกฎแตกต่างกันสำหรับการใช้คำหลักเหล่านี้อย่างไร

3
เมื่อใดจึงเหมาะสมที่จะใช้สีในแอปพลิเคชันบรรทัดคำสั่ง
ขณะนี้ฉันมีการประยุกต์ใช้บรรทัดคำสั่งใน Cbtcwatchเรียกว่า แต่ก็มี-Cตัวเลือกที่จะสามารถได้รับเป็นอาร์กิวเมนต์ที่เปรียบเทียบราคาปัจจุบันของ Bitcoin -Sมีราคาที่ถูกเก็บไว้ก่อนกับหนึ่ง ตัวอย่างเอาต์พุตที่มีตัวเลือกนี้คือ: $ btcwatch -vC # -v = verbose buy: UP $ 32.000000 USD (100.000000 -> 132.000000) sell: UP $ 16.000000 USD (100.000000 -> 116.000000) ขึ้นเขียงว่าจะใช้สีสำหรับUPหรือDOWNสตริง (สีเขียวและสีแดงตามลำดับ) แอปพลิเคชันบรรทัดคำสั่งส่วนใหญ่ที่ฉันรู้จัก (นอกเหนือจากคอมไพล์) อยู่ห่างจากสีในเอาต์พุตของพวกเขา ในความปรารถนาของฉันที่btcwatchจะมองและค่อนข้าง "มาตรฐาน" (การใช้getopt, Makefiles ฯลฯ ) ฉันไม่แน่ใจว่าสีจะออกนอกสถานที่ในสถานการณ์นี้หรือไม่

3
ใครสามารถอธิบายแบบแผนการเข้ารหัสของ C # ให้ฉันได้บ้าง
ฉันเพิ่งเริ่มทำงานกับ Unity3D และสคริปต์เป็นหลักด้วย C # ตามปกติแล้วฉันจะเขียนโปรแกรมใน Java ความแตกต่างก็ไม่ดีนัก แต่ฉันยังคงเรียกใช้หลักสูตรความผิดพลาดเพื่อให้แน่ใจว่าฉันกำลังอยู่ในเส้นทางที่ถูกต้อง อย่างไรก็ตามความอยากรู้ที่ยิ่งใหญ่ที่สุดของฉันกับ C # คือมันใช้อักษรตัวแรกของชื่อเมธอด (เช่น Java: getPrime()C #: GetPrime()aka: Pascal Case) มีเหตุผลที่ดีสำหรับสิ่งนี้หรือไม่? ฉันเข้าใจจากหน้าหลักสูตรความผิดพลาดที่ฉันอ่านซึ่งเห็นได้ชัดว่ามันเป็นแบบแผนสำหรับ. Net และฉันไม่มีทางที่จะเปลี่ยนแปลงมัน แต่ฉันอยากรู้ว่าทำไมมันถึงทำแบบนี้เมื่อเทียบกับกรณีอูฐปกติ (ญาติ?) ที่พูดว่า Java ใช้ หมายเหตุ: ฉันเข้าใจว่าภาษาต่าง ๆ มีระเบียบการเข้ารหัสของตนเอง (วิธีการ Python เป็นตัวพิมพ์เล็กทั้งหมดซึ่งใช้กับคำถามนี้ด้วย) แต่ฉันไม่เคยเข้าใจเลยว่าทำไมมันถึงไม่ทำเป็นมาตรฐาน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.