Đổi case hàng loạt khi rename trong PR | camelCase snake_case checklist【2026】

(Cập nhật: 19 tháng 7, 2026 ) case converter rename Pull Request camelCase snake_case kebab-case identifier
Kết luận

Rename trong PR mà đổi case từng biến bằng tay = dễ sót và dễ lệch convention. Quy trình an toàn: liệt kê identifier → chuyển case hàng loạt → review acronym → apply có kiểm soát. Dùng Case Converter để sinh danh sách user_name ↔ userName / UserName / user-name trên trình duyệt (không upload). Không Find & Replace mù toàn repo.

Bạn mở PR “rename order_status → orderStatus cho đồng bộ FE”. Reviewer hỏi: “đã đổi hết key JSON, DTO, test snapshot chưa?” Bạn đã sửa 12 chỗ bằng tay — vẫn còn 3 chỗ trong fixture và 1 chỗ trong docs OpenAPI.

Đó là lúc đổi case hàng loạt hữu ích hơn gõ lại từng chữ: chuẩn bị danh sách identifier, convert một lần, rồi áp dụng có checklist. Bài này dành cho developer / freelancer / team outsource ở Việt Nam khi làm PR rename giữa camelCase, snake_case, PascalCase và kebab-case — không phải bài lý thuyết naming chung.

Bài viết này giúp bạn

  • Hiểu khi nào cần bulk case convert trong PR rename
  • Quy trình 5 bước: list → convert → filter → apply → verify
  • Bảng mapping nhanh giữa 4–7 định dạng phổ biến
  • Checklist review trước merge và lỗi thường gặp
  • Case study: rename field API mà không phá client cũ

Vì sao PR rename hay “sót case”?

Rename không chỉ đổi tên biến trong một file TypeScript. Một identifier thường xuất hiện ở nhiều “lớp”:

LớpVí dụConvention hay gặp
Biến / hàm JS-TSgetUserNamecamelCase
Class / componentUserProfileCardPascalCase
Cột DB / Pythonuser_namesnake_case
CSS class / URL sluguser-namekebab-case
Hằng số / envMAX_RETRY_COUNTUPPER_SNAKE

PR rename thất bại thường vì đổi một lớp mà quên lớp khác, hoặc vì Find & Replace đụng phải chuỗi nằm trong string không phải identifier (ví dụ log message "user_name missing").

Case converter giải quyết phần “sinh đúng dạng chữ” hàng loạt. Phần “chọn đúng chỗ để thay” vẫn cần bạn và IDE (Rename Symbol, thay thế theo file đã lọc).

Các định dạng case cần nhớ khi rename

Định dạng case — dùng khi nào trong PR
Định dạng Ví dụ Thường gặp ở
camelCase orderStatus Biến, hàm, field JSON (Nest/FE)
PascalCase OrderStatus Class, React component, enum member (một số style)
snake_case order_status Python, SQL, nhiều payload backend cũ
kebab-case order-status CSS class, path URL, slug
UPPER_SNAKE ORDER_STATUS Constant, đôi khi tên env

Trên Case Converter Kawa bạn còn có lower case và UPPER CASE (cách bằng khoảng trắng) — hữu ích khi chuẩn hóa nhãn hiển thị hoặc tiêu đề tạm, ít dùng hơn cho identifier code.

Lưu ý kỹ thuật: tool tách từ theo biên chữ hoa/thường, _ và -, rồi ghép lại theo định dạng đích. Mỗi dòng trong ô nhập được convert độc lập — phù hợp paste danh sách identifier từ git grep hoặc Excel spec.

Quy trình 5 bước: rename PR không sót

1. Khoanh phạm vi

Viết rõ trong description PR:

  • Đổi trong module nào (ví dụ chỉ orders/, không đụng payments/)
  • Có đổi API contract / JSON key không?
  • Có cần migration DB không? (đổi tên cột ≠ đổi tên field TS)

Nếu chỉ đổi tên biến nội bộ mà JSON public vẫn order_status, hãy ghi rõ để reviewer khỏi yêu cầu đổi client.

2. Xuất danh sách identifier cũ

Ví dụ từ terminal (minh họa):

rg -o "order_status|OrderStatus|order-status" -g '*.ts' -g '*.tsx' | sort -u

Hoặc copy từ “Find in Files” của IDE. Mục tiêu: một tên mỗi dòng, không kèm path.

Ví dụ input sẵn sàng convert:

order_status
payment_method
created_at
user_id

3. Convert hàng loạt

  1. Mở Case Converter
  2. Dán danh sách
  3. Chọn định dạng đích (ví dụ camelCase)
  4. Copy kết quả:
orderStatus
paymentMethod
createdAt
userId

Làm thêm một lần sang kebab-case nếu PR cũng đụng CSS/URL. Giữ hai cột mapping trong PR comment hoặc ticket.

4. Lọc những gì không được đổi

Trước khi apply, gạch bỏ khỏi danh sách:

  • Tên env (ORDER_STATUS_WEBHOOK) nếu ngoài phạm vi
  • HTTP header hoặc khóa do đối tác quy định
  • Acronym theo style guide team (userId vs userID)
  • File generated / lockfile

5. Apply + verify

  • Ưu tiên Rename Symbol của IDE cho symbol thật
  • Với JSON fixture / OpenAPI: thay theo mapping đã review
  • Chạy unit test, snapshot, và một request thật nếu đổi response key
  • Trong PR: bảng cũ → mới ngắn (5–20 dòng) giúp reviewer

Case study: PR “đồng bộ field đơn hàng”

Bối cảnh: Freelancer nhận task từ agency: FE React dùng orderStatus, backend Laravel trả order_status. Lead yêu cầu một PR FE map rõ, không đổi DB tuần này.

Làm đúng:

  1. Liệt kê key JSON backend cần map (snake)
  2. Convert sang camel cho TypeScript interface
  3. Viết adapter một chỗ (mapOrderDto) thay vì rename mù 40 file
  4. PR ghi: “JSON public vẫn snake; TS nội bộ camel — bảng map đính kèm”

Làm sai (thường gặp):

  • Find & Replace order_status → orderStatus cả repo → phá chuỗi trong i18n và log
  • Đổi luôn tên cột trong migration “tiện thể” → rollback đau
  • Quên snapshot test → CI đỏ sau merge

Bài học: Case converter giúp sinh tên đúng; chiến lược PR quyết định đổi ở tầng nào.

Checklist trước khi bấm Merge

  • Có danh sách mapping cũ → mới trong PR
  • Đã tách code identifier vs string literal vs env
  • Acronym đã review (Id / URL / API)
  • Test/snapshot liên quan field đã chạy
  • Nếu đổi JSON public: đã thông báo consumer / version API
  • Không dán secret vào tool online (dù tool chạy local vẫn nên thói quen sạch)

Lỗi thường gặp khi bulk convert

1. Convert cả câu thay vì identifier

Input get user name from DB → camel có thể thành chuỗi vô nghĩa. Mỗi dòng một identifier, không phải câu mô tả.

2. Tin tool hiểu acronym

oauthToken ↔ oauth_token ổn; OAuthToken có thể tách thành o_auth_token tùy biên chữ hoa. Luôn đọc lại tên viết tắt.

3. Đổi kebab trong URL đã public

Slug /order-status đã được bookmark hoặc sitemap thì đổi case URL là breaking change — cần redirect, không chỉ rename code.

4. Trộn UPPER_SNAKE với camel trong cùng object

{
  "orderStatus": "paid",
  "MAX_RETRY": 3
}

Hằng số và field thường khác convention — đừng “normalize hết về camel” chỉ vì tiện.

Cách dùng nhanh trên Kawa Dev Tools

  1. Mở Case Converter
  2. Dán danh sách identifier (mỗi dòng một tên)
  3. Bấm định dạng đích: camelCase, PascalCase, snake_case, kebab-case, UPPER_SNAKE…
  4. Sao chép kết quả vào bảng mapping PR hoặc IDE

Công cụ xử lý trên trình duyệt — phù hợp danh sách field nội bộ hơn việc upload lên dịch vụ lạ. Kết hợp Đếm ký tự nếu bạn đang kiểm tra độ dài tên cột DB hoặc nhãn form kèm theo.

Khi nào không cần case converter?

  • Đổi một symbol trong một file → Rename Symbol của IDE đủ
  • Cần refactor semantic (đổi user thành account) → không phải bài toán case
  • Đổi tên đã chuẩn hóa bởi codegen (Prisma client, OpenAPI generator) → sửa schema/source of truth, đừng sửa output tay

Case converter tỏa sáng khi bạn có nhiều tên cùng một phép biến đổi chữ trong một PR rename có deadline.

Câu hỏi thường gặp

Find & Replace toàn repo có ổn không?
Hiếm khi ổn với rename case. Dùng danh sách + IDE rename + thay thế có lọc file.

Có cần đổi DB và JSON cùng một PR không?
Không bắt buộc. Tách PR giảm rủi ro; ghi rõ tầng nào giữ nguyên.

Team FE/BE đặt tên lệch thì sao?
Chốt contract (OpenAPI/DTO) làm nguồn sự thật; dùng converter để sinh cặp tên khi viết map lần đầu, rồi khóa convention trong CONTRIBUTING.

Liên kết liên quan