StandardSQLのLinterを作りました - Qiita
概要 StandardSQL(BigQuery)のSQL Linter/Formatterを作りました. 需要はあんまりなさそうですが、せっかくなので内容について少し書いてみます. コードはこちら https://github.com/shigeru0215/sqlint モチベーション 仕事で結構BigQueryのSQLを書くことがあるのですが、メンバによって細かい書き方が違ったのでチーム内でルールを決めました. 理由は、主に見やすさのためです. 例えば、以下のような感じです. select /* 予約後はすべて小文字 */ a /* インデントは4つずつ */ , b /* 改行のカンマは行末ではなく行頭にする */ from table1 as t1 inner join table2 as t2 on t1.x = t2.y /* fromで一段下げ, onでも一段下げる */ w
SQL Style Guide
A set of conventions and guidelines for writing SQL at GitLab SQL Style Guide This guide establishes our standards for SQL and are enforced by the SQLFluff linter and by code review. The target code changes that this stile guide apply to are those made using dbt. If you are not on the Data Team or you are developing SQL outside of dbt, keep in mind that the linting tools may be more difficult to a
SQLスタイルガイド · SQL style guide by Simon Holywell
概要 全般 推奨 非推奨 命名規則 通則 表 列 別名、相関名 ストアド・プロシージャ 統一的接尾辞 問合せ文 予約語 空白類 インデント 望ましい形式 Create文 データ型の選択 デフォルト値の指定 制約とキー 非推奨設計 付録 予約語リファレンス SQLスタイルガイド（日本語訳） 日本語訳について 日本語訳は誤訳や原文の最新版に追随していない恐れがあります。誤訳や改善点があれば、GitHubのissueまたはpull requestを使用するか、Twitterでお知らせください。 翻訳: 久利史之 @nkuritw 概要 このガイドラインは利用の他、forkしたり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubのissueまたはpull requestを使用してください。 このガイドライン
「分析SQLスタイルガイド」をかなり真面目に考えた - Qiita
目次 なぜSQLのスタイルガイドが重要なのか この記事の目的 この記事の対象者 分析SQLスタイルガイドの指針 基本ルール 命名規則 インデントルール 別名ルール joinルール クエリ分割ルール ⭐ コメント欄で「いや私はこう思う！」という意見をたくさんいただきました！ぜひそちらも御覧ください！（決して揶揄ではないです） なぜSQLのスタイルガイドが重要なのか SQLはプログラミング未経験者でもとっつきやすい言語と言われ、エンジニアや分析を本業としていない人でもSQLを使う機会が増えてきていると思います。 そんなSQLですが、こちらのブログでも指摘されている通り、一般的なスタイルガイドが定まっていません。スタイルガイドとはコードの書き方マナーようなもので、どこで改行するか、空白はいくつ入れるか、大文字を使うかなどの諸々を指します。 もしスタイルガイドが無いとこんな事が起こります コードに
メソッドに対応関係を持たせる - kagamihogeの日記
バグ出した、ってわけでもないんだけど。ちょっと気になったコードがあったので。 amazon:Code Complete第2版〈上〉―完全なプログラミングを目指して曰く、 〜良いルーチン名のガイドラインより ■正確な反意語を使用する 反意語の命名規則を設けると、一貫性を保ちやすくなり、読みやすさにつながる。first/last のような反意語の組は、一般的に理解されている。それに対して、FileOpen() と _lclose のような反意語の組は対称的でなく、紛らわしい。 setter/getter なんかが良い例。必ずしも対応関係のあるメソッドばかりでもないけどさ。 で、今日見かけたのはこんなコード int getHogeId() { ... } void releaseHoge(int hogeId) { ... }hoge っていうのは何かしらのハードウェアリソースと思ってもらえれば
処理の連鎖をどう書くか？ - 演算子方式とメソッドチェイン方式 - NyaRuRuが地球にいたころ
算術演算の拡張 普段あまり意識しないかもしれませんが，算術演算も「処理の連鎖を組み合わせて大きな処理を書く」の一種です．個々の演算で引数の型と戻り値の型がどう対応するかは事前に決まっていて，式全体の型はその組み合わせから自然に導出されます． var r = (((1 + 1) - 100) * 1.0f) / 10; C# の算術演算は基本的に C/C++ のそれをそのまま拝借しているのでなじみやすいのですが，いくつか拡張している部分もあります．例えば C# 2.0 で導入された Nullable 拡張などがそれです． var r = (((x + 1) - 100) * y) / 10; xの型 yの型 rの型 int int int float int float int float float int? float float? float int? float? C# の Null
JavaScriptのコーディングスタイル 2.0 — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
Confessions of a Ruby Sadist sudo gem install flog
Flog shows you the most torturous code you wrote. The more painful the code, the higher the score. The higher the score, the harder it is to test. Run it against your best stuff. I double-dog dare you. Flog essentially scores an ABC metric: Assignments, Branches, Calls, with particular attention placed on calls. Run flog on all your code. Try this: find lib -name \*.rb | xargs flog Whatever is at
ChangeLog の作法 steps to phantasien t(2005-10-13)
ソースコードなどの変更履歴を ChangeLog と呼ぶ. オープンソースのソフトウェアで変更履歴を "ChangeLog" というファイルに書いたのが ChangeLog のおこりだと思う. 最近は Subversion などに登録された変更履歴も change log, あるいは commit log などと呼ぶ. 以下ではそれらを ChangeLog と総称する. 最近わけあってこの ChangeLog をどう書いたものかと考えている. コーディング規約には山ほど資料がある. コメントの書き方もよく議論される. しかし ChangeLog についての読み物は少い. GNU コーディング規約 は数少ないそうした文書である. この説明はよくかけている: ChangeLog は将来のメンテナがバグの原因を探るのに使うものだ. コメントに書くべきものはコメントに書け. 関数名を並べろ...
C++ Coding Standard
Using this Standard. If you want to make a local copy of this standard and use it as your own you are perfectly free to do so. That's why I made it! If you find any errors or make any improvements please email me the changes so I can merge them in. I also have a programming blog at http://radio.weblogs.com/0103955/categories/stupidHumanProgramming/ that is accidently interesting at times, as is my
||=とdoを使ってキャッシュ - Unknown::Programming
たとえばメンバ変数にオブジェクトとかをキャッシュするときに、 sub method { my $self = shift; return $self->{hoge_obj} ||= Hoge->new; } とか良くやるんだけど、前処理とかが必要な場合はdo使って sub method { my $self = shift; return $self->{hoge_obj} ||= do { ### 前処理 Hoge->new; }; } こんな感じで良くやるんだけどもコレって一般的なのかな？ 前にどっかのソースで、 sub method { my $self = shift; my $code = sub { ### 前処理 return Hoge->new; }; return $self->{hoge_obj} ||= $code->(); } っていう感じのを見たんだけどどっちがい
PEAR 標準コーディング規約
注意 PEAR 標準コーディング規約は、 PEAR の公式ディストリビューションに含まれるコードに適用されます。 コーディング規約 (Coding standards) は、開発者たちの間ではよく CS と略されます。この規約の狙いは、コードの一貫性を保つことと PEAR の開発者たちがコードを保守しやすくすることにあります。 インデント 空白 4 つのインデントを使用します。タブは使いません。 これにより、diff や patch、CVS history や annotations の際に問題が発生するのを避けることができます。 Emacs を使用する場合、indent-tabs-mode を nil に設定する必要があります。 Emacs を設定するモードフックの例を次に示します (PHP ファイルを編集する際に これがコールされるようにする必要があります)。 (defun php-
自転車置場の議論 - bkブログ
自転車置場の議論 人が集まると、なぜかどうでもいいようなことほど議論が紛糾してしまう傾向がありますが、このような現象のことを、FreeBSD のコミュニティでは自転車置場の議論 (bikeshed discussion) と呼んでいることを知りました。 この、「瑣末なことほど議論が紛糾する現象」はパーキンソンの法則という本の「議題の一項目の審議に要する時間は、その項目についての支出の額に反比例する」という法則として知られています。 この本の中で著者は、原子炉の建設のような莫大な予算のかかる議題については誰も理解できないためにあっさり承認が通る一方で、市庁舎の自転車置場の屋根の費用や、果ては福祉委員会の会合の茶菓となると、誰もが口をはさみ始めて議論が延々と紛糾するというストーリーを紹介しています。 このように、「瑣末なことほど議論が紛糾する現象」はパーキンソン氏によって見事に説明されているの
83's : vimで代入文を=でそろえる for Ruby, Perl
Align.vimっていう、ここに載せたものより高機能なスクリプトがあります。 代入文がたくさん並んでると、なんか見にくいですよね。 @close_listeners = [] tool_bar = Gtk::HBox.new @label_title = Gtk::Label.new @btn_close = Gtk::Button.new('X') @moz = Gtk::MozEmbed.new 以下のようになったら見やすいよね？ @close_listeners = [] tool_bar = Gtk::HBox.new @label_title = Gtk::Label.new @btn_close = Gtk::Button.new('X') @moz = Gtk::MozEmbed.new viについてちょっと調べものをしていたら ヽ( ・∀・)ノきゅまきゅまーさんのところ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Reddit - Dive into anything
Introduction — sql-lint 0.0.11 documentation
GitHub · google/yapf: A formatter for Python files
GitHub - databricks/jsonnet-style-guide: Databricks Jsonnet Coding Style Guide
プログラムのコードには、個人を識別できる“指紋”が残されている：研究結果
株式会社 社会式株 PHPコーディング規約