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

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

12
ควรเขียนข้อความในปัจจุบันหรือในอดีต? [ปิด]
ปิด . คำถามนี้เป็นคำถามความคิดเห็นตาม ขณะนี้ยังไม่ยอมรับคำตอบ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบได้ด้วยข้อเท็จจริงและการอ้างอิงโดยแก้ไขโพสต์นี้ ปิดให้บริการใน3 ปีที่ผ่านมา ปรับปรุงคำถามนี้ คุณคิดว่าแบบไหนดีกว่าและใช้งานง่ายกว่ากัน? Fixed the XXX bug in YYY Fix the XXX bug in YYY Fixes the XXX bug in YYY Fixing the XXX bug in YYY โปรดระบุเหตุผลของคุณ หมายเหตุฉันขอจากมุมมองทั่วไปของคุณหมายความว่าคุณไม่ควรพยายามเชื่อมโยงสิ่งนี้กับเครื่องมือ svn / cvs หรือภาษาโปรแกรมที่คุณต้องการ แต่คิดว่ามันเป็นสิ่งที่ควร / สามารถนำไปใช้กับเครื่องมือและภาษาโปรแกรมใด ๆ

13
มีหลักการตั้งชื่อมาตรฐานสำหรับองค์ประกอบ XML หรือไม่ [ปิด]
ปิด. คำถามนี้ไม่เป็นไปตามหลักเกณฑ์กองมากเกิน ขณะนี้ยังไม่ยอมรับคำตอบ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Stack Overflow ปิดให้บริการใน3 ปีที่ผ่านมา ปรับปรุงคำถามนี้ มีมาตรฐานใด ๆ สำหรับเอกสาร XML หรือไม่? ตัวอย่างเช่นวิธีใดเป็นวิธีที่ "ดีที่สุด" ในการเขียนแท็ก <MyTag /> <myTag /> <mytag /> <my-tag /> <my_tag /> ในทำนองเดียวกันถ้าฉันมีค่าที่แจกแจงสำหรับแอตทริบิวต์ที่ดีกว่า <myTag attribute="value one"/> <myTag attribute="ValueOne"/> <myTag attribute="value-one"/>

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

9
การเยื้อง #defines
ฉันรู้ว่า#defines ฯลฯ ปกติไม่เคยเยื้อง ทำไม? ฉันกำลังทำงานกับโค้ดบางตัวในขณะนี้ซึ่งมีส่วนผสมที่น่ากลัวของ#defines, #ifdefs, #elses, #endifs และอื่น ๆ ทั้งหมดนี้มักจะผสมกับรหัส C ปกติ การไม่เยื้อง#defines ทำให้อ่านยาก และส่วนผสมของโค้ดเยื้องกับ#defines ที่ไม่เยื้องเป็นฝันร้าย ประโยชน์ของการไม่เยื้อง#defines คืออะไร? มันทำให้ฉันเป็นคนไม่ดีหรือเปล่าถ้าฉันเยื้องย่างเข้าไป นี่ไม่ดีกว่านี้เหรอ? #ifdef SDCC #if DEBUGGING == 1 #if defined (pic18f2480) #define FLASH_MEMORY_END 0x3DC0 #elif defined (pic18f2580) #define FLASH_MEMORY_END 0x7DC0 #else #error "Can't set up flash memory end!" #endif #else #if …

13
วิธีง่ายๆในการสร้างเมทริกซ์ของตัวเลขสุ่ม
ฉันพยายามสร้างเมทริกซ์ของตัวเลขสุ่ม แต่วิธีแก้ปัญหาของฉันยาวเกินไปและดูน่าเกลียด random_matrix = [[random.random() for e in range(2)] for e in range(3)] มันดูโอเค แต่ในการใช้งานของฉันมันเป็น weights_h = [[random.random() for e in range(len(inputs[0]))] for e in range(hiden_neurons)] ซึ่งไม่สามารถอ่านได้อย่างมากและไม่พอดีกับบรรทัดเดียว

8
เหตุใดฟังก์ชันจึงควรมีจุดออกเพียงจุดเดียว [ปิด]
ปิด . คำถามนี้เป็นคำถามความคิดเห็นตาม ขณะนี้ยังไม่ยอมรับคำตอบ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบได้ด้วยข้อเท็จจริงและการอ้างอิงโดยแก้ไขโพสต์นี้ ปิดให้บริการใน3 ปีที่ผ่านมา ปรับปรุงคำถามนี้ ฉันเคยได้ยินเสมอเกี่ยวกับฟังก์ชันจุดออกเดี่ยวว่าเป็นวิธีที่ไม่ดีในการเขียนโค้ดเนื่องจากคุณสูญเสียความสามารถในการอ่านและประสิทธิภาพ ฉันไม่เคยได้ยินใครเถียงอีกด้าน ฉันคิดว่าสิ่งนี้เกี่ยวข้องกับ CS แต่คำถามนี้ถูกยิงที่ cstheory stackexchange

30
ฉันผิดศีลธรรมหรือไม่ที่ใช้ชื่อตัวแปรที่แตกต่างจากประเภทของชื่อนั้น ๆ
ตัวอย่างเช่นใช้รหัสนี้: var person = new Person(); หรือสำหรับคุณ Pythonistas: person = Person() ฉันบอกตลอดเวลาว่าสิ่งนี้เลวร้ายแค่ไหน แต่ยังไม่เห็นตัวอย่างของการผิดศีลธรรมของรหัสสองบรรทัดนี้ สำหรับฉันแล้วคน ๆ หนึ่งก็คือบุคคลและการพยายามตั้งชื่ออื่นเป็นการเสียเวลา ฉันคิดว่าในช่วงหลายวันก่อนที่จะเน้นไวยากรณ์สิ่งนี้จะเป็นเรื่องใหญ่ แต่ทุกวันนี้มันค่อนข้างง่ายที่จะบอกชื่อประเภทนอกเหนือจากชื่อตัวแปร Heck มันง่ายมากที่จะเห็นความแตกต่างที่นี่ใน SO หรือมีบางอย่างที่ฉันขาดหายไป? ในกรณีนี้จะเป็นประโยชน์หากคุณสามารถให้ตัวอย่างโค้ดที่ทำให้เกิดปัญหาได้

6
ฉันสามารถบังคับใช้รูปแบบประเภทใดกับโค้ดเพื่อให้แปลเป็นภาษาโปรแกรมอื่นได้ง่ายขึ้น [ปิด]
ปิด . คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ขณะนี้ยังไม่ยอมรับคำตอบ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เน้นไปที่ปัญหาเดียวโดยแก้ไขโพสต์นี้เท่านั้น ปิดให้บริการใน5 ปีที่ผ่านมา ปรับปรุงคำถามนี้ ฉันกำลังวางแผนที่จะทำโครงการด้านข้างที่มีเป้าหมายในการแปลรหัสจากภาษาโปรแกรมหนึ่งไปยังอีกภาษาหนึ่ง ภาษาที่ฉันเริ่มต้นคือ PHP และ Python (Python เป็น PHP ควรจะเริ่มต้นได้ง่ายกว่า) แต่ฉันควรจะเพิ่มภาษาอื่น ๆ ได้อย่างง่ายดาย (สัมพัทธ์) แผนคือ: สิ่งนี้มุ่งสู่การพัฒนาเว็บ รหัสเดิมและรหัสเป้าหมายจะอยู่บนเฟรมเวิร์ก (ซึ่งฉันจะต้องเขียนด้วย) กรอบงานเหล่านี้จะใช้รูปแบบการออกแบบ MVC และปฏิบัติตามข้อกำหนดการเข้ารหัสที่เข้มงวด สิ่งนี้น่าจะทำให้การแปลง่ายขึ้น ฉันกำลังดู IOC และการฉีดแบบพึ่งพาเนื่องจากอาจทำให้กระบวนการแปลง่ายขึ้นและมีข้อผิดพลาดน้อยลง ฉันจะใช้โมดูลแยกวิเคราะห์ของ Python ซึ่งช่วยให้ฉันสามารถเล่นกับ Abstract Syntax Tree ได้ เห็นได้ชัดว่าสิ่งที่ใกล้เคียงที่สุดที่ฉันจะได้รับจาก PHP คือtoken_get_all ()ซึ่งเป็นการเริ่มต้น จากนั้นฉันสามารถสร้าง AST ตารางสัญลักษณ์และโฟลว์ควบคุม จากนั้นฉันเชื่อว่าฉันสามารถเริ่มการส่งออกโค้ดได้ ผมไม่จำเป็นต้องมีการแปลที่สมบูรณ์แบบ ฉันยังคงต้องตรวจสอบโค้ดที่สร้างขึ้นและแก้ไขปัญหา …

30
การเช็คอินของรหัส "แสดงความคิดเห็นออก" [ปิด]
ปิด . คำถามนี้เป็นคำถามความคิดเห็นตาม ขณะนี้ยังไม่ยอมรับคำตอบ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบได้ด้วยข้อเท็จจริงและการอ้างอิงโดยแก้ไขโพสต์นี้ ปิดให้บริการใน3 ปีที่ผ่านมา ปรับปรุงคำถามนี้ โอเคนี่คือสิ่งที่ทำให้เกิดความขัดแย้งในงานปัจจุบันของฉันและฉันไม่คาดคิดเลยจริงๆ การพัฒนาซอฟต์แวร์ภายในองค์กรเป็นแนวคิดใหม่ที่นี่และฉันได้ร่างหลักเกณฑ์การเขียนโค้ดฉบับร่างแรก ฉันได้เสนอว่าไม่ควรตรวจสอบโค้ด "แสดงความคิดเห็น" ในที่เก็บ เหตุผลที่ฉันได้ระบุไว้ก็คือที่เก็บรักษาประวัติทั้งหมดของไฟล์ หากคุณกำลังลบโค้ดที่ใช้งานได้ให้ลบออกทั้งหมด ที่เก็บจะเก็บการเปลี่ยนแปลงของคุณเพื่อให้ง่ายต่อการดูว่ามีการเปลี่ยนแปลงอะไรบ้าง สิ่งนี้ทำให้เกิดความขัดแย้งเนื่องจากนักพัฒนารายอื่นเชื่อว่าการใช้เส้นทางนี้ จำกัด เกินไป นักพัฒนาซอฟต์แวร์รายนี้ต้องการแสดงความคิดเห็นเกี่ยวกับโค้ดที่เขากำลังดำเนินการอยู่ แต่ยังไม่สมบูรณ์ จากนั้นรหัสนี้จะไม่เคยถูกเช็คอินมาก่อนและจะไม่ถูกบันทึกไว้ที่ใด เรากำลังจะใช้ TFS ดังนั้นฉันจึงแนะนำว่าการเก็บข้อมูลการเปลี่ยนแปลงจะเป็นวิธีแก้ปัญหาที่ถูกต้องที่สุด อย่างไรก็ตามไม่ได้รับการยอมรับเนื่องจากเขาต้องการตรวจสอบการเปลี่ยนแปลงบางส่วนที่อาจนำไปใช้หรือไม่ก็ได้ ในที่สุดเราก็ต้องการไปถึงจุดที่เราใช้ประโยชน์จาก Continuous Integration อย่างเต็มที่และปรับใช้กับเว็บเซิร์ฟเวอร์สำหรับการพัฒนาโดยอัตโนมัติ ขณะนี้ยังไม่มีเวอร์ชันพัฒนาของเว็บเซิร์ฟเวอร์หรือเซิร์ฟเวอร์ฐานข้อมูล แต่จะมีการเปลี่ยนแปลงในไม่ช้า อย่างไรก็ตามคุณมีความคิดอย่างไร? คุณเชื่อว่าโค้ด "แสดงความคิดเห็น" มีประโยชน์ในที่เก็บหรือไม่? ฉันสนใจที่จะรับฟังความคิดเห็นจากผู้อื่นในหัวข้อนี้ แก้ไข: เพื่อความชัดเจนเราไม่ใช้สาขาส่วนตัว ถ้าเราทำเช่นนั้นฉันจะบอกว่าทำในสิ่งที่คุณต้องการกับสาขาส่วนตัวของคุณ แต่ไม่เคยรวมรหัสที่แสดงความคิดเห็นกับลำต้นหรือสาขาที่ใช้ร่วมกัน แก้ไข: ไม่มีเหตุผลที่ถูกต้องที่เราไม่ใช้ส่วนตัวหรือต่อสาขาของผู้ใช้ ไม่ใช่แนวคิดที่ฉันไม่เห็นด้วย เรายังไม่ได้ตั้งค่าแบบนั้น บางทีนั่นอาจเป็นจุดศูนย์กลางในที่สุด ตอนนี้เราใช้ชั้นวางของ TFS

9
อะไรคือผลกำไรจากการประกาศวิธีการเป็นแบบคงที่
ฉันเพิ่งดูคำเตือนของฉันใน Eclipse และเจอคำเตือนนี้: มันจะเตือนคอมไพเลอร์หากวิธีนี้สามารถประกาศเป็นแบบคงที่ได้ [แก้ไข]ใบเสนอราคาที่แน่นอนภายในความช่วยเหลือ Eclipse โดยเน้นเรื่องส่วนตัวและขั้นสุดท้าย: เมื่อเปิดใช้งานคอมไพลเลอร์จะแสดงข้อผิดพลาดหรือคำเตือนสำหรับวิธีการที่เป็นส่วนตัวหรือขั้นสุดท้ายและอ้างถึงเฉพาะสมาชิกแบบคงที่ ใช่ฉันรู้ว่าฉันสามารถปิดได้ แต่ฉันต้องการทราบเหตุผลในการเปิดเครื่อง? เหตุใดจึงเป็นเรื่องดีที่จะประกาศทุกวิธีที่เป็นไปได้ว่าเป็นแบบคงที่? สิ่งนี้จะให้ประโยชน์ด้านประสิทธิภาพหรือไม่? (ในโดเมนมือถือ) ชี้ให้เห็นว่าวิธีการเป็นแบบคงที่ฉันคิดว่ากำลังแสดงว่าคุณไม่ได้ใช้ตัวแปรอินสแตนซ์ใด ๆ ดังนั้นจึงสามารถย้ายไปที่คลาสสไตล์ยูทิลิตี้ได้หรือไม่ ในตอนท้ายของวันฉันควรจะปิด 'เพิกเฉย' หรือฉันควรแก้ไขคำเตือนมากกว่า 100 รายการที่ให้ไว้? คุณคิดว่านี่เป็นเพียงคำหลักพิเศษที่ทำให้โค้ดสกปรกเนื่องจากคอมไพเลอร์จะสอดแทรกวิธีการเหล่านี้ต่อไปหรือไม่? (เหมือนกับว่าคุณไม่ได้ประกาศตัวแปรทุกตัวที่ทำได้สุดท้ายแต่คุณทำได้ )

3
การแปลงโดยนัยกับคลาสประเภท
ใน Scala เราสามารถใช้อย่างน้อยสองวิธีในการติดตั้งประเภทที่มีอยู่หรือแบบใหม่ สมมติว่าเราต้องการแสดงว่าบางสิ่งสามารถหาปริมาณได้โดยใช้Int. เราสามารถกำหนดลักษณะต่อไปนี้ การแปลงโดยนัย trait Quantifiable{ def quantify: Int } จากนั้นเราสามารถใช้การแปลงโดยนัยเพื่อหาจำนวนเช่น Strings and Lists implicit def string2quant(s: String) = new Quantifiable{ def quantify = s.size } implicit def list2quantifiable[A](l: List[A]) = new Quantifiable{ val quantify = l.size } หลังจากนำเข้าสิ่งเหล่านี้เราสามารถเรียกใช้เมธอดquantifyในสตริงและรายการ quantifyโปรดทราบว่ารายการเชิงปริมาณเก็บความยาวของมันจึงหลีกเลี่ยงการสำรวจเส้นทางที่มีราคาแพงของรายการได้ที่โทรตามมากับ พิมพ์คลาส อีกทางเลือกหนึ่งคือการกำหนด "พยาน" Quantified[A]ที่ระบุว่าบางประเภทAสามารถหาปริมาณได้ trait Quantified[A] { def …

10
แนวทางปฏิบัติที่ดีที่สุด: การสั่งซื้อสาธารณะ / ป้องกัน / ส่วนตัวภายในนิยามคลาส?
ฉันกำลังเริ่มโครงการใหม่ตั้งแต่ต้นและต้องการให้มันสะอาด / มีมาตรฐานการเข้ารหัสที่ดี นักพัฒนาที่ช่ำชองที่นี่ชอบจัดวางสิ่งต่างๆภายในชั้นเรียนในลำดับใด ตอบ: 1) วิธีการสาธารณะ 2) วิธีการส่วนตัว 3) ตัวแทนสาธารณะ 4) ตัวแทนส่วนตัว B: 1) ตัวแทนสาธารณะ 2) ตัวแทนส่วนตัว 3) วิธีการสาธารณะ 4) วิธีการส่วนตัว C: 1) public vars 2) public method 3) private method 4) private vars โดยทั่วไปฉันชอบใส่ vars คงที่สาธารณะไว้ด้านบน แต่ถ้าอย่างนั้นวิธีการแบบคงที่สาธารณะจะแสดงอยู่ข้างหน้าตัวสร้างของคุณหรือตัวสร้างควรอยู่ในรายการก่อนเสมอ? แบบนั้น ... ฉันรู้ว่ามันฟิน แต่ฉันแค่สงสัย: แนวทางปฏิบัติที่ดีที่สุดสำหรับสิ่งนี้คืออะไร? PS: ไม่ฉันไม่ใช้ Cc # ฉันรู้ว่า. ฉันเป็น …

5
การใช้ assert () ในการปฏิบัติที่ไม่ดีของ C ++ หรือไม่?
ฉันมักจะเพิ่มการยืนยันจำนวนมากให้กับโค้ด C ++ ของฉันเพื่อให้การดีบักง่ายขึ้นโดยไม่ส่งผลกระทบต่อประสิทธิภาพของการสร้างรุ่น ตอนนี้assertเป็นมาโคร C บริสุทธิ์ที่ออกแบบโดยไม่คำนึงถึงกลไก C ++ ในทางกลับกัน C ++ กำหนดstd::logic_errorซึ่งหมายถึงการโยนในกรณีที่มีข้อผิดพลาดในตรรกะของโปรแกรม (ดังนั้นชื่อ) การโยนอินสแตนซ์อาจเป็นทางเลือกที่สมบูรณ์แบบของ C ++ assertมากกว่า ปัญหาคือassertและabortทั้งสองยุติโปรแกรมทันทีโดยไม่ต้องเรียกผู้ทำลายดังนั้นการข้ามการล้างข้อมูลในขณะที่การทิ้งข้อยกเว้นด้วยตนเองจะเพิ่มต้นทุนรันไทม์โดยไม่จำเป็น วิธีหนึ่งในการแก้ปัญหานี้คือการสร้างมาโครการยืนยันของตัวเองSAFE_ASSERTซึ่งใช้งานได้เหมือนกับคู่ C แต่จะมีข้อยกเว้นสำหรับความล้มเหลว ฉันนึกถึงความคิดเห็นสามประการเกี่ยวกับปัญหานี้: ยึดมั่นในการยืนยันของ C เนื่องจากโปรแกรมถูกยกเลิกทันทีจึงไม่สำคัญว่าการเปลี่ยนแปลงจะถูกยกเลิกอย่างถูกต้องหรือไม่ นอกจากนี้การใช้#defines ใน C ++ ก็แย่พอ ๆ กัน โยนข้อยกเว้นและจับมันใน main () การอนุญาตให้รหัสข้ามตัวทำลายในสถานะใด ๆ ของโปรแกรมถือเป็นการปฏิบัติที่ไม่ดีและต้องหลีกเลี่ยงค่าใช้จ่ายทั้งหมดดังนั้นจึงมีการเรียกร้องให้ยุติ () หากมีการโยนข้อยกเว้นจะต้องถูกจับ ทิ้งข้อยกเว้นและให้มันยุติโปรแกรม ข้อยกเว้นในการยุติโปรแกรมนั้นไม่เป็นไรและเนื่องจากNDEBUGสิ่งนี้จะไม่เกิดขึ้นในรุ่นสร้าง การจับเป็นสิ่งที่ไม่จำเป็นและเปิดเผยรายละเอียดการนำโค้ดภายในไปmain()ใช้ มีคำตอบที่ชัดเจนสำหรับปัญหานี้หรือไม่? อ้างอิงมืออาชีพใด ๆ ? แก้ไข:แน่นอนว่าการข้ามผู้ทำลายล้างคือพฤติกรรมที่ไม่ได้กำหนด

10
สไตล์ JavaScript สำหรับการโทรกลับที่เป็นทางเลือก
ฉันมีฟังก์ชั่นบางอย่างซึ่งบางครั้ง (ไม่เสมอไป) จะได้รับการติดต่อกลับและเรียกใช้ กำลังตรวจสอบว่าการเรียกกลับถูกกำหนด / ฟังก์ชั่นสไตล์ที่ดีหรือมีวิธีที่ดีกว่านี้หรือไม่? ตัวอย่าง: function save (callback){ .....do stuff...... if(typeof callback !== 'undefined'){ callback(); }; };

8
เว้นวรรคก่อนปิดทับ?
ฉันเคยเห็นช่องว่างก่อนเครื่องหมายสแลชปิดในแท็ก XML และ HTML การแบ่งบรรทัด XHTML น่าจะเป็นตัวอย่างที่ยอมรับได้: <br /> แทน: <br/> พื้นที่ดูเหมือนฟุ่มเฟือย อันที่จริงฉันคิดว่ามันฟุ่มเฟือย เหตุผลที่เขียนเว้นวรรคนี้คืออะไร? ฉันได้อ่านพบว่า Space ช่วยแก้ปัญหา "ความเข้ากันได้ย้อนหลัง" ได้ ปัญหาความเข้ากันได้ย้อนหลังใด ปัญหาเหล่านั้นยังคงมีความเกี่ยวข้องหรือเรายังคงเพิ่มช่องว่างเพิ่มเติมเพื่อประโยชน์ในการกล่าวถึงความเข้ากันได้ของ IE3? มีข้อกำหนดบางอย่างพร้อมคำตอบที่ชัดเจนเกี่ยวกับเรื่องนี้หรือไม่? หากไม่สามารถใช้งานร่วมกันได้ย้อนกลับจะเป็นปัญหาในการอ่านหรือไม่? คล้ายกับการอภิปราย Great Open Curly Brace? void it_goes_up_here() { int no_you_fool_it_goes_down_there() { แน่นอนฉันสามารถเคารพความคิดเห็นเกี่ยวกับโวหารที่แตกต่างกันได้ดังนั้นฉันยินดีที่จะเรียนรู้ว่าการเขียนพื้นที่เป็นเพียงเรื่องของรสนิยม
93 html  xml  xhtml  coding-style 

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