|
4 | 4 | # clean-code-javascript |
5 | 5 |
|
6 | 6 | ## Table of Contents |
7 | | - 1. [บทนำ](#introduction) |
| 7 | + 1. [Introduction](#introduction) |
8 | 8 | 2. [Variables](#variables) |
9 | 9 | 3. [Functions](#functions) |
10 | 10 | 4. [Objects and Data Structures](#objects-and-data-structures) |
|
15 | 15 | 9. [Formatting](#formatting) |
16 | 16 | 10. [Comments](#comments) |
17 | 17 |
|
18 | | -## บทนำ |
| 18 | +## Introduction |
19 | 19 |  |
21 | 21 |
|
22 | | -Software engineering principles, from Robert C. Martin's book |
23 | | -[*Clean Code*](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882), |
24 | | -adapted for JavaScript. This is not a style guide. It's a guide to producing |
25 | | -readable, reusable, and refactorable software in JavaScript. |
26 | | - |
27 | | -Not every principle herein has to be strictly followed, and even fewer will be |
28 | | -universally agreed upon. These are guidelines and nothing more, but they are |
29 | | -ones codified over many years of collective experience by the authors of |
30 | | -*Clean Code*. |
31 | | - |
32 | | -Our craft of software engineering is just a bit over 50 years old, and we are |
33 | | -still learning a lot. When software architecture is as old as architecture |
34 | | -itself, maybe then we will have harder rules to follow. For now, let these |
35 | | -guidelines serve as a touchstone by which to assess the quality of the |
36 | | -JavaScript code that you and your team produce. |
37 | | - |
38 | | -One more thing: knowing these won't immediately make you a better software |
39 | | -developer, and working with them for many years doesn't mean you won't make |
40 | | -mistakes. Every piece of code starts as a first draft, like wet clay getting |
41 | | -shaped into its final form. Finally, we chisel away the imperfections when |
42 | | -we review it with our peers. Don't beat yourself up for first drafts that need |
43 | | -improvement. Beat up the code instead! |
| 22 | +หลักการในการพัฒนาซอฟท์แวร์ซึ่งนำมาจากหนังสือของ Robert C. Martin ที่ชื่อว่า |
| 23 | +[*Clean Code*](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) |
| 24 | +โดยมีการปรับแต่งให้อยู่ในรูปของ JavaScript |
| 25 | +นี่ไม่ใช่สไตล์ไกด์ แต่เป็นไกด์เพื่อสร้างโค้ด JavaScript |
| 26 | +ที่อ่านง่าย(readable) ใช้ซ้ำได้(reusable) และปรับโครงสร้างได้(refactorable) |
| 27 | + |
| 28 | +ทุกๆหลักการในที่นี้ไม่จำเป็นต้องทำตามอย่างเคร่งครัด และมีเพียงบางหลักการเท่านั้นที่เป็นที่ยอมรับอย่างเป็นสากล |
| 29 | +นี่เป็นเพียงไกด์ไลน์ที่เกิดจากประสบการณ์หลายปีของผู้เขียนหนังสือ Clean Code |
| 30 | + |
| 31 | +การพัฒนาซอฟท์แวร์เพิ่งผ่านมาแค่ 50 กว่าปีเท่านั้น และเรายังคงต้องเรียนรู้อีกมาก |
| 32 | +เมื่อสถาปัตยกรรมการพัฒนาซอฟท์แวร์เก่าแก่พอ เมื่อนั้นเราอาจจะมีกฏที่เข้มงวดขึ้นให้ต้องปฏิบัติตาม |
| 33 | +แต่ตอนนี้ ให้ไกด์ไลน์นี้เป็นเหมือนสิ่งที่ใช้ตรวจสอบคุณภาพของโค้ด JavaScript ที่คุณและทีมของคุณสร้างขึ้น |
| 34 | + |
| 35 | +อีกเรื่องหนึ่ง การทำตามหลักการนี้ไม่ได้ช่วยให้คุณเป็น software developer ที่ดีขึ้นได้ทันที |
| 36 | +และการอยู่กับมันหลายปีไม่ได้หมายความว่าคุณจะไม่ทำผิดพลาด |
| 37 | +ทุกๆส่วนของโค้ดเริ่มจากฉบับร่าง เหมือนกับการขึ้นรูปปั้นดินเหนียว |
| 38 | +ในท้ายที่สุดแล้ว เราจะกำจัดส่วนที่ไม่สมบูรณ์ออกไป อย่าเพิ่งโทษตัวเองกับแบบร่างแรกที่ต้องการการปรับปรุง |
| 39 | +แต่จงจัดการกับโค้ดซะ! |
44 | 40 |
|
45 | 41 | ## **Variables** |
46 | 42 | ### Use meaningful and pronounceable variable names |
|
0 commit comments