為什麼我更喜歡頂級符號的&#function&#聲明（但不會再使用它們）

今天，我們決定在工作中只使用箭頭函數。

我們有一個通用的 ESLint 配置，並且團隊投票決定在所有專案中統一此規則。

老實說，我不喜歡這個特殊規則

個人而言...函數宣告感覺更具表現力，至少對於頂層符號：

some-screen-of-my-app.tsx

import {} ...

export function SomeScreen(props: Props) {
  const { myContext } = useMyContext()
  const [state, setState] = useState()

  const doSomething = () => { ... }
  const handleSomething = () => { ... }

  return <>...</>
 }

function SomeInternalComponent() { ... }

這就是我習慣寫組件的方式：聲明一個函數感覺就像小說中的章節標題。

function Chapter3(storySoFar: Props) {
   // where the Hero meets the Villain
}

---

但我確實理解團隊的需求：根據模組的原始作者，我們可能會在第一層找到 const () =>; {} 或函數。

主要論點是「箭頭函數更具可讀性」（我不同意）

import {} ...

const SomeInternalComponent = () => { ... }

export const SomeScreen = (props: Props) => {
  const { myContext } = useMyContext()
  const [state, setState] = useState()

  const doSomething = () => { ... }
  const handleSomething = () => { ... }

  return <>...</>
 }

我試著找一些技術優勢來支持我的偏好...一些書呆子*pitimini* [一些小或微不足道的東西]移動了我的利益的平衡，但因為我們所有人都同意以下：

• 沒有類別（只有函數）
• 沒有全域的東西（現代模組）
• 沒有這個

兩者之間沒有顯著差異。

深入細節：

const foo = () =>; { ... }

• 禁止吊掛
• 函數的名稱源自於變數的名稱（“foo”）
• 以後不能像 foo=... 一樣被覆蓋
• 不建立原型物件 foo.prototype
• 不能用作建構子 new foo()
• 沒有參數
• 該值由 宣告函數的位置 定義

函數 foo() { ... }

• 吊裝
• 函數名稱是obv。
• 可以像 foo = ... 一樣被覆蓋
• 建立物件原型 foo.prototype
• new 是允許的，例如： new foo() （它將連結原型）
• 該值由如何呼叫函數
定義

---

最終，我更喜歡頂級組件的卓越的清晰度功能，但多數人的意志佔上風。
開玩笑，我會適應的。擁有統一的風格將有助於維護有凝聚力的程式碼庫。

???.

---

感謝您的閱讀

以上是為什麼我更喜歡頂級符號的&#function&#聲明（但不會再使用它們）的詳細內容。更多資訊請關注PHP中文網其他相關文章！