タグ

コーディングに関するcomoglyのブックマーク (8)

  • accessclub.jp - このウェブサイトは販売用です! - アクセスクラブ リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

  • 俺的コーディングルール SQL編 - suVeneのアレ

    プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード=大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押すのが面倒という理由で小文字に変えた。では何故オブジェクト名

  • プロとしての行為 Act as Proffesional

    1.一般的なコーディング規約に目を通し、エレガントなコードを知る エレガントなコードを書くためには、エレガントなコードを知らなければならい。その土台を築いているコーディング規約について、オープンソースではどのようなものが使われているのか理解しておこう。入社する予定の会社が採用している言語については必ず目を通しておこう。 PHP PEAR 標準コーディング規約 symfony CodingStandards Perl perlstyle Ruby クックパッド株式会社のRubyコーディング規準 Matzスタイル NaClで採用している規約 Python PEP 8 そして、あなたの身近にあるオープンソースのコードを実際に読んでみよう。この時点でコードの仕組みや設計が理解できなくても良い。コードがエレガントかどうか?を感じ取って欲しい。こう書いた方が、良いのではないか?など、考えてみよう。

    プロとしての行為 Act as Proffesional
  • codic - デベロッパーのためのネーミング辞書

    codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。

    codic - デベロッパーのためのネーミング辞書
  • 404 Error - File Not Found

    指定されたファイルは見つかりませんでした。 10秒後に トップページ にジャンプします。

  • HTML5のimg要素のalt属性の仕様は読んでおくべきだと思う。

    読んでおくべき。で終わってるタイトルが、自分っぽくなくて違和感有り有りだったの何となく変更。 都道府県選択するやつ。がもしかしたら一日辺りの過去最高のアクセスを稼いだかも知れないという現実。 7月16日のアクセスが17,000PVオーバーって何だ・・・おかしいな、ウチはCSSネタが主力なのに・・・あぁ複雑。 題ですが、HTML5のimg要素のalt属性に関する仕様がすごい事になってますね。 ちょっと読んでて泣きそうになるくらい事細かに書かれています。 これは、コーディングを生業としている人間なら覚えていなければならないと思うので、必読すべき内容です。 4.8.2.1 Requirements for providing text to act as an alternative for images 4.8.2.1 イメージの代替として作用するテキストを提供するための要件 ざっくりまとめ

    HTML5のimg要素のalt属性の仕様は読んでおくべきだと思う。
    comogly
    comogly 2009/08/04
    その画像が無くても完全に意味が伝わるようにしろ
  • ひどすぎるネーミング - idesaku blog

    UKTKKNSHINF こういう名前の変数が出てくるのだが、意味わかる? 答え:受付禁止情報 今読んでいるPL/SQLコードは当にひどい出来なのだが、その中でもネーミングが群を抜いてひどすぎてむしろ笑えてくるので、ここでさらしてみたい。 先ほどの例でわかると思うが、悪しきネーミング習慣である子音母音抜きの嵐である。変数名だろうが関数名だろうがこのルールで命名されているので、暗号文を読んでいるような気分になる。 他には、例えばこんなのがある。 SKSI 作成 HNKN 変換 KKT 確定 CHKN 中間 DTM Datetime DTA Data こうして見ると、ktkrやwktkとなんら違いがない。 "作成"のような、比較的簡単に対応する英単語が見つかるものまで日語子音母音抜きで書くという徹底ぶり。でも"情報"はINFだったりする統一感のなさ。そしてこれらが単独ならまだしも、複合して出

    ひどすぎるネーミング - idesaku blog
  • 俺コーディング規則 - Cube Lilac

    最近,他人が自分のコードを読んだり修正したりする機会が増えてきたので,意思疎通のために自分のコーディング規則をメモしておきます.CLX C++ Libraries も(たまにブレてますが)ここに挙げる規則に従って書いているので,コードを読む際の参考にでも. 尚,以下は基的に自分が守っているだけで,他人は(単一プロジェクト内のコード間で整合性が取れる範囲で)自分の信念に基づいてコーディングしていけば良いんじゃないかな,と思っています. 名前空間 グローバル名前空間には,クラス/関数を(極力)定義しないようにします.通常は,プロジェクト毎に適当な名前空間を考えて,その名前空間内に各種クラス/関数を定義します.ただし,ユーザに使用されることを意図していないクラス/関数に関しては,使用する名前空間の中でさらに detail 名前空間を定義して,その中で定義します. クラス設計 クラスは, x.i

    俺コーディング規則 - Cube Lilac
  • 1