タグ

code-rulesに関するrudo108のブックマーク (5)

  • iOSアプリのコーディング規約を考える時はGoogleよりもNYTimesのObjective-Cスタイルガイドを参考にすべき - Steel Dragon 14106

    iOSアプリのコーディング規約を考える時はGoogleよりもNYTimesのObjective-Cスタイルガイドを参考にすべき By raimon, 2015-03-21(土), in category Ios Googleのスタイルガイドは古い 複数人でiOSアプリをObjective-Cコードで書いて保守する時、コーディング規約を検討することになる。 参考にすべきスタイルガイドとして良く挙がるものにGoogle Objective-C Style Guideがあるが、これはいかんせん古い。メモリ管理ARCやNSNumberのリテラル構文など、比較的新しいトピックについても追記されてはいるが、 インスタンス変数のアクセス修飾子 プロパティを使う事が主流となっている2015年現在、余り扱われない autorelease を使ったオブジェクト生成など、MRC時代の規約 何よりホスティング先が

  • キャメルケースよりスネークケースで。 - 偏見プログラマの語り!

    プログラムを書くとき、たいていは何らかの命名規則に従って識別子を書くわけですが、その種類はだいたい 2 つじゃないかと思います。 ・スネークケース:スペースをアンダースコアに置き換えた表現。( chocolate_pie, candle_cake, ... ) ・キャメルケース:スペースを詰めて次の語を大文字から始める表現。( chocolatePie, CandleCake, ... ) プログラムってのは名前が 8 割とか言うひともいますけども、なんだかんだと複合語を記述する場面は死ぬほどありますし、しかも多くのプログラミング言語がスペースをトークンの区切りとしている以上、何かルールを設けないといけないんですよね。そうしないと「複合語の中にあるスペース」と「トークン区切りとしてのスペース」を区別できない。区別できないっていうかプログラム書けない。 で、どういうルールで書くかっていうと標

  • メソッド名をシンプルにするために、 知っておくと便利な英語のprefixとsuffix - codic ブログ

    メソッド名などをネーミングする際に、知っておくと便利な、接頭辞と接尾辞をリストアップしてみました。どのように元の単語の意味が変わるかのルールを知っておくと、よく使う単語をベースにボキャブラリーを増やすことができるので、覚えておいて損はないと思います。 使う場合は、当たりを付けて実際の使用がないか、Googleなどで調べてみてください。 1. pre-, post- / 事前〜、事後〜 per-は、元の意味に “事前に、前に”、post-は “事後に”という意味が付け加わえます。汎用性が高いのでとても便利です。afterやbeforeの代替になるかもしれません。 // 事前テストする function testBefore(); ↓ function pretest(); // 事後処理する function executeAfter(); ↓ function postexecute();

  • Rubyコーディング規約

    はじめに 文書は、Rubyによりコーディングを行う際の規約について述べる。 実際のプロジェクトに適用する際には、このコーディング規約をカスタ マイズして用いることを推奨する。 ソースコードの整形 インデント プログラムを読みやすくするため、インデントを適宜行う。インデント 幅は2とする。また、インデントにはスペースのみを使用し、タブは使用 しない。(環境によりタブ幅が異なるため。) 例: if x > 0 if y > 0 puts "x > 0 && y > 0" end end 一行の桁数 一行の桁数は最大80桁までとする。 空行 複数のクラスの区切には空行を挿入する。 例: class Foo ... end class Bar ... end 誤った例: class Foo ... end class Bar ... end また、クラス内の各構成要素の区切にも空行を挿入する。

  • C#コーディング規約の個人的なまとめ

    コーディング規約は非常に色々なものが提案されているが、その色々なものを見て来た中で、かなり自分勝手な方向でまとめてみる。 はじめに コーディング規約というのは、さまざまな団体で独自に定められており、時にはそれが競合することもあろうかと思う。特にC++のプレフィックス関連が顕著だと思う。それに比べて、C#は割りと落ち着いたコーディング規約が根付いているのか、私の短いプログラミング人生の中で、そこまで読みにくいと思ったコードを見たことがない。これは、C#の言語構造やVisualStudioの自動整形も関係しているのかもしれないが。 というわけで、厳格なコーディング規約を設けずとも、それなりに読めてしまうC#でも、やはり規約を定めて、より読みやすく、統一性を持たせたコードを生産することは、非常に有意義なことだと考える。 代表的な記法 C#の命名規約についてを参考にしてほしい。一部を抜粋しておく。

    C#コーディング規約の個人的なまとめ
  • 1