SaigonTech Vault
Loại: knowledge-doc 2026-09-29 active #wiki-import

Một số vấn đề thường gặp khi lập trình

1. Không format source code

Mọi project sẽ có code-style riêng, style này được định nghĩa trong thư mục .idea/codeStyles. Mọi người phải tuân thủ việc format source sau khi chỉnh sửa để người sau không bị ảnh hưởng.

Nếu bạn không tuân thủ việc format source, việc review pull của người sau sẽ tốn nhiều thời gian hơn do phát sinh những thay đổi không cần thiết.

  • Tạo file mới : Format toàn bộ nội dung file

  • Chỉnh sửa file cũ : chỉ Format nội dung chỉnh sửa. (Xem xét format toàn bộ file nếu có ít thay đổi sau khi format)

2. Commit những đoạn code dùng để debug

Không nên commit kể cả khi những đoạn code đã được comment lại. Nhưng những đoạn log để dễ kiểm tra lỗi sau này thì vẫn OK.

// PHP example
var_dump($users);
// dump($users);
dd($page);

// JS example
console.log(response);

// ti nua lam tiep bla bla
 ```
Trường hợp OK:
```php
try
{
    // Do somthing
}
catch(Exception $exception)
{
    Log.error(__FUNCTION_NAME__ . ':' . $exception->getMessage());
    // Rollback or somthing else
}

3. Github: “No newline at end of file”

Khi tạo file mà không có một dòng trống cuối cùng của file.

Những file được tự động tạo và thay đổi liên tục khi code thay đổi thì không cần thiết phải quan tâm tới warning này.

4. Không tạo document và comment ý nghĩa cho “function”, “class”, “property”.

Xem xét thêm comment, để giải thích rõ hơn cho ý nghĩa của chúng.

Những đoạn code phải trải qua nhiều bước, có những xử lý cần chú ý thì cũng nên comment để giải thích rõ hơn. Những người chỉnh sửa sau này sẽ dễ dàng hơn khi đọc source.

Tham khảo: https://www.jetbrains.com/help/phpstorm/phpdoc-comments.html

Môi trường PHP>=8.0, sử dụng type hint cho dễ dev và hạn chế lỗi

5. Key not defined in array object

$array = [1, 2, 3];
echo $array['id'];
echo $array['id']['value'][0]['title'];
 ```

## 6. Vi phạm quy tắc đặt tên
 - `Array, Collection`: Số nhiều
 - `Object`: Số ít
 - `Meaning`: Phải có ý nghĩa, rõ và đúng nghĩa
 - Không quá dài hoặc quá ngắn
 - Hạn chế viết tắt

```php
$student = [{}, {}, {}];
$user = User::all();

$userList = User::find(100);

$title_for_layout; $title;
foreach ($users as $key => $value) {
  // $key unused
}

public function aVeryLongMethodName() {}

$userIdx; $ua; $userAgent;

for($a = 0; $a < $l; $a++) {} 
foreach ($users as $user) {} 
$user->save(); // ERROR

PHP:

https://www.php-fig.org/psr/psr-2/

https://www.php-fig.org/psr/

Laravel:

https://chungnguyen.xyz/posts/code-laravel-lam-sao-cho-chuan

7. Viết 1 function quá dài (>40 dòng)

Phải tuân thủ quy tắc mỗi function tối đa 40 dòng

Tốt nhất là dưới 10 dòng

Hạn chế trên 30 dòng.

8. Commit source không cần thiết

Ví dụ:

  • Chỉ cần thay đổi 3 files là hoàn thành 1 issue. Nhưng format thêm file thứ 4 (chỉ format). Xong commit cả 4 file. (có chủ ý)
  • Có 1 số file ở local, khi commit không để ý và cũng push lên git luôn (không có chủ ý)
  • Import thư viện hoặc khai báo biến, khai báo function mà không sử dụng

9. Commit message không có đầy đủ ý nghĩa, không có link tới issue

Ví dụ:

  • Fix comments

  • Commit

  • (no message)

Ex chuẩn: #15 Add login screen

10. Vi phạm DRY, don’t repreat your self

Những đoạn code có thể có sử dụng ở một nơi khác, phải tạo ra function để gọi lại.

Quy tắc: Nếu có thể có 3 chỗ giống nhau, thì tạo ra function để sử dụng.

11. Viết function trong Controller mà không sử dụng trong Route files

12. Không self-check khi request review

13. Đang review mà vẫn thấy commit push lên

14. Không fix hết comments đã request review lại

15. JS, sử dụng “let, const, var” không hợp lý

Tham khảo: https://www.freecodecamp.org/news/var-let-and-const-whats-the-difference/

16. (5K) Lỗi syntax, 500 Error...

17. (5K) Khi có lỗi, xác định là dễ quá không test lại nên phát sinh lỗi, có thể là 500 Error...

Một nhánh nhỏ của 16

18. Làm xong mà không request review hoặc không push chatwork

19. Không research trước khi nhờ support, nhất là những câu hỏi liên quan tới syntax

Học cách đặt câu hỏi cho hợp lý và chính xác

20. Research quá lâu 1 vấn đề (> 45 phút)

Research hướng giải quyết quá 30 phút mà chưa ra, Xem xét hỏi leader hoặc những thành viên khác.

21. Không bám theo WBS

Làm task không theo thứ tự đã được lên kế hoạch từ đầu trong WBS

22. (5K) Pull vô nhánh “master“

Kể cả khi nhánh “master” là nhánh default. Cần xác nhận lại trước khi làm

23. (5K) Không checkout từ develop

Dẫn tới rất khó khăn cho người review, hoặc là phải chờ nhánh khác review xong mới review được. Cần xác nhận trước với người review

24. (3K) Không tuân thủ 1 pull cho 1 issue

25. PHP >=8.0, tuân thủ type hint như bên dưới

    public Order $order;

    /**
     * @param int $sendId
     * @param string $result
     * @param int $money
     * @param string $paypalId
     * @throws Throwable
     */
    public static function updateOrder(int $sendId, string $result, int $money, string $paypalId): void
    {
        // TODO something
    }
 ```

## 26. (5K) Commit “<<<<<<<< HEAD” Or something like that

## 27. (1K) Key của Object nên tuân thủ theo quy tắc đặt tên biến
- Không nên bắt đầu bằng số hay ký tự đặc biệt,...

Ví dụ:

const THE_NUMBER = { '10' : { name : 'ten', value: 10, }, '20': { name : 'twenty', value: 20, }, ... }


Lý do:
Trong JS có thể gọi property theo 2 cách: 
 1. THE_NUMBER.ten
 2. THE_NUMBER['ten']

Nên đối với ví dụ trên khi gọi property: 
- THE_NUMBER.10 => errorrrrrrr
- THE_NUMBER['10'] => khum seo

Nhưng cách thứ nhất thường được sử dụng hơn, nên tốt nhất nên đặt tên property theo quy tắc đặt tên biến bình thường để khi nó được sử dụng với cách nào cũng không gây ra lỗi:

Ví dụ:

const THE_NUMBER = { ten: { name : 'ten hihi', value: 10, }, twenty: { name : 'twenty hehe', value: 20, }, ... } ```

28. (5K) Không cập nhật label trên Github khi làm issue

  • Đang làm -> doing, làm xong -> reviewable,...

29. Các rule về đọc chatwork, feedback, comment,...

  • Không tự ý phán đoán specs. Khi specs không ghi, thì cần phải confirm lại, ko tự ý phán đoán rồi tự ý làm.
  • Nội dung viết bằng tiếng Nhật dễ gây khó hiểu, vì vậy nếu cảm thấy không chắc chắn thì cần tag và confirm lại với những người biết tiếng Nhật.
  • Cần đọc kỹ nội dung, không qua loa. Đối với câu hỏi dạng xác nhận đúng/sai => nên viết lại xác nhận nội dung câu hỏi, thay vì chỉ trả lời yes/no, giúp cả 2 bên đều hiểu về cùng 1 vấn đề. (vd: https://www.chatwork.com/#!rid145192865-1588807293594521600)
  • Sau khi hiểu nội dung, cần xác nhận lại một lần nữa với bên EyeM.
  • Khi được mention vào chatwork bắt buộc phải confirm. Không được bỏ qua khi có member khác đã trả lời.

30. Không early return khi có thể

Tham khảo:

https://gomakethings.com/the-early-return-pattern-in-javascript/

https://medium.com/swlh/return-early-pattern-3d18a41bba8

31. Một comment bị lặp lại trong cùng 1 pull (x2)

  • Người review comment: abc
  • Assignee fix comment và request review lại
  • Người review lại comment: abc