這世界上最危險的事之一，就是在老闆面前開你的程式碼畫面。
本來會議只是要看一下專案模組結構，討論專案結構是不是符合老闆想要的。沒人想過，主管查德看著程式碼說出：
「這些import的檔案的form為什都沒有對齊？」
「你看這個
:沒有對齊、=也亂七八糟，理查，我以為你資歷這麼深，這種基本的東西你早就都會了！」
全場空氣瞬間凝結，史帝夫像被定格一樣，嘴角微微抽動，一句話都說不出來。他不是不想解釋，而是心裡充滿了疑惑：
「這是會議的重點嗎？這樣排真的比較好嗎？不是已經有 eslint 處理了嗎？」
查德主管沒理會他的沉默，直接指揮他：「你現在打開那段 import，我看著你改。」
史帝夫只好默默把手放回鍵盤上，依照查德口頭指令，一行一行地在 VS Code 裡手動排起對齊版：
import React from 'react'
import { useForm } from 'react-hook-form'
import moment from 'moment'
import { Button, Input } from '@/components/ui'
import { login, logout, status } from '@/api/user'
「來，你現在排排看，這樣是不是漂亮很多了！」
那一刻我才真正理解，我們已經不是在開發討論會，而是在參加一場視覺對齊信仰的現場傳教儀式。
查德要求的對齊到底是什麼
React 表單寫法不能這樣：
下面是通常大家會寫的樣子
<Controller
name="email"
control={control}
rules={{ required: true }}
render={({ field }) => <Form.Control {...field} />}
/>
但查德覺得 props 應該要依照等號去對齊。
<Controller
name = "email"
control = {control}
rules = {{ required: true }}
render = {({ field }) => <Form.Control {...field} />}
/>
Object 或 config 檔也要這樣排：
const options = {
showLabel : true,
size : 'md',
color : 'blue',
}
對，你們沒看錯，要照著冒號去對齊。是不很反人類？
再來是 import 排版
要對著 form 去對齊
import React from 'react'
import { useForm } from 'react-hook-form'
import moment from 'moment'
import { Button, Input } from '@/components/ui'
import { login, logout, status } from '@/api/user'
他還說：「你看這樣看起來多工整，這樣才能展現出一個資深工程師的寫程式的功力。」
我只能說，他的審美觀很特別，非常非主流。
這種「手動排版風格」是從哪裡來的？
雖然我覺得很荒謬，但為了不讓自己只是發牢騷，我開始認真去查資料。這種「手動對齊」的風格，其實是有歷史背景的：
- 來自早期無 IDE 的開發時代：當時大家靠純文字編輯器（如 Vim、Emacs）開發，沒有語法高亮、沒有自動排版，要靠人工排版來提高可讀性。
- 重視人眼掃視效率：對齊
:和=讓 reviewer 可以用視覺對齊軸快速比對欄位內容，減少眼睛跳躍，方便閱讀
所以這一切，並非毫無根據，而是來自一種上個時代的「最佳實踐」。
但—我們現在還需要這樣嗎？
人工排版的問題
變更會變得很複雜，難以Review
手動對齊這個風格會造成整個團隊的程式維護困難。例如只改了一個變數名稱，就必須重新對齊整塊區域，這種格式變動對版本控制與 Code Review 來說非常不友善。
假設我們有一個範例，是一個設定檔案
const settings = {
port : 3000,
host : 'localhost',
maxRetries : 5,
enableCache : true,
};
現在要新增一個比較長的欄位名backupServerIP，為了「維持冒號對齊」，你被迫整塊重排變這樣：
const settings = {
port : 3000,
host : 'localhost',
maxRetries : 5,
enableCache : true,
backupServerIP : '192.168.1.10',
};
git 變更看起來會像是這樣
const settings = {
- port : 3000,
- host : 'localhost',
- maxRetries : 5,
- enableCache : true,
+ port : 3000,
+ host : 'localhost',
+ maxRetries : 5,
+ enableCache : true,
+ backupServerIP : '192.168.1.10',
};
結果就是 Git diff 看起來像是整塊程式碼被修改，實際上可能只是改了一行，造成 reviewer 難以分辨真正的改動。其實你只變更了最後一行，但你被迫要花時間去對齊格式。
如果是現在流行的排版風格在 git diff就會是下面這樣
const settings = {
...
- enableCache: true
+ enableCache: true,
+ backupServerIP: '192.168.1.10',
};
這樣 reviewer 可非常明確知道只是加了backupServerIP之一行而已。
維護成本高
每次新增或刪除一行時，都需要手動重調所有對齊的行。對，手動！
對團隊來說，這種格式維護是額外的開銷，而且沒有帶來實質功能上的提升。花非常多時間在這種虛功。
容易產生 Merge Conflict
多人同時修改相同區塊、但調整了不同的對齊方式，會導致 Git 無法自動合併，即使實際改動無衝突。手動解 conflict 時，也更容易出錯。畢竟變動太多了，混淆判斷力。
不一致的對齊標準
每個開發者對「對齊」的偏好不同：是用空格對齊？還是用 Tab？幾格？沒有統一規範時，格式容易混亂；有統一規範時，又造成格式改動變得嚴格又脆弱。
對齊目的只為了「美觀」，但犧牲實用性
程式碼的可讀性，不應該靠「欄位垂直整齊」來維持，而應該靠簡潔一致的排版規則。而且最好是統一自動化的，盡量少的人工介入，減少成本維持一致性。
如果你的主管和查德一樣固執的話
那麼恭喜你，將踏上一條永無止境的「手動對齊地獄之路」。雖然整個團隊都已經明確反應，這種靠空白鍵或 Tab 硬是把 : 和 = 排成直線的作法，早就被現代開發流程淘汰了。不僅沒有實質好處，還會帶來大量 diff 噪音、版本控制混亂與 code review 難度提升。但查德總是說：「你看這樣不是比較整齊嗎？」
最諷刺的是，查德口口聲聲說「整齊是基本功」，卻從不思考這些對齊動作帶來的實際成本，這和他每天最在意的成本完成矛盾。
有什麼工具可以幫助你
畢竟有時候如果主管很固執還活在舊時代，溝通了一樣無效堅持自我。那這個主管又掌握著你的績效直接影響你的獎金，除非你想換工作了。不然通常不建議和他堅持或是硬是要說服他。相信我，不需要和錢過不去，這只是一份工作，我們應付應付他就是了。那該怎麼應付呢？
Prettier
Prettier 不支援自動對齊 : 或 = 等符號，因為只要有一點修改，就會導致整段程式碼重新排列，產生大量不必要的 Git diff，增加維護負擔。這也是社群中許多人支持 Prettier 的理由之一，團隊的程式格式保持穩定永大於「看起來整齊」重要。
EsLint
ESLint，雖然技術上可以透過 key-spacing 規則設定對齊冒號
"key-spacing":["error",{"align":"colon"}]
但這並非官方推薦的做法。原因同樣是：這種對齊行為在多人協作下非常脆弱，一旦新增或刪除欄位，就容易引發大片格式變更，造成 Git diff 雜訊與協作障礙。
Align-Vertically
這是一個 VSCode 插件，可以幫助你依據你想要的東西去對齊，不管是 : 、= 還是 from 都可以。真的有需求的小夥伴，推薦使用看看。
當我們開始質疑新東西時，會不會已經老了？
查德對於程式碼對齊的堅持，若你試著去理解，會發現那不是純粹的固執，而是來自他所處的時代背景。在那個還沒有 Prettier、沒有 CI/CD pipeline、甚至還在用 Vim 寫程式的年代，手動對齊被視為一種「工程師的工整」基本素養，是用來展現專業與自律的象徵。而他在那樣的文化中一路升遷、做出成績，自然對這套價值觀深信不疑。
但也正因為他已經多年不碰第一線程式，早已脫離目前主流的開發流程與工具習慣，對於現在這個強調「自動化」、「最小 diff」、「可維護性高」的程式碼風格，感到陌生甚至排斥。他不願學習，也不願接受新的規範，反而想把他熟悉的那一套繼續強加在團隊身上，覺得那才是對的、才是專業。
這讓我不禁開始反思一件事—— 現在的我，也許還能寫出乾淨、有測試、符合現代語法風格的程式碼；也還能理解 Prettier 的自動排版、ESLint 的規則配置、Git 的工作流程。但未來呢？
未來十年、二十年後，會不會也有某種我無法理解的新工具、新風格，讓我忍不住皺眉說出：「這樣寫會不會太醜？」或「為什麼要用這個奇怪的東西？」我會不會也變成那個查德？
一個不再願意學習、不願放下自己經驗的人？
也許每一位技術人，終將在某個時間點面對這樣的選擇：是固守舊有經驗，堅信自己看過的世界已經是全部？還是保持好奇，承認自己還有很多東西不懂，願意理解年輕人的工具與語言？
我不知道未來的我會怎麼做，但我希望自己不會忘記這個畫面：當查德看著大家的程式碼說出「這樣不整齊」，整個團隊的氣氛瞬間凝結的那一刻。
我希望那一刻能成為提醒自己的警鐘。
這也是我決定寫這篇文章紀錄這個故事的原因
你也有遇過像查德這樣的主管嗎？留言跟我說
如果你也曾遇過類似的主管、開發習慣衝突，或對這種手動對齊的文化有話想說，歡迎在留言區分享你的故事。
這篇文章是我寫給未來自己的提醒，也想寫給還在第一線努力的開發者們。
如果你喜歡這種結合技術與職場觀察的內容，歡迎追蹤我，我會持續寫更多真實的故事與反思。
本文所描述的角色、事件與情境皆為虛構，僅用於技術與職場經驗之分享與反思。若與任何實際人物、單位或事件雷同，純屬巧合。
參考資料
Why Aligning Statements Will Haunt You https://fagnerbrack.com/why-aligning-statements-will-haunt-you-c7385a3b24d
What's wrong with aligned code?https://www.reddit.com/r/javascript/comments/7up999/whats\_wrong\_with\_aligned\_code/
key-spacing (eslint) https://eslint.org/docs/latest/rules/key-spacing
Align Vertically Extension https://marketplace.visualstudio.com/items?itemName=matthewthorning.align-vertically
