การเขียน“ รหัสดี” หมายความว่าอย่างไร [ปิด]


41

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

ปรากฏว่าคำว่า "รหัสที่ดี" และ "รหัสไม่ดี" เป็นอัตนัย เนื่องจากฉันมีมุมมองเดียวจึงอาจแตกต่างจากมุมมองของคนอื่นมาก

ดังนั้นการเขียน "รหัสที่ดี" หมายความว่าอย่างไร "รหัสดี" คืออะไร?


15
รหัสที่ดีคือถ้าคุณดูหลังจากสองปีและความคิดแรกของคุณไม่ใช่ "Dude, wtf"
Bobby

คำตอบ:


91

โคเดอร์ที่ดีเป็นเหมือนผู้เล่นพูลที่ดี

เมื่อคุณเห็นผู้เล่นมืออาชีพในสระในตอนแรกคุณอาจไม่ประทับใจ: "แน่นอนพวกเขามีลูกบอลทั้งหมดเข้ามา แต่พวกเขามีช็อตง่ายเท่านั้น!" นี่เป็นเพราะเมื่อผู้เล่นพูลทำช็อตเธอไม่คิดว่าลูกจะใส่ในกระเป๋าไหนเธอก็คิดด้วยว่าลูกคิวจะจบลงที่ใด การตั้งค่าสำหรับช็อตถัดไปนั้นใช้ทักษะและการฝึกฝนอย่างมาก แต่ก็หมายความว่ามันดูง่าย

ตอนนี้นำอุปมานี้เพื่อรหัสcoder ดีเขียนรหัสที่ดูเหมือนว่ามันเป็นเรื่องง่ายและตรงไปตรงมาจะทำอย่างไร ตัวอย่างมากมายจาก Brian Kernighan ในหนังสือของเขาเป็นไปตามรูปแบบนี้ ส่วนหนึ่งของ "เคล็ดลับ" กำลังจะมาถึงด้วยแนวความคิดที่ถูกต้องของปัญหาและการแก้ไขของตน เมื่อเราไม่เข้าใจปัญหาที่ดีพอเรามีแนวโน้มที่จะแก้ปัญหาที่ซับซ้อนเกินไปและเราจะไม่เห็นความคิดรวม

ด้วยแนวคิดที่เหมาะสมของปัญหาคุณจะได้รับทุกสิ่ง: ความสามารถในการอ่าน, การบำรุงรักษา, ประสิทธิภาพและความถูกต้อง เนื่องจากวิธีการแก้ปัญหาดูเหมือนตรงไปตรงมาจึงอาจมีความคิดเห็นน้อยลงเนื่องจากคำอธิบายเพิ่มเติมไม่จำเป็น โคเดอร์ที่ดียังสามารถมองเห็นวิสัยทัศน์ระยะยาวของผลิตภัณฑ์และสร้างแนวความคิดตามความเหมาะสม


10
"รหัสที่ดีเขียนโค้ดที่ดูเหมือนง่ายและตรงไปตรงมา" << แน่นอน! ฉันคิดว่านี่เป็นเพราะคนมักจะคิดว่า coder ที่ดีคือคนที่สามารถเขียนแฮ็ก "ฉลาด" มาก หากรหัสนั้นสะอาดและไม่ "ฉลาด" มากเกินไปมันจะต้องง่ายใช่มั้ย
hasen

3
2 เซนต์ของฉัน: เมื่อคุณมีภาษาที่มีการปรับโครงสร้างอัตโนมัติแบบง่าย - Java และ C # เป็นสองตัวอย่างที่ฉันรู้จักดีที่สุด - มันง่ายที่จะย้ายไปใช้โค้ดที่ดีซ้ำ ๆ ไม่อย่างนั้นคุณต้องคิดให้ดีตั้งแต่แรก แต่มีปัญหาไก่ไข่อยู่ตรงนั้น
Dan Rosenstark

3
อัลกอริทึมบางอย่างมีความซับซ้อนภายใน coder ที่ดีควรจะมีปัญหาการเขียนพวกเขาเมื่อพวกเขาถูกจริงๆจำเป็น - และทำให้พวกเขาเป็นที่อ่านได้ที่เป็นไปได้
J-16 SDiZ

2
@hasenj: ใช่นี่เป็นเพราะบทแทรกนี้: คนที่โง่เขียนโค้ดที่คอมไพเลอร์เข้าใจ คนฉลาดเขียนรหัสโง่คนเข้าใจ
v.oddou

49

WTF ต่อนาที

( ต้นฉบับ )


แก้ไข: แนวคิดพื้นฐานคือ "คุณภาพของโค้ด" ไม่สามารถนำไปใช้กับกฎได้เช่นเดียวกับที่คุณไม่สามารถใส่ "ศิลปะที่ดี" หรือ "บทกวีที่ดี" ลงในกฎเพื่อให้คอมพิวเตอร์สามารถระบุว่า "ใช่ศิลปะที่ดี" หรือ "ไม่บทกวีไม่ดี" ในปัจจุบันวิธีเดียวคือการดูว่าโค้ดที่เข้าใจได้ง่ายคือมนุษย์คนอื่น ๆ ได้อย่างไร


1
เราติดสิ่งนี้บนไวท์บอร์ดในที่ทำงาน :-)
ไม่มีใคร

1
@Cape Cod Gunny อยู่ในหนังสือของลุงบ๊อบด้วย
mlvljr

2
นอกเหนือจากการเป็นการ์ตูนที่ยอดเยี่ยมฉันคิดว่ามันเป็นจุดที่ดีจริงๆ - รหัสที่ดีคือรหัสที่คนอื่น ๆ พอใจในการอ่านและบำรุงรักษา
FinnNk

1
จริงรหัสที่ดีคือรหัสใด ๆ ที่ไม่เลว เช่นมันยากที่จะกำหนดรหัสที่ดีมันง่ายกว่าที่จะกำหนดรหัสที่ไม่ดี
Ernelli

5
ฉันมักจะพบว่า "WTF?" เหล่านั้นในการประชุมโค้ดที่ดีนั้นมีการติดตามในไม่ช้าโดย "Oooooh โอเค ... ฉันเห็นสิ่งที่คุณทำอยู่แล้ว"
AndrewKS

7

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

"WTF's per minutes" (ด้านบน) เป็นจริง แต่เป็นเพียงข้อพิสูจน์ของกฎทั่วไปที่มากกว่า WTFs ยิ่งเข้าใจยิ่งช้า


1
@rmx: กำหนด "ทำงานได้ดี"
mojuba

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

2
@rmx: แต่การปราศจากข้อบกพร่องนั้นบอกเป็นนัยใช่มั้ย หากรหัสของคุณทำงานไม่ถูกต้องแสดงว่าไม่ใช่รหัส (ยัง)
mojuba

4
@rmx: ที่จริงแล้วไม่มี หากรหัสของคุณเข้าใจง่ายสรุปได้ว่าเข้าใจได้ง่ายว่าทำงานได้ไม่ดี OTOH ถ้ามันยากที่จะเข้าใจมันเป็นการยากที่จะเข้าใจว่ามันทำงานได้หรือไม่
Pillmuncher

2
@rmx: PS ใส่ง่ายๆการลดลงของคุณ () เป็น WTF แบบคลาสสิกและทำให้มันช้าลงความเข้าใจในส่วนของรหัสที่ใช้ฟังก์ชั่นนี้
mojuba

5

คุณรู้ว่าคุณเขียนรหัสที่ดีเมื่อ ...

  1. ลูกค้ามีความสุข
  2. เพื่อนร่วมงานยืมรหัสของคุณเป็นจุดเริ่มต้น
  3. คนใหม่เอี่ยม / สาวเพิ่งบอกให้ทำการปรับเปลี่ยนระบบที่คุณสร้างขึ้นเมื่อ 6 เดือนที่แล้วและเขา / เธอไม่เคยถามคำถามกับคุณ
  4. เจ้านายของคุณขอให้คุณพัฒนาวิดเจ็ตใหม่เพื่อให้ทีมใช้
  5. คุณดูรหัสที่คุณเขียนวันนี้และพูดกับตัวเองว่า "ฉันหวังว่าฉันจะเขียนโค้ดแบบนี้เมื่อสองปีก่อน"

คุณวัดได้อย่างไรว่ารหัสดีหรือไม่ ...

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

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


2
"ลูกค้ามีความสุข" เป็นมุมฉากกับสิ่งนี้

1
@TRA - หากลูกค้ามีความสุขนั่นหมายความว่าคุณเข้าใจความต้องการและจัดหาโซลูชั่นที่พวกเขาคาดหวัง
Michael Riley - AKA Gunny

6
แน่นอน แต่รหัสที่ไม่ดีสามารถทำเช่นเดียวกัน

4

รหัสซึ่งเป็น

  1. ข้อผิดพลาดฟรี

  2. นำมาใช้ใหม่

  3. อิสระ

  4. ซับซ้อนน้อยลง

  5. เอกสารที่ดี

  6. ง่ายต่อการเปลี่ยน

เรียกว่ารหัสที่ดี

โปรแกรมที่ดีทำงานได้อย่างไร้ที่ติและไม่มีข้อบกพร่อง แต่คุณภาพภายในอะไรทำให้เกิดความสมบูรณ์แบบเช่นนั้น? มันไม่มีเรื่องลึกลับเราแค่ต้องการเตือนบางครั้ง ไม่ว่าคุณจะเขียนโค้ดใน C / C ++, C #, Java, Basic, Perl, COBOL หรือ ASM การเขียนโปรแกรมที่ดีทั้งหมดจะแสดงคุณสมบัติที่ได้รับการยอมรับในเวลาเดียวกัน: ความเรียบง่ายการอ่านได้แบบแยกส่วนการออกแบบประสิทธิภาพความสง่างามและความชัดเจน และความชัดเจน

ที่มา: MSDN


ความเรียบง่ายการอ่านความสง่างามและความคมชัดล้วนเป็นสิ่งเดียวกัน Modularity และ layering เป็นเพียงวิธีการทำให้โค้ดของคุณชัดเจนและสง่างาม สิ่งเดียวที่เหลืออยู่ในรายการนั้นคือประสิทธิภาพซึ่งมีความหมายโดยนัยและนอกจากนั้นมันมักจะเป็นเรื่องของการประนีประนอมระหว่างประสิทธิภาพและความชัดเจน
mojuba

ตรวจสอบสิ่งนี้: goo.gl/hdQt8
Chankey Pathak

2
รหัสสามารถปราศจากข้อผิดพลาด?
Casey Patton

ไม่มันไม่สามารถ (ในทางปฏิบัติ)
Chankey Pathak

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

3

มันดูคุ้นเคยไหม?

ฟิลิปส์เปิดโอกาสให้ฉันดูการออกแบบผลิตภัณฑ์ใหม่ ในขณะที่มันพัฒนาขึ้นฉันเริ่มรู้สึกไม่สบายใจมากขึ้นและเริ่มให้ความกังวลกับผู้บังคับบัญชาของฉัน ฉันบอกเขาหลายครั้งว่าการออกแบบนั้นไม่“ สะอาด” และควรจะ“ สวยงาม” ในแบบที่การออกแบบของ Dijkstra นั้นสวยงาม เขาไม่พบว่าสิ่งนี้เป็นความคิดเห็นที่มีประโยชน์ เขาเตือนฉันว่าเราเป็นวิศวกรไม่ใช่ศิลปิน ในใจของเขาฉันแค่แสดงออกถึงรสนิยมของฉันและเขาต้องการที่จะรู้ว่าฉันใช้เกณฑ์อะไรในการตัดสินของฉัน ฉันไม่สามารถบอกเขาได้! เพราะฉันไม่สามารถอธิบายได้ว่ามีการละเมิดหลักการใดความคิดเห็นของฉันก็ถูกเพิกเฉยและงานก็ดำเนินต่อไป การรู้สึกว่าต้องมีวิธีในการอธิบายและให้แรงจูงใจสำหรับ "รสนิยม" ของฉัน ฉันเริ่มพยายามหาหลักการที่จะแยกความแตกต่างของการออกแบบที่ดีออกจากสิ่งที่ไม่ดี วิศวกรสามารถใช้งานได้จริง พวกเขาอาจชื่นชมความงาม แต่พวกเขาแสวงหาประโยชน์ ฉันพยายามค้นหาคำอธิบายว่าทำไม "ความงาม" จึงมีประโยชน์

โปรดดูส่วนที่เหลือที่นี่


1
เนื่องจากลิงก์ในโพสต์ของ @ mlvljr เสียนี่คือลิงก์ไปยังหน้า Google หนังสือ: books.google.co.th/in
balajeerc

@balajeerc ขอบคุณ (ฉันยังคงเชื่อมโยงจึงชี้ไปที่รุ่นสปริงเกอร์เป็นเจ้าภาพของไฟล์ PDF เดียวกัน) :)
mlvljr

1

นอกเหนือจากเกณฑ์คุณภาพรหัสธรรมชาติ (คัดลอก / วางขั้นต่ำไม่มีสปาเก็ตตี้และอื่น ๆ ) รหัสอุตสาหกรรมที่ดีควรมีลักษณะไร้เดียงสาอยู่เสมอและค่อนข้างละเอียดเกินไปเช่น

int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;

ตรงข้ามกับ

Record r = cache.get(i++, false);

แต่do_not_create = falseหมายความว่า“ ผ่านfalseเป็นdo_not_createอาร์กิวเมนต์เพื่อที่จะถูกสร้างขึ้น” หรือ“ ผ่านfalseเป็นdo_createอาร์กิวเมนต์เพื่อที่จะไม่ถูกสร้างขึ้น”? cache.get (key:i, create: false); i += 1;ในภาษาที่คุณสามารถใช้ชื่ออาร์กิวเมนต์ฉันชอบ
PJTraill

1

บางทีคำตอบด้วยการอธิบายสิ่งที่ตรงกันข้ามจะช่วยได้ (รวมทั้งเป็นข้ออ้างที่จะนำXKCD มาไว้ที่นี่)

ข้อความแสดงแทน

รหัสที่ดีคือ

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

ตัวอย่าง ได้แก่

  • Apache Commons
  • กรอบสปริง
  • กรอบการไฮเบอร์เนต

1

ฉันจะไปกับ "บำรุงรักษา"

รหัสทั้งหมดจะต้องมีการรักษา: ไม่จำเป็นต้องมีงานที่ทำยากกว่าที่จำเป็น

หากผู้อ่านไม่เข้าใจข้อกำหนดที่เรียบง่ายนี้หรือต้องการการสะกดคำผู้อ่านนั้นไม่ควรเขียนรหัส ...


1

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

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

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


1

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

แต่ฉันพิจารณา WTF สองประเภท: สิ่งที่คุณสงสัยว่าโปรแกรมเมอร์นั้นดีกว่าการเขียนโปรแกรม 101 หรือไม่และผู้ที่คุณไม่เข้าใจความเป็นอัจฉริยะของรหัสอย่างแน่นอน รหัสบางอย่างอาจดูแปลก ๆ ในตอนแรก แต่จริงๆแล้วมันเป็นทางออกที่สร้างสรรค์มากสำหรับปัญหาที่ยาก ส่วนที่สองไม่ควรนับใน WTF-meter และสามารถหลีกเลี่ยงได้ด้วยความคิดเห็น

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

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

ใช่แล้วการอ่านมีความสำคัญต่อรหัสที่ดี ฉันรู้ว่า adagium ของ Uwe Liggis: การคิดเจ็บและคอมพิวเตอร์ราคาถูก แต่ในสาขาของฉัน (ฟังก์ชั่นเชิงสถิติ) การคำนวณครั้งต่อสัปดาห์และการใช้หน่วยความจำมากกว่า 40 Gb นั้นไม่ถือว่าผิดปกติ ดังนั้นการปรับปรุงความเร็วสองเท่าและหน่วยความจำครึ่งหนึ่งจึงมีค่ามากกว่าการอ่านเพิ่มอีกเล็กน้อย


ไม่มีกฎ / กฎโดยไม่มีข้อยกเว้น
2664856

1
ให้ฉันไม่เห็นด้วยกับความไม่ลงรอยกันของคุณ: คุณบอกว่าในสนามความเร็วของคุณมีความสำคัญมากและบอกว่ามันสำคัญกว่าการอ่าน ฉันไม่เห็นด้วยคุณควรพยายามใช้ความสมดุลที่เหมาะสม หากไม่ต้องการความเร็วเช่นอินเทอร์เฟซระดับสูงคุณอาจต้องการสิ่งที่ง่ายต่อการบำรุงรักษาหากจำเป็นต้องใช้ความเร็วฉันก็เห็นด้วยกับคุณ แทนที่จะใช้กฎอย่างหนักจะดีกว่าหากใช้สามัญสำนึกและคุณควรหลีกเลี่ยงการปรับให้เหมาะสมก่อนวัยอันควร
BlueTrin

@BlueTrin ทำไมไม่ทั้งสมองคอมไพล์ซอร์สโค้ด hi-perf เหล่านั้นและยังจัดทำเอกสารเกี่ยวกับสิ่งที่เกิดขึ้นที่นั่น (มีความคิดเห็น)
mlvljr

1

สำหรับฉันแล้ว ... ฉันรู้ว่าฉันกำลังเขียนโค้ดที่ดีเมื่อผู้ร่วมงานที่ทำงานในโครงการอื่นเข้ามาและสามารถกระโดดเข้ามาและเข้าใจสิ่งที่ฉันกำลังทำอยู่ และแสดงสิ่งที่กำลังทำ
แทนที่จะพูดว่า "เดี๋ยวก่อนนะอะไรนะ! เขากำลังพูดว่า "โอเคฉันเห็นสิ่งที่คุณทำที่นั่น"

รหัสที่ดียังไม่มีวิธีแก้ไขปัญหาส่อเสียดจำนวนมากหรือ 'แฮ็ก' เมื่อคุณเขียนมันคุณจะพูดกับตัวเองว่า "ฉันรู้ว่านี่ไม่ใช่วิธีที่ดีที่จะทำ แต่ฉันแค่ต้องทำอย่างนี้ตอนนี้ฉันจะเตือน ปรับปรุงตัวเองในภายหลัง ... "


1

มีคุณสมบัติมากมายของรหัส 'ดี' แต่ที่สำคัญที่สุดคือ IMHO คือความสามารถในการอ่านและการบำรุงรักษา

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

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

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