2008/08/28 6:30:04
75
18
15 zeromemory.sblo.jp [
この元コンテンツへ ]
プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。原則...
[
← 前の画面 ]
【 PR 】 もうデザインだけではいられない… [
ニコニコ風 ] [
関連記事 ] [
Feeling Lucky ]
■ この情報のコメント・メモ ■
人それぞれだなー、参考になる [ k_37to ]
コーディングルールは人それぞれで見る分には面白いし参考になるね。仕事で違いすぎる人とぶつかるとストレスになるけど…w [ s-e-i ]
そういえばSQLのコーディング規約って見たこと無いなぁ。カンマの位置はたしかに難しいところだ。前カンマに慣れちゃえば別にそれでいいような気もする。 [ lockcole ]
そもそもSQLを直で書かないようにしたらいいと思う。いや、そうもいかないレイヤでの話なんだろうけど。/自分で書くときはキーワード大文字、オブジェクト小文字、後カンマ、前AND/OR。 [ seamlessbias ]
prg [ webmarksjp ]
coding規約 [ svankmajer ]
SQLに限らず前カンマ便利だと思いますが。/流れで思い出した⇒http://www.geocities.jp/mickindex/database/idx_database.html見たことない人は一読しておいてよいよいよい。 [ FTTH ]
こういうのはありがたい。 [ wwolf ]
プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵はデ・ファクト [ ama2 ]
SQL文における自己流コーディング規約を公開。フィールドの追加変更やコピペがやりやすい前カンマ方式。 [ wacky ]
SQLに関しては前カンマのほうが効率が良いのではないかと思っている。理由は開発中は取得フィールドの追加変更や切り貼りが多いから。←なるほど。こういう視点があったか [ h5y1m141 ]
大文字小文字は逆だなぁ。キーワード大文字で項目は小文字。エディタで置換してる。あとは前コンマ、AND/ORも前かなぁ。 [ moro ]
つーか,SQL文もこういうふうに複数行で書いていいものだったのか。今度から気をつけよう [ myrmecoleon ]
この辺りは大変気になっていたので参考になりました。 [ nui81 ]
sqlの書き方って、揺るぎない正解が他の言語よりも無い気がする。みんな悩みながらやってるのね。書きやすさの前カンマ、読みやすさの後カンマという認識なので、余程のやっつけ仕事じゃない限りは後カンマ。 [ poolmmjp ]
視認性のためキーワードは大文字で、比較的文字数の多くなる項目は小文字、切り貼りのために前カンマ、前スペース、あとは、テーブルには視認性に「t_」(table)or「m_」(master)をつけておく、ついでに前AND、後ろOR派 [ tot-main ]
仕事用 [ dispace ]
[
← 前の画面に戻る ]