List of Lint [text.Baldanders.info]

strings.Title 関数は非推奨になった

2022-07-24T12:24:01+00:00

たとえば，以下のコードがあるとする。

package main

import (
    "fmt"
    "strings"
)

func main() {
    msgs := []string{
        "hello, world!",
        "HELLO, WORLD!",
    }
    for _, msg := range msgs {
        fmt.Println(msg, "->", strings.Title(msg))
    }
}

これを実行すると

$ go run sample1.go
hello, world! -> Hello, World!
HELLO, WORLD! -> HELLO, WORLD!

と単語の先頭が大文字に変換される。

この strings.Title() 関数について Go 1.18 から

The Title function is now deprecated. It doesn’t handle Unicode punctuation and language-specific capitalization rules, and is superseded by the golang.org/x/text/cases package.

via Go 1.18 Release Notes - The Go Programming Language

という感じに非推奨になった。なお，このコードを golangci-lint にかけると

$ golangci-lint run
sample1.go:14:26: SA1019: strings.Title has been deprecated since Go 1.18 and an alternative has been available since Go 1.0: The rule Title uses for word boundaries does not handle Unicode punctuation properly. Use golang.org/x/text/cases instead. (staticcheck)
        fmt.Println(msg, "->", strings.Title(msg))
                               ^

と言う感じに警告を出してくれる。つか，この警告で気がついたんだけどね。相変わらず lint に叱られっぱなしである orz

ちなみに似た関数名に strings.ToTitle() というのがあるが，これを使うと

$ go run sample1b.go
hello, world! -> HELLO, WORLD!
HELLO, WORLD! -> HELLO, WORLD!

という感じに全部大文字になる。これって strings.ToUpper() と何が違うんか分からん（笑）

さて， strings.Title() 関数を使う代わりに golang.org/x/text/cases を使えとあるようなので，早速コードを書き換えてみる。こんな感じかな。

package main

import (
    "fmt"

    "golang.org/x/text/cases"
    "golang.org/x/text/language"
)

func main() {
    msgs := []string{
        "hello, world!",
        "HELLO, WORLD!",
    }
    for _, msg := range msgs {
        fmt.Println(msg, "->", cases.Title(language.Und).String(msg))
    }
}

これを実行すると

$ go run sample2.go
hello, world! -> Hello, World!
HELLO, WORLD! -> Hello, World!

おっと！単語の2文字目以降が違うか。じゃぁ，オプションをつけて

fmt.Println(msg, "->", cases.Title(language.Und, cases.NoLower).String(msg))

とすればいいのかな。

$ go run sample2b.go
hello, world! -> Hello, World!
HELLO, WORLD! -> HELLO, WORLD!

よーし，うむうむ，よーし。

language.Und の部分は特定の言語（language.Japanese とか）を指定できるのだが，たとえば役物が絡む場合：

package main

import (
    "fmt"

    "golang.org/x/text/cases"
    "golang.org/x/text/language"
)

func main() {
    msg := "'n"
    casers := []cases.Caser{
        cases.Title(language.English),
        cases.Title(language.Dutch),
    }
    for _, caser := range casers {
        fmt.Println(msg, "->", caser.String(msg))
    }
}

これを実行すると

$ go run sample3.go
'n -> 'N
'n -> 'n

という感じに言語によって違いが出るようだ？

Lint は用法・用量を守って正しく使いましょう

話は変わるが，「失敗」には大きく2つある。「受動的失敗」と「能動的失敗」だ。このフレーズは Bruce Schneier さんの『セキュリティはなぜやぶられたのか（Beyond Fear）』にセキュリティ用語として出てくる。

セキュリティシステムの問題は大きく分けてふたつのパターンがある。ひとつ目は攻撃に対する防御が失敗するもの。（中略）とるべき対策が実行されない受動的な失敗である。ふたつ目は間違ったときに対策を実行して防御が失敗するもの。（中略）とるべき対策を実行したがゆえの能動的な失敗である。

『セキュリティはなぜやぶられたのか』p.77より

受動的失敗は批判の対象になりやすいが，受動的失敗を恐れるあまり能動的失敗に陥るというのもありがちなパターンである。

いや Twitter の TL で golangci-lint をフルオプションで起動して山ほど警告が出てきても平気みたいな記述を見かけたので。これって典型的な能動的失敗だよなぁ。オオカミが来た！

もとより lint のような静的コード解析は万能ではない。なれば，より気にすべきなのは受動的失敗より能動的失敗である。

golangci-lint はオプション無しでもかなりの部分を網羅できる。せいぜい gosec を追加するくらい。まずはこれで警告が出ないことを目指した上で，プロダクトによって過不足があれば少しずつ調整していけばいいのだ。

たとえば，拙作の gnkf は MD5 や SHA-1 のハッシュ値を出力する機能があるが gosec を含めて lint をかけると「弱いハッシュ関数を使うな（←超意訳）」みたいな警告が出てしまう。そこで

$ golangci-lint run --enable gosec --exclude "G501|G505" ./...

のようにチェック対象を調整している。仕事で使うならメンバ間で .golangci.yaml 等を使って設定を合わせておけばいいだろう。

lint は用法・用量を守って正しく使いましょう。

ブックマーク

逆引き Goによる静的解析

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

[Comment] 著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

[Comment] 原書のタイトルが “Beyond Fear: Thinking Sensibly About Security in an Uncertain World” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので，そのへんを加味して読むとよい。

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

Go 1.18 と Generics と Linter

2022-03-19T06:16:40+00:00

予測して然るべきであったが Go 1.18 に組み込まれた Generics と既存の linter の間でトラブルが続出しているらしい。

私も大変お世話になっている Go の代表的な総合 linter である golangci-lint は v1.45 で暫定的な対応を行ったようだ。

So I added a new configuration option inside the run section.
We will not have to remove this option in the future because we will be able to use it for some linters that have a Go version option.

An example:
run:
    go: 1.18
By default, the supported Go version will be go1.17 because it allows us to run all our tests without a huge rewrite.

If you set the version to go1.18, the following linters will be inactive:

bodyclose

contextcheck

gosimple

nilerr

noctx

rowserrcheck

sqlclosecheck

staticcheck

stylecheck

tparallel

unparam

unused

wastedassign

via Support of go1.18 · Issue #2649 · golangci/golangci-lint

この説明にあるように .golangci.yaml ファイルに

run:
    go: 1.18

の記述を入れることで Go 1.18 に対応していない linter を無効にしてくれるようだ。あとは各 lint パッケージが 1.18 に対応してくれることを気長に待つしかないか。

なお Generics の機能を使わないのなら今回の件は気にしなくてよい（笑）

あと golangci-lint-action もいつの間にか v3 に上がってるな。見落としてたかなぁ。この辺はおいおい検証しよう。

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

MISRA-C の思ひ出（または「守られないルールはルール自体に問題がある」）

2021-04-25T02:35:57+00:00

オンライン開催お疲れさまでした

2021-04-21 に開催された Go Conference 2021 Spring は初のオンラインだったそうで，週末の土曜日ということもあって，出不精で人見知りな私でも気軽に参加できたのがありがたかった。（リアルタイム視聴も含めて）動画や音声のコンテンツはまとまった時間で拘束されてしまうのであまり好きではないのだが，たまにはこういうものに参加するのもよろしかろう。

そのなかのひとつである

Go をセキュアに書き進めるための「ガードレール」を整備しよう / Let’s Build Security Guardrails For Your Go Programs! - Speaker Deck

は興味深く視聴させてもらった。特に go-ruleguard は面白そうだ。個人でも使う機会があるかもしれない。

ちなみに，スライドにも書かれているが， gosec は golangci-lint にも組み込まれているので

$ golangci-lint run --enable gosec ./...

といった感じに使うことができる。

MISRA-C の思ひ出

この発表を視聴しながら思い出していたのは大昔に車載系のプロジェクトに参加したときのことだ。あのときはアセンブラでベクタテーブルからゴリゴリ書いてたよなぁ（遠い目）

今は違うと思うが，当時は MISRA-C というガイドラインがあって，これが車載系における事実上の C 言語コーディング基準（criteria）になっていた。

詳細は割愛するが， MISRA-C には127個のルールがあって「必要（Required）」と「推奨（Advisory）」のいずれかに分類されている。このうち「必要」ルールは強制的に課せられるルールで，このルールからの逸脱（deviation）を許容する場合には，手続きを踏んで文書化と承認を行わなければならない。各ルールにはルールの詳細（何故そのルールが必要か）と逸脱可否の判断基準とサンプルコードが載っているので，それを参考に逸脱の可否を判定する。

MISRA-C が定めるルール自体は合理的な内容なのだが，127個ものルールを机上でチェックするのは不毛なので MISRA-C 対応の lint ツールを使うことになる（当時はこれがバカ高くてねぇ）。で，当然ながら lint ツールは製品の差別化のために MISRA-C 以外のルールもチェックできるようになっていて，最終的に数百ものルールをチェックすることになる。

守られないルールはルール自体に問題がある

問題は lint を実施した結果，大量の警告が出た場合である。あるルールについて大量の逸脱が発生する理由は大きく2つある。

プログラム設計が根本的に間違っている
ルールが間違っている

プログラマのスキルによるかもしれないが，経験上こういうときに前者が理由であることはほとんどない。なので，まずは「ルールが間違っている」のではないかと疑ってみるのが定石である。

基本的に「ルールは守られるべきもの」であるが，ルールもまた人間が考えたものであり，間違っている可能性を常に考慮すべきである。何故なら人間は間違いを犯す生き物なのだから。

私は「悪法も法」という考え方には与しない。「悪法は悪法」であり正すべきだ。そして「悪法」の判断基準のひとつが「守られないルールはルール自体に問題がある」である。ルールもリファクタリングの対象となる「コード」なのだ。

最初に挙げた発表では reviewdog を使って変更部分のみチェックする方法が紹介されていたが， reviewdog を常用するのは個人的にお勧めできない。これが常態化すると「動いてるコードは触るな」という方向に行きがちで，それによってリファクタリングの機会を失うこととなり，最終的に技術的負債の返済が遅れることになる。リファクタリングに厚いのが Go の持ち味なので，これを抑圧するような運用は避けるべきだろう。

ことほど左様にルール・メイキングというのは難しいのである。できるなら，煩わしいことは機械に任せて楽しくコードを書きたいものである。

ブックマーク

golangci-lint を GitHub Actions で使う

参考図書

組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド: MISRA‐C研究会 (編集); 日本規格協会 2006-10-01; 単行本; 4542503461 (ASIN), 9784542503465 (EAN), 4542503461 (ISBN); 評価

[Comment] 私が持っているのはこれよりひとつ古い版だが，まぁいいか。むかし，車載用の組み込みエンジニアをやっていた頃は必読書として読まされました。今はもっと包括的な内容のものがあるはず。

reviewed by Spiegel on 2019-02-06 (powered by PA-APIv5)

CODE VERSION 2.0: ローレンス・レッシグ (著), 山形浩生 (翻訳); 翔泳社 2007-12-19 (Release 2016-03-14); Kindle版; B01CYDGUV8 (ASIN); 評価

[Comment] 前著『CODE』改訂版。

reviewed by Spiegel on 2018-11-17 (powered by PA-APIv5)

golangci-lint を GitHub Actions で使う

2020-09-29T02:20:19+00:00

golangci-lint は go vet をはじめ複数の lint を集約して結果を表示してくれる優れものである。かつては GolangCI.com で GitHub と連携できていたのだが，2020年4月でサービスが停止してしまい，寂しい限り。

と思っていたのだが，いつの間にか公式の GitHub Actions が用意されていた。気付かなんだよ。不覚。

golangci/golangci-lint-action: Official GitHub action for golangci-lint from it’s authors

使い方は簡単。リポジトリの .github/workflows/ ディレクトリに YAML ファイル（例えば lint.yml）を置き，以下のように記述する。

name: golangci-lint
on:
  push:
    tags:
      - v*
    branches:
      - master
  pull_request:
jobs:
  golangci:
    strategy:
      matrix:
        go-version: [1.15.x]
        os: [ubuntu-latest, macos-latest, windows-latest]
    name: lint
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v2
      - name: golangci-lint
        uses: golangci/golangci-lint-action@v2
        with:
          # Required: the version of golangci-lint is required and must be specified without patch version: we always use the latest patch version.
          version: v1.31

          # Optional: working directory, useful for monorepos
          # working-directory: somedir

          # Optional: golangci-lint command line arguments.
          # args: --issues-exit-code=0

          # Optional: show only new issues if it's a pull request. The default value is `false`.
          # only-new-issues: true

また，リポジトリ直下の .gitattributes ファイルに以下の記述を追加する。

*.go text eol=lf

これで pull request 時， master ブランチ¹ への push 時，およびバージョンタグを打った際に golangci-lint が走る。 golangci-lint は matrix の組み合わせで並列処理されるようだ。

よーし，うむうむ，よーし。

まぁ，プラットフォーム依存のコードでもない限り Go 最新バージョンの ubuntu-latest だけでいいと思うけどね。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

2020年10月から GitHub の新規リポジトリの既定ブランチ名が main になるらしい。ご注意を。 ↩︎

GolangCI でコード・レビューを自動化する

2019-12-15T05:05:25+00:00

この記事で紹介した GolangCI のレビュー・サービスは 2020-04-15 で終了するらしい。

GolangCI.com is closing - golangci - Medium

まぁ Go 言語自体がもっと普及しないと営利サービスとしては難しいのかもね。残念ではあるが lint ツール自体は公開を続けるそうな。うんうん，よかったよかった。

以前「golangci-lint に叱られる」で

GolangCI も気になるが，それはまたいつか

と書いたが，今回はその話。

GolangCI は GitHub と連携して機能するコード・レビュー・サービスで， GitHub 上のリポジトリにある Go 言語コードに lint をかけて結果を報告してくれる。 Pull request とも連携してレビュー結果を上げてくれるので，レビューにかかる労力をかなり引き下げることができる¹。

サインアップは GitHub アカウントで行うことができる。サインアップに成功したらリポジトリ一覧画面に行けるようになる²。

連携したいリポジトリに [Connect] するとレビューを開始するのだが，レビュー結果が表示されるまで結構時間がかかるみたい。実は随分前に GolangCI に登録していくつかのパッケージと連携させていたのだが，なかなか処理が終わらないので，そのまま綺麗サッパリ忘れ去っていたのだった（笑）

レビューが終わったリポジトリの [Report] を開くとこんな感じの画面になる。これは問題がなかったリポジトリの場合：

こっちは問題が発見されたリポジトリ：

このレポート結果を基にコードを修正する。当然ながら master ブランチ上で作業をしないこと。

修正を commit & push し，修正を行ったブランチから pull request をかける。 GitHub 側は pull request したコードに対して連携しているサービスを呼び出して事前チェックを行う。チェックにパスすればこんな感じになる。

問題があれば “Details” で問題箇所が示されるので，修正を行って再度 commit & push する。

GolangCI にはコマンドライン・ツールも用意されていて IDE やテキストエディタなどとも連携可能なのだが³，どうしても見落としがあるみたいで，リポジトリ全体をチェックしてくれるレビュー・サービスの存在はありがたい。

さて，他のパッケージも修正するか。

ブックマーク

無料で使える Go 言語の CI サービス『GolangCI』を使ってみる｜ Developers.IO

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド: MISRA‐C研究会 (編集); 日本規格協会 2006-10-01; 単行本; 4542503461 (ASIN), 9784542503465 (EAN), 4542503461 (ISBN); 評価

reviewed by Spiegel on 2019-02-06 (powered by PA-APIv5)

とはいえ GolangCI がチェックしてくれるのは lint レベルのコード・チェックなので，ビジネスロジック等の妥当性は人間が判断する必要がある。言い方を変えれば GolangCI で lint レベルのチェックを事前に行っておけば，人間はビジネスロジック等のチェックに専念することができる。 ↩︎
既定では公開リポジトリのみが対象となる。お金を払えばプライベート・リポジトリもチェックできるらしいが試していない。 ↩︎
ATOM エディタの場合は go-plus パッケージで Linter に golangci-lint を指定できる。 ↩︎

golangci-lint に叱られる

2019-02-06T14:15:43+00:00

私は Go 言語コードを ATOM エディタおよび go-plus パッケージで書いているのだが，最近の go-plus は lint に以下のツールを選択できるようだ。

特に golangci-lint は gometalinter より5倍も速いと豪語してるので，こちらを試してみることにした。 GolangCI も気になるが，それはまたいつか。

いやぁ，最近の lint は賢いんだね。特に古いコードのまま放置している部分についてどえら叱られたですよ。ボーっと生きててすみません（笑）

error を無視すんな

例えば io.Reader から io.Writer へデータを流し込むのにやっつけコードで

io.Copy(writer, reader)

とか書くことがあるが golangci-lint にかけたら「返り値の error を無視すんなや」って叱られた。ちゃんと書くなら

if _, err := io.Copy(writer, reader); err != nil {
    ...
}

とかすべき，ということだろう。明示的に返り値の error を無視するなら

_, _ = io.Copy(writer, reader)

などと明示すれば，とりあえず叱られない。まぁ安直にこう書いてしまうのは問題だけど。

true は不要

無限ループについて昔は何となく

for true {
    ...
}

とか書いていて，またも「true とか要らんけぇ」と叱られた。正しくは

for {
    ...
}

でよい。こういう「若気の至り」なコードがそこかしこに残ってて，黒歴史を見せられてるようでちょっと恥ずかしい。

SIGNAL のバッファリング

SIGNAL を channel として登録する際に誤って

ch := make(chan os.Signal)
signal.Notify(ch, sig...)

とか書いていて「ちゃんとバッファリングさせろや，ゴラァ」とまたまた叱られた。正解は

ch := make(chan os.Signal, 1)
signal.Notify(ch, sig...)

そんなことまで知っている golangci-lint は偉いねぇ。

Lint は知見のかたまり

というわけで過去の恥ずかしいコードが次々と発覚してしまい，公開しているコードのリファクタリングを行っている真っ最中である。色々やりたいことがあるのに横道に逸れてばっかり。

C 言語で書いてた頃は MISRA-C とかいった「事実上の標準」みたいなのがあって lint ツールとかも（少なくともエンタープライズ向けは）そういったものに準拠したものが色々あった。 Lint ってのはそのプログラミング言語に関する知見のかたまりなので上手に使いこなしていきたいものである。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド: MISRA‐C研究会 (編集); 日本規格協会 2006-10-01; 単行本; 4542503461 (ASIN), 9784542503465 (EAN), 4542503461 (ISBN); 評価