🧋請GenAI產code就像點飲料：
不先講清楚甜度，出來的結果會讓你喝（讀）不下去。

前言

中秋連假的今晚，讓我一邊喝著珍奶微糖少冰，一邊閒聊GenAI時代，我個人對於語法糖的甜度偏好。

正文

指引GenAI少用語法糖

在這個大AI時代，各位開發者、碼農，或像我這樣的腳本玩家，應該都有一套自己偏好的GenAI配置。

我這幾個月比較常用的是Amazon的Kiro IDE，我會將個人偏好的程式碼風格，指定為Kiro每次產出程式碼前，必須先讀一次的規範。

其中一個規範是：避免使用語法糖。

- **Avoid syntax sugar**: Use explicit, verbose syntax instead of shorthand properties for better readability.

首次給出這個規範的契機，是我第一次使用Vue的時候。[^1]我並沒有像當年碰React一樣先相對踏實地慢慢學，僅是先大致了解Vue的基本架構後，就給pseudocode讓GenAI生成Vue的程式碼。

可是我當時根本不懂Vue的語法，於是我讓GenAI一律不要用縮寫，讓我能更好地辨識：[^2]

- **Use full directive names**: Write `v-on:click` instead of `@click` for better readability

- **Use explicit binding syntax**: Write `v-bind:class` instead of `:class` to make data binding obvious

具體來說，如果只是以下這種僅簡略幾個字元，身為剛接觸該語法的我，就會覺得前者比較易讀：

• v-on:click="fn" => @click="fn"
• v-bind:src="imgUrl" => :src="imgUrl"

只是少打幾個字的縮寫不再有意義

我覺得在後GenAI時代，只為了少打幾個字的縮寫不再那麼有效益。

例如const resp = await fetch()，這裡我就會更傾向於用response而非resp。

又例如{ x, y }相比{ x: x, y: y }，前者減少了重複的登打，後者則更直觀地顯示mapping，在後GenAI時代我更偏好後者。

再例如在GAS腳本，GenAI生成語法時，常常會出現這種縮寫：

var ss = SpreadsheetApp.getActiveSpreadsheet();

我個人則偏好直接用activeSpreadsheet而非ss。

pseudocode標準化？

整個程式語言發展的歷史，很大一部分都在處理如何更好地用人類易於理解的方式來撰寫電腦也可以讀懂的文件。

GenAI的出現大幅推進了這個進展，儘管目前只是用來生成程式碼，但相信也會大幅改變新舊程式語言的演進。例如有社群嘗試一套更適合GenAI的pseudocode格式：SudoLang。

後話

寫這篇文章的時候，我查詢了以前學習promise時的筆記，發現我當時讀一篇教學文章，讀到一半就放棄，隔一段日子重來、又放棄，循環了好幾次😅[^3]

現在重讀時覺得比以前更好理解，包含為什麼會有thenable這個容易產生預期外錯誤的相容性設計。

一來，我當時連資料間如何跨環境交換都沒實作過，自然對於promise很多語法感到難以理解。

二來，我現在嘗試新library時，也會去稍微了解開發者／維護團隊的問題意識與解題風格，所以更能想像一大群人之間如何凝聚共識最終成為一個convention甚至標準。

Annotations

[^1]： 那時必須在有限的時間內，先打包某個香草口味JavaScript專案，保持上線的同時每天逐步擴展。那時覺得，如果用React重構會太花時間，所以用Vue把大部分程式碼直接塞進template/style/script。

[^2]： 在官方ESLint插件，有vue/v-bind-style可以處理這個偏好。

[^3]： 如果能重來，我就會指引過去的我先學async/await語法就好，就跟學Redux時直接先學RTK就好一樣。