2021年Python開発リンター導入のベストプラクティス
この記事は何？ Python 開発における リンターの利点 数ある Python リンターの違い・特徴 導入方法 おすすめの設定 リンターを（部分的に）無効化する方法 を紹介しています。 昨今の状況を踏まえた上で、多くのプロジェクトで適用できる構成になっていると思います。 リンターって何？ コードをチェック・解析するツールのことです。静的解析ツールとも呼ばれます。参考）lint (Wikipedia) 導入することで、以下の効果が得られます。 バグの発生が減る 保守性の高いコードを書けるようになる チーム内でのコーディング規約（コードの書き方のルール）を自動的に守れるようになる リンターが簡易自動テストのように働く場面もある 本稿では「チェックするだけでなく、自動であるべき形に整形までしてくれる」フォーマッターについても、リンターとして扱い紹介します。 リンターが導入されない理由 リンター
vulture で未使用のクラス/メソッド/関数/変数を探す - Qiita
実行 インストールが完了するとvultureコマンドが使えるようになっています。そのコマンドを使って実行します。 全てのオブジェクトが使われている状態 定義されている全てのオブジェクトが使われているサンプルコードを作りました。 # -*- coding: utf-8 -*- USE = 'use' class Use(object): use_attr = 'use' def use(self, value): self.use_attr = value return self.use_attr def use(): Use.use(USE) if __name__ == '__main__': use()
Pythonのコード改善のためのツール5つを試してみた - minus9d's diary
Pythonのコードを改善するためのツールについて一通り試してみました。各ツールのインストール方法や使い方については Pythonのスタイルガイドとそれを守るための各種Lint・解析ツール5種まとめ！ - Sider Blog に詳細にまとまっているのでおすすめです。 サンプルコード 以下のサンプルコードを対象に、各ツールの出力を確かめてみます。 import time import sys import fractions def func1(varA,varB): '''return sum of a and b''' varC = 42 return (varA + varB) print(func1(fractions.Fraction(1, 2), fractions.Fraction(1, 3))) 3 + 5 sys.exit(0) このスクリプトをsample.pyという名
SwiftLintのカスタムルールを使って、スクリーン計測用コードの実装漏れを防ぐ - Qiita
この記事では、SwiftLintのカスタムルールを使い、Google Analyticsのスクリーン計測用コードの実装漏れを防ぐ方法をご紹介します。 SwiftLintのカスタムルールを使うと、気合や根性で何とかしていた問題を、ルールに落とし込むことができ、ミスが減ります。 背景 アプリを開発する際に、ユーザーの行動計測を目的として、Google Analyticsのスクリーン計測を使うことは多いと思います。このスクリーン計測を利用する際には、各ViewControllerに手動でイベント計測コードを埋め込むことになりがちです。1 手動でのイベント計測は正直苦行であり、実装漏れも起きやすくなります。 Method swizzlingを使って、viewDidAppear() を置き換え、自動計測を行うような方法も提案されていますが2、黒魔術的なコードを本番アプリに組み込むのは気が引けました。
Android Studioで使うgradleのlint - LIFULL Creators Blog
こんにちはAndroid開発グループ橋本です。 今回はAndroidStudioで使うlintについて調査する機会があったので内容を記事にします。(lint自体の解説は省略します。) まずは実行をしてみる。 Androidのlintの実行について調べてみると、Android/sdk/tools/の下にあるlintが使用できるようです。 参考：http://developer.android.com/intl/ja/tools/help/lint.html この方法だといちからlintのオプション設定を行わなければいけないため、とても手軽に使えるとは言い難いものです。ではどうしたらいいのか？そもそも開発はAndroid Studioを使う事を前提としていたのでそちらで実行したいところです。 Android Studioから実行 AndroidStudioから実行する場合、実はとても簡単で、メ
jscs·奇麗なコードを書こう。JavaScriptコーディングスタイルチェッカー MOONGIFT
奇麗なコードは可読性も高く、バグも減りますよね。 JavaScriptは下手に書くとものすごくスパゲティなコードになりやすい言語ではないでしょうか。ただでさえコールバックを使うのでネストしやすく、さらに処理が非同期だったりするとカオスになりがちです。 そんなJavaScriptのコードも機械的にチェックすれば問題点が洗い出されて可読性が高くなるかも知れません。そのためのチェックツールがjscsです。 インストールはnpmを使って行います。インストールが終われば次のようなヘルプが出せるようになります。 $ jscs --help Usage: jscs [options] <file ...> Options: -h, --help output usage information -V, --version output the version number -c, --config [p
Foodcritic - A lint tool for your Opscode Chef cookbooks
Foodcritic has two goals: To make it easier to flag problems in your Chef cookbooks that will cause Chef to blow up when you attempt to converge. This is about faster feedback. If you automate checks for common problems you can save a lot of time. To encourage discussion within the Chef community on the more subjective stuff - what does a good cookbook look like? Opscode have avoided being overly
Chef Cookbook のスタイルをチェックしてくれる Foodcritic を使ってみた - P A R A G R A P H S
Foodcritic - A lint tool for your Opscode Chef cookbooks Foodcritic というのは「Chef の Cookbook のスタイルをチェックしてくれる Lint ツール」みたいなやつで、どんなものなのか気になったので少し触ってみた。 インストール $ rvm use 1.9.3 $ gem install foodcritic $ foodcritic # 正常にインストールされると foodcritic コマンドが使えるようになる とりあえず使ってみる 「使ってみる」と言っても foodcritic [チェックしたい cookbook のパス] を実行するだけ。デフォルトではこのページに載っている 32 個のルールでチェックが行われる。試しに Opscode 公式の mysql cookbook をチェックしてみた。公式なのにけ
foodcriticでChefのcookbookの書き方をチェックする方法
foodcriticはChefのcookbookのためのlintツールで、http://acrmp.github.com/foodcritic/ で公開されています。 cookbookは長い間環境を維持していくために使われるため、可読性が高く誰でも分かるように書いておくことが望ましいのは言うまでもありません。このツールでは標準で45個のルールにしたがってcookbookをチェックすることができます。もちろん自分でルールを新たに追加していくことも可能です。 インストール動作させるには、ruby 1.9.2以降が必要です。インストールはgemでさくっと入ります。gem install foodcritic 実行方法実行方法も簡単です。引数にcookbookの名前を指定すればOKです。foodcritic php その他の実行オプションとしては以下があります。 foodcritic [cookb
High-Quality JavaScript Code ツールまとめ
というスライドの流れが結構良かったので紹介。 AKQA Anoraks というイベントで発表されたもので、 タイトル通りコードのクオリティがテーマの内容です。 内容的には、モジュールパターン、JSDoc、コードレビュー、Lint、テスト、自動化、コードカバレッジ、ステータスの可視化 のツール、サービスなどを それぞれ軽く触れられていて、最近見る感じのツールが良い感じの流れでまとまってる気がします。 ただ、スライドにURLやツール名が載ってなかったので、自分で書きだしたものをまとめておきます。 Module/JSDoc YUIDoc - Javascript Documentation Tool Peer Code Review ピアコードレビューツール | Atlassian Static Code Analysis JSHint, a JavaScript Code Quality To
Objective-CのLintツールについて – xctoolとOCLintの連携方法
というように-reporter json-compilation-databaseを指定してテストを動かすと、compile_commands.jsonファイルを生成してくれます。 このファイルはビルドコマンドやファイル等がまとまってるだけで、これをOCLintに読み込ませてLint結果を取得するoclint-json-compilation-database というコマンドが用意されています。(OCLintに) シェルスクリプトにまとめると以下のような感じです。 #!/bin/sh OCLINT_HOME=~/local/oclint/bin export PATH=$OCLINT_HOME/bin:$PATH xctool -reporter json-compilation-database:compile_commands.json clean xctool -reporter j
JSHint+Closure Linter+Gruntで最強のLint環境を目指してみた - はてブロ@ama_ch
先日JSHint 1.1.0がリリースされ、そのリリースノートに気になる記述がありました。 Adds new option gcl to make JSHint style checks compatible with Google Closure Linter. うそーまじでーなにそれヤバイ！ 普段は仕事でClosureにどっぷりなせいもあってClosure Linterを使っているんですが、Closure LinterってJSDocとかお作法的なとこはチェックしてくれるけど、他のLintツールが当たり前にチェックしてくれるとこはやってくれないんですよね。たとえばvarの付け忘れとか。 Closure Compilerを使ってコンパイル時にチェックすることもできるけど、規模が大きくなってくるとその結果が出るまでに10分とか待たないといけなくっていやな感じー。Closure Linterと
oinume journal
Raycastを使い始めて1年経ったので、どういうことに使っているかを振り返ってみる。去年書いた AlfredからRaycastに移行した - oinume journal の記事から少し使い方が変わっているところもあるのでメモがてら。 基本的な使い方 Cmd + QをRaycast起動のショートカットとして割り当てている。Pro版は使っていないのでAI機能などは使ったことがない。 ブラウザのブックマーク検索など、よく使うけどHotKeyを割り当てるほどでもないRaycastコマンドはbmのようにAliasを設定している。 Cmd + QでRaycastを起動してbmと入力するとブックマークの検索ができるので楽ちん アプリケーションランチャー機能 アプリケーションを起動するときのランチャーとして使っている。よく使うアプリにはHot Key(ショートカット)を割り当ててる。 Clipboar
text-hatena.js を GitHub に移動した
2005 年ごろに作成して放置していた text-hatena.js について、twitter で @nitoyon さん、2005年くらいのtext-hatena.js をGitHub等に公開は可能でしょうか？ tech.nitoyon.com/javascript/app… — テラまこさん (@teramako) 12月 17, 2012 というツッコミを受けたので GitHub で公開してみました。 nitoyon / text-hatena.js - GitHub いま text-hatena.js のコードを読み返すと、グローバルな名前空間を汚染してたり、Object.extend() を定義してたりと、いろいろ酷い。 当時は今に比べると JavaScript の知識も浅かったが、浅いなりに prototype.js のコードを読んだり、真似したりして勉強していたことを思い出し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - hadolint/hadolint: Dockerfile linter, validate inline bash, written in Haskell
DockerfileをLintする - Qiita
既存プロジェクトにSwiftLintを導入した話
GitHub - realm/SwiftLint: A tool to enforce Swift style and conventions.
GitHub - jfahrenkrug/StoryboardLint: A lint tool for UIStoryboard to find wrong classes and wrong storyboard/segue/reuse identifiers
GitHub - koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts
