GitHub - isocpp/CppCoreGuidelines: The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
"Within C++ is a smaller, simpler, safer language struggling to get out." -- Bjarne Stroustrup The C++ Core Guidelines are a collaborative effort led by Bjarne Stroustrup, much like the C++ language itself. They are the result of many person-years of discussion and design across a number of organizations. Their design encourages general applicability and broad adoption but they can be freely copie
1000万行のコードと向き合う3つのステップ――富士ゼロックスはリファクタリングにどう取り組んでいるのか
1000万行のコードと向き合う3つのステップ――富士ゼロックスはリファクタリングにどう取り組んでいるのか（1/2 ページ） 大企業では実施が難しいと思われるソフトウエアのリファクタリング。富士ゼロックスでは、どのように取り組んでいるのか。リファクタリングの実施を決断した理由、課題とその対応方針、成果、今後の展望などについて聞いた。 バグの有無ではなく保守性を品質管理の指標にすべき 1962年設立の富士ゼロックスは、主に複合機やオフィスプリンターなどに内蔵されるコントローラーソフトウエアの開発を行っている。コントローラーソフトウエアは、スキャナーで撮り込んだ画像の加工や印刷、ネットワーク経由の通信、セキュリティなどの各種機能を、操作パネルのユーザーインターフェースを介して制御しており、昨今の多機能なオフィス機器の要といえる。 一方で、多機能になったことでコードは大規模かつ複雑化の一途をたどっ
品質の文脈でコメントの代わりのメソッド導入が安易に受け入れられない理由 - きしだのHatena
前提 目的は品質であり、品質のために読みやすさを求める。 メソッドを導入するとコードの複雑度はあがる。 コメントの記述ではコードの複雑度はあがらない。 コードの複雑度が高くなるとバグがでやすくなる。 バグがでやすくなると品質はさがる。 ここまでは今回前提とさせてもらいます。なので、ここで異論があれば、あぁそこに考え方の違いがあったのね、ということで。 目的が読みやすさであれば、まあそれで読みやすい人もいるんですねぇ、ということで終わらせることもできます。 ただ、このまえのエントリでは、品質がテーマです。 そういう前提では、読みやすいだけじゃなくて、品質を落とさないということも大事になります。 メソッドの導入は、基本的に複雑度をあげるので、それはそれでやりすぎるとバグの原因にもなっていきます。 もちろん、メソッドによって式や処理に名前をつけるというのは、複雑度をあげたことを補ってあまる効果が
品質におけるコメントの役割。あるいは、レビューとコメント - きしだのHatena
昨日のエントリでも書いたきょんくんとの会話なんだけど、なんとなく、コメントとテストは同じように扱えるんではないかという認識のもとで話がすすんでた。もちろん、コメント書けばテスト書かなくていいとかそういうのではなくて。 テストは、書きやすい対象と書きにくい対象がある。関数的に計算を行うコードの場合はテストが書きやすい。一方で、関数的ではなく副作用のあるコードはテストが書きにくい。データベースを扱ったり通信したりUIがあったり。 そして、そのようなテストを書きにくいときに、コメントはテストのように品質のために使えるんではないか。 で、問題は、どのように品質のために使うかということなんだけど、コードレビューのときの指針として使えばいいんじゃないかなと思った。 コードレビューのとき、コードだけを見ていると、名前付けとかコードの順番とか条件文の使い方とか、体裁的なものだけのレビューになりがち。そこで
コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId
Cutting Edge - ソース コードを読みやすくするヒント
ソース コードを読みやすくするヒント Dino Esposito International Obfuscated C Code Contest (国際難読化 C コード コンテスト) というのを聞いたことはありますか。簡単に言えば、故意に読みづらい C 言語コードで問題を解決するプログラムを書き、そのコードの汚さを競う公開コンテストです。ここ数年間に優勝したプログラムのソース コードは、ioccc.org/years.html (英語) で公開されています。 C コードの難読化を競うコンテストは、プログラミングのスタイルや読みやすさの重要性がわかる愉快な取り組みです。今回は、自身にも同僚にも読みやすく、理解しやすいコードを書くために従いたい最も重要な実践手法をいくつか紹介します。 読みやすさという特性 ソフトウェア開発におけるメンテナンスの容易さとは、既存のコードを変更する場合の容易さを
Input: Fonts for Code
# coding=utf-8 from vanilla import * from defconAppKit.windows.baseWindow import BaseWindowController from mojo.events import addObserver, removeObserver import math class ShowMouseCoordinatesTextBox(TextBox): def __init__( *args, **kwargs): super(ShowMouseCoordinatesTextBox, self).__init__(*args, **kwargs) addObserver("mouseMoved", "mouseMoved") addObserver("mouseDragged", "mouseDragged") addObse
キャメルケースよりスネークケースで。 - 偏見プログラマの語り！
プログラムを書くとき、たいていは何らかの命名規則に従って識別子を書くわけですが、その種類はだいたい 2 つじゃないかと思います。 ・スネークケース：スペースをアンダースコアに置き換えた表現。( chocolate_pie, candle_cake, ... ) ・キャメルケース：スペースを詰めて次の語を大文字から始める表現。( chocolatePie, CandleCake, ... ) プログラムってのは名前が 8 割とか言うひともいますけども、なんだかんだと複合語を記述する場面は死ぬほどありますし、しかも多くのプログラミング言語がスペースをトークンの区切りとしている以上、何かルールを設けないといけないんですよね。そうしないと「複合語の中にあるスペース」と「トークン区切りとしてのスペース」を区別できない。区別できないっていうかプログラム書けない。 で、どういうルールで書くかっていうと標
最適化の第二法則（要約版） - OGINO Masanori@はてな
これはThe Second Law of Optimization (Abridged) – the Voidの日本語訳です。原文と同じく、Creative Commons 表示 - 非営利 - 継承 3.0ライセンスの下で自由に利用できます。 僕は同じ題名の元の記事（英文）がみんなが読みたいと思うよりも長いと気付いたので、要約したものを用意した。 今や誰もがこの「最適化のマントラ」を聞いたことがあるだろう。「やめとけ」 これは一般的に三つのルールに内包されている。最初の二つはこのマントラの複製で、三つ目のルールは「まだ」という抜け目のない言葉を唯一無二のルールに付け加えて「エキスパート」に宛てている。 時期尚早な最適化――僕らの大部分は身に覚えがある。この言葉がとても有名な理由だ。言うなれば格言だ。アルゴリズムを肉付けせず、結果をよく確かめもしない内に、ただ出力に驚嘆してスマートなトリッ
JavaScriptのプログラミングスタイルはどうあるべきか？ 重鎮Douglas Crockford氏が脳の働きとの関係を語る（前編）。QCon Tokyo 2013
JavaScriptのプログラミングスタイルはどうあるべきか？ 重鎮Douglas Crockford氏が脳の働きとの関係を語る（前編）。QCon Tokyo 2013 4月23日に都内で開催されたエンジニア向けのイベント「QCon Tokyo 2013」。基調講演に登壇したのは、JavaScriptの重鎮であるDouglas Crockford氏。「プログラミング・スタイルと私たちの脳」という大胆なタイトルで、JavaScriptプログラミングにおいてバグをどう減らしていくのかについて解説しています。 基調講演の内容をダイジェストで紹介しましょう。 プログラミング・スタイルと私たちの脳 PayPalのDouglas Crockford氏。 プログラミングスタイルはプログラムの一部ですが、コンパイラからは無視されます。だからある人はプログラミングスタイルが重要ではないと考えていますが、しか
読みやすいコードってどんなものか考えてみた -抽象化と名前重要- - tumblr
あらすじ 人の綺麗なコードを読みまくると自分のコードも綺麗になっていくのに、イケメンを見続けても僕の顔が良くならないのは何故なの?? 2012-11-30 19:41:20 via web 今まであまり人のコードを読む習慣というか機会というかがあまりなかったのですが、最近になって、デスクの上がヨドバシのiMac売り場みたいと(僕の中で)話題沸騰中の@mitukiiiさんのコードを読む事があり、この人がまたすごく綺麗でスタイリッシュなコードを書くわけで、その時に、綺麗なコードというのはこういう感じに書くものなのかと結構な衝撃を受けたわけです。 またこれも最近なのですが、別の機会で、なんと言いますか、1つの関数が数千行あったり、しかもその内の大部分が共通処理として括り出せるような恐らくはコピペされたであろう部分が大量に入っていたりまぁ不可解な部分の多い、言うなればイケメンを見続けた僕みたいな、
クリアなコードの作り方 - How to make clear code - Kouhei Sutou - Rabbit Slide Show
私はコードを書くことが好きです。もっと言うとクリアなコードを書くことが 好きです。クリアなコードを書くことはとても楽しいので、みんながクリアな コードを書けるようになればいいなぁと思っています。そこで、私がどうやっ てクリアなコードを書いているかを紹介します。 I like coding. I say more. I like coding clear code. I hope that we can code clear code because coding clear code is very fun. I'll talk about how I code clear code.
DM's Esoteric Programming Languages - HQ9++
Introduction HQ9++ is an object-oriented extension of the well-known esoteric language HQ9+, created by Cliff L. Biffle. Design Principles Extend the elegance, simplicity, and power of HQ9+ to the object-oriented paradigm. Be backwards compatible with HQ9+. That is, any valid HQ9+ program will also run in HQ9++ and will produce identical output. Language Concepts HQ9+ was created to make some very
11 Tools to Instantly Code Faster | Envato Tuts+
Twice a month, we revisit or update some of our readers’ favorite posts and sessions from throughout the history of Nettuts+. This tutorial was first published last September. Doesn't the title say it all? There are a wide variety of tools and techniques which can drastically improve the speed at which we code. Particularly during time-sensitive settings, even a savings of a few seconds per iterat
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本人が間違いやすいコーディング上の英語 - Qiita
Google C++スタイルガイド 日本語訳
zen-coding - Set of plugins for HTML and CSS hi-speed coding - Google Project Hosting