このメールは自動的に消滅する―期限来ると消える「Dmail」がGmailで利用可能に

どうやって実現しているんだ？
相手先が受信したものをいじれるのって、もはやウィルスな気がするのだが？
また、メールはないけど、Pdfなら期限付きはすでにあるはず。
ともかく、技術的に興味がある。

http://news.livedoor.com/article/detail/10398654/

タイマーをセットし、期限が来ると自動的に消滅出来るサービスがGmailに登場しました。

自己破壊機能つきメール

セキュリティ会社Deliciousは、グーグルのブラウザChromeで、Gmailの拡張プラグイン「Dmail」のサービスを提供することを明らかにしました。
 
この「Dmail」を通してメールを送信しようとすると、相手にメールが届いてから1時間後-1週間の期間で、期限になると自動的に消えるようにするオプションを選択することが出来ます。
 
期限が来ると、相手はゴミ箱を閲覧しても、メール自体を見ることが出来なくなります。またこの仕組みを応用して、今後はPDFも時間内に消滅するようにすることが出来るようにもなるのだそうです。

Snapchatを意識？

またこのサービスは、以前提供された、送信後30秒以内であれば、送信自体をなかったことに出来るGmailの機能とは全く別のものとなります。
 
「消えるメッセージ」と言えば、SNSアプリSnapchatが有名であるだけに、好調な同社のシステムから影響を受けたのでは、という声もありますが、将来的にグーグルがSNSサービスに進出することになれば面白そうですね。
 
 
Source：CNN Money
(kihachi)

海外「技術革新が起きるな！」日本の靴屋にスゴい店員がいると海外サイトでも紹介されてた

現実になるかはともかく、面白い。

http://blog.livedoor.jp/otataho/archives/43698016.html

　複数のローターブレードをもつ機体『マルチコプター』。最近ではその制御技術がぐんぐん進歩しており、それに伴って救助活動から商業利用、エンタメまで様々な応用法が提案されています。例を挙げるときりがないのですが少しだけ紹介すると、クアドロコプターを使った撮影や演奏、ジャグリング、ウェイター、ピザ・新聞配達、Amazonの配達員などなどが行われてきました。 

　そんな中、日本でマルチコプターを使って行われたユニークなイベント「空飛ぶ靴屋」が海外でも紹介されていました。 

Credit : huffingtonpost

　マルチコプターは単なるラジコンとしてだけでなく次世代の労働力としても期待されている側面があるもので前述したように各企業により様々な利用法が実験されていますが、六本木の東京ミッドタウンで開催される「空飛ぶ靴屋」なるイベントではそんなマルチコプターたちが靴屋の店員として姿を現したようです。 

　このイベントを展開するのはクロックス靴でお馴染みのクロックス・ジャパン。なんでもクロックスのスニーカー新ラインアップとして発売される"ノーリン"の特徴である「軽さ」をアピールするために企画されたそうで、店員となるマルチコプターには半年かけて製作したという特製モデルの機体を採用。センサーで位置を感知しながら靴の元まで飛び、電磁石が付いたアームで靴をキャッチする・・・という一連の工程を全て自動で行うようになっているのです。 

　公開された動画でもその一連の流れが映されており、お客さんが設置されたタブレットで欲しい靴の色を選択すると、マルチコプターはその商品の元へ飛び立ち、ボディの下部に装備されたアームを使って靴の天板を電磁石でキャッチ、そしてお客さんへ。あくまでもプロモーションの一環ではあるのですが、店員がロボットという光景は未来を垣間見てるのかもしれませんね。ちなみに六本木の東京ミッドタウンで8日まで開催するとのことですよ。

YouTube

　この光景に海外のネットユーザーの方々からもコメントが多く寄せられています。これに対しての海外の反応を見ると、

防衛省のドローンが行方不明に

防衛省のドローンが行方不明との報道。なんか新作のスゲー新作ができたのかとおもったら。phantomじゃん。普通のことだと思うが、防衛省ってつくだけでニュースなんだろうな。
むしろphantomを作っているDJIって中国の企業だから、採用はないと思うのだが・・・しかも、民間の業者が操縦していたっていうから、敷地内でやっただけで、まだデモの段階でないのかな？それってただの業者のミスで防衛省と関係ないとおもうのだが、実際どうなんだろう。

http://www3.nhk.or.jp/news/html/20150722/k10010162481000.html

２２日、東京の防衛省で小型の無人機、ドローンが飛行中、行方が分からなくなったということで、防衛省は、詳しい状況を確認しています。

防衛省によりますと、２２日午後１時すぎ、東京・新宿区の防衛省の敷地内にあるグラウンドの上空を飛行していたドローンが、風で北に流され、コントロールを失って、行方が分からなくなったということです。
ドローンは１機で、防衛省の職員の立ち会いの下、民間の業者が操縦していたということで、重さは１キロ余りで、大きさは縦横それぞれおよそ３０センチの大きさだということです。
防衛省は職員およそ２０人を風に流された敷地の北側を中心に派遣し、行方を探していますが、見つかっていません。
このドローンは一般に販売されているタイプで、２３日、関係省庁にドローンを捕捉する機材を公開するため、その対象となるドローンを予行として飛ばしていたところ、風で流されたということです。
気象庁の観測によりますと、東京都内では２３日の日中は沿岸部を中心に南寄りのやや強い風が吹いていて、東京の都心では、午後１時前に１８．５メートルの最大瞬間風速を観測していました。気象庁は東京２３区に強風注意報を発表して、昼前から夜遅くにかけて強風に注意するよう呼びかけていました。
防衛省の担当者は、「対策を講じるべき側が、このような事案を起こしてしまい、誠に申し訳ない」と話しています。

►►

テレビ朝

Googleの人工知能「DeepDream」でラーメン次郎

絶対食いたくねー

ラーメン二郎をDeepDreamで変換すると以下のような感じになります。

https://twitter.com/kz403/status/618763823269310464/photo/1

http://gigazine.net/news/20150714-deep-cheese-dreams/

Googleの開発した人工知能「DeepDream」はプログラムが公開されており、映像などが誰でも自由に作れるようになっています。作り出す画像や映像が悪夢すぎるとして話題になっているDeepDreamですが、ピザを持ち上げてチーズがとろ～りとなる瞬間をDeepDreamで表現したすさまじいムービーが公開されました。

Deep Cheese Dreams on Vimeo


キツネのようなウサギのような動物の顔が写った一枚の画像。


かと思いきや、びろーんと白い物体が伸びていきます。


みんな大好きなピザのチーズがとろりと伸びている瞬間だったわけです。犬がじっとこちらを見つめ、伸びるチーズは獣の足に見えますが……。


アメリカのピザチェーン「パパ・ジョンズ・ピザ」のCMも獣まみれ。


ソースの中には虫のようなもの。


トロピカル


アメリカン・スペシャル


ペチャンコのピザが……


ふっくら焼き上がる瞬間。


ピザの上に見知らぬ誰かもいました。

もはや自動運転カーの方が安全ではないかと思わされる事故が発生

http://gigazine.net/news/20150721-self-driving-car-more-safety/



Googleが開発中の自動運転カーは、公道でテスト走行を積み重ねてすでに数万マイル(数万キロメートル)を走破しています。その中で、複数回の事故を起こしたことが明らかになっていますが、基本的には「人間の」ドライバーの不注意によるもらい事故であることが分かっています。2015年7月1日に起こった直近の事故のムービーからは、人間の運転にひそむあやうさと、それを解決するヒントが隠されていそうです。

The View from the Front Seat of the Google Self-Driving Car, Chapter 2 — Medium
https://medium.com/@chris_urmson/the-view-from-the-front-seat-of-the-google-self-driving-car-chapter-2-8d5e2990101b

以下のわずか8秒のムービーを見れば、Googleの自動運転カーが被った事故の様子がよく分かります。

The View from the Front Seat of the Google Self-Driving Car, Chapter 2 - YouTube


これは自動運転カーが認識する交通状況。赤枠で囲まれたのが自動運転カーで、刻々と変化する周囲の状況はポリゴンで認識しています。


自動運転カーは前方の自動車が交差点で停車したのを確認して、ゆっくりと停車。一方、自動運転カーの後ろの自動車は、停車するそぶりを見せずに車間距離を一気に詰めて……


追突。


自動運転カーを押し出して、自らも反動でふらふら。


さらにゴリゴリと車体を押しつけるように、自動運転カーを押し出しています。


この事故は2015年7月1日にカリフォルニア州の交差点で起こったもので、前方の信号自体は青でしたが、Googleの自動運転カーを含む3台は、安全を確保するために交差点への進入を中断して待機していたとのこと。しかし、後方の1台は、時速17マイル(約27キロメートル)の速度でブレーキを一切かけることなく前進して、自動運転カーに追突してしまいました。なお、この事故で自動運転カー・追突した車両の搭乗者は軽いケガですんだそうです。

これまでもGoogleの自動運転カーは公道走行で事故に遭ってきましたが、自動運転カーが原因となる事故は1件もないとのこと。基本的には人間の注意不足が原因で発生した事故に巻き込まれたものだそうで、自動運転カーの安全性は、単独走行の安全性という問題はクリアー済みで、すでに運転の「下手な」ドライバーへいかに対応するかというレベルに突入しています。

なお、Googleは衝突事故で得られたデータを解析することで、交通事故がどのような状況でどのような原因が元で発生するのかについての研究を進めており、このデータは交通事故の研究を大きく進めるものと期待されています。

初認可の「ドローン宅配便」が実際に空を飛んで荷物を届けるまでの一部始終が公開中

http://gigazine.net/news/20150721-first-faa-approved-drone-delivery/

アメリカ・バージニア州で空港に届けられた医療用品をドローンを使って移動診療所まで配達するデモが現地時間2015年7月17日に実施されました。この宅配ドローンはリアルタイム宅配サービスを提供するスタートアップ企業Flirteyが行ったもので、アメリカ連邦航空局による初の飛行許可を得たドローン宅配便となっています。

First FAA-Approved Drone Delivery Drops Medicine in Virginia - NBC News
http://www.nbcnews.com/tech/tech-news/first-faa-approved-drone-delivery-drops-medicine-virginia-n393986

宅配ドローンが森や野原の上空を抜けて目的地に荷物を届けている様子は、以下のムービーで見ることができます。

Flirtey making history with the first US drone delivery - YouTube


宅配ドローンに取り付けられたカメラが地面を映し出しているところからムービーがスタート。


ふわっと地面から飛び立ち……


垂直に飛び上がって、斜め右へクルッと向きを変えます。


森の上空を進んでいくドローン。


森を抜けて、羊たちのいる牧場を通り過ぎていきます。


原っぱに到着。ドローンは風に流されることもなく、安定した飛行姿勢を保っています。


今度は左へと進路を変更。


駐車場の方向へ向かっていきます。


駐車場の右側に、配達場所の目印である水色のシートを発見し、上空でホバリング。


そのまま機体の高度を下げていきます。


このまま着陸するのかと思いきや、カメラを荷物の方へクルッと向けて……


ぽーん、と荷物を離しました。


荷物はふわふわとゆっくり地面に降りていきます。


目印よりもやや下側に着地しそうですが……


無事に、荷物の配達に成功。離陸から配達までの所要時間はたった3分で、車だと空港から移動診療所まで1時間半かかるところ、ドローンを使えばわずかの時間で荷物を届けることが可能でした。


荷物を下ろした後は、ドローンと荷物をつないでいたワイヤーをドローン側へ巻き上げて回収。


機体を180度旋回させて、出発点に戻っていきます。宅配ドローンによる荷物の配達を見るためにバージニア州知事を含む何百人もの人々が集まったそうで、地上からドローンの様子を見守っているのが分かります。


だんだんと地上の人や車が小さくなり……


先ほど通った道を帰っていくドローン。


森を抜けて……


飛び立った地点に帰還。


ゆっくりと着陸して配達完了。往復約6分のフライトでした。


なお、今回使われたドローンは以下のような6つの羽根を持つ機体で、医療用品の入った小包を1箱ずつ配達したとのこと。


宅配ドローンが荷物を抱えながら目的地へ向かって飛んでいる様子はこんな感じです。


上空でドローンが荷物を離して小包が地上へ降りてくる様子を地上から見上げると、2つの黒い物体が空に浮かんでいるのが分かります。


今回デモが行われたバージニア州ワイズ郡は炭鉱で栄えた街なのですが、石炭の需要が減り続けていることで街の活気は失われつつあるそうです。ワイズ郡の裁判所で書記官として働くケネディさんはNBC Newsのインタビューに応じて「宅配ドローンは、炭鉱に依存しているワイズ郡の経済危機を救う手段です。ワイズ郡の貧困率は25％を越えていて、解雇通知が毎週のように貼り出されています。ワイズ郡にアメリカ国内のドローン宅配便を開発したり製造したりする拠点を作れば、住人が貧困の苦しみから解き放たれます」と語っています。

また、ワイズ郡の経済担当官であるデビッド・コックスさんも、地域が生き残るために新たな道を切り開く必要があると考えていて、「ドローン宅配便の初飛行には州知事や大学生をはじめとした何百人もの人々が集まり、初認可の宅配ドローンを見て会場が興奮であふれかえっていました。今こそワイズ郡が変化すべき時で、そのためにドローンが役に立つと思います」とコメント。

Flirteyは「アメリカ国内で初めてFlirteyが宅配ドローンを開始、Amazonがテスト中のドローン配達便Amazon Prime Airに勝利」とツイートしています。なお、Flirteyはニュージーランド国内で既にドローン宅配便を提供していて、アメリカ国内でも今後ドローンによる配達ビジネスを進めていくとのことです。

STL ( standard template library) の勉強サイト

STLは結構つかうのに、体系的に学んだことがありませんでした。ってことでいい本を探していたら・・・絶版になった本がサイトになって復活していました。ちょっとわかんなかった時に読むのによさそう。

Standard Template Library プログラミング on the Web


もう一つ。
さくさく理解する C言語/C++ プログラミング 入門

より実践的な使い方を学ぼうとするとこちらのほうがいいです。

C/C++ のプログラムの書き方入門 コーディングルールはどこから学ぶ？(2016/3/15 追記)

読みやすいコードを書くことは重要。個人で書いていてもデバックのやり易さが違うし、チームだといわずもがな。下手なコードを書いていると、解りやすくかけ！！と言いたくなる。過去にそれですべて書き直しをしたことがなんどかありますね。っと、いっても私も長いこと書いてなくて忘れて下手なコード屋になっていますが。
ちょっと復習がてらに、私の知っているコーディングルールは、本のやつと自動車業界とNASA。各々紹介していきます。ってか引用のみです。
追記：
流石はＧｏｏｇｌｅさん。自分のコーディングルールを公開しているようでした。結構細かくて面白いので追記します。

目次
１．本
２．MISRA-C(自動車業界の標準です)
３．NASA
４．Google

本文
１．本から
１．１

CODE COMPLETE 第2版 上

CODE COMPLETE 第2版 下

プログラマと名乗っている人で知らないと、潜りだと思います。まぁ、俺は現在潜りなので持ってないけど。きれいに書くなら必読書。原書が英語なので、どこかで手に入るでしょう。

１．２．

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

最近知った本。ちょっと読んでみたらかなり良かったです。

英語版であるが、原初のサンプルがここでみることができる(The Art of Readable Code)

２．自動車業界：
MISRA-C

MISRA-C:2004（ちょっと古い）　R:必要,A:推奨

環境
1.1 R	すべてのコードは、ISO/IEC 9899:1990,Program language-Cを満たしていなければならない。
1.2 R	未定義または未規定の動作に依存してはならない。
1.3 R	言語/コンパイラ/アセンブラが準拠するオブジェクトコードの共通インターフェース規格が定義されている場合に限り、複数のコンパイラや言語を用いることができる。
1.4 R	コンパイラやリンカが、外部識別子に対する31文字特徴及び大文字・小文字の区別をサポートしているかを確認しなければいけない。
1.5 A	浮動小数点の実装は、定義された浮動小数点規格に従うべきである。
言語拡張
2.1 R	アセンブル言語が、カプセル化して分離しなければならない。
2.2 R	ソースコードでは、/* ・・・　*/ スタイルのコメントだけを用いなければならない。
2.3 R	文字列　/* をコメント内で用いてはならない。
2.4 A	コードの一部を”コメントアウト”すべきではない。
文書化
3.1 R	用いる処理系定義の動作は、すべて文書化しなければならない。
3.2 R	文字集合及びそれに対応するエンコーディングは、文書化しなければならない。
3.3 A	選定したコンパイラの整数除算の実装について確認し、文書化し、十分に配慮すべきである。
3.4 R	用いる　#pragma 指令は、すべて文書化し、説明しなければならない。
3.5 R	ビットフィールドの処理系定義の動作とパッキングに（プログラムが）依存している場合、それは文書化しなければならない。
3.6 R	製品コードで用いられるすべてのライブラリは、この文書の規定にしたがって記述されていなければならず、適切な妥当性確認を受けていなければならない.
文字集合
4.1 R	ISO/IEC 9899:1990で定義されている拡張表記だけを用いなければならない。
4.2 R	3文字表記は、用いてはならない。
識別子
5.1 R	（内部及び外部）識別子は、31文字を超える特徴に依存してはならない。
5.2 R	外部スコープの識別子が隠蔽されることになるため、内部スコープの識別子には外部スコープの識別子と同じ名前を用いてはならない。
5.3 R	typedef 名は、固有の識別子でなければならない。
5.4 R	タグ名は、固有の識別子でなければならない。
5.5 A	静的記憶域期間をもつオブジェクトや関数の識別子は、再使用すべきではない。
5.6 A	構造体及び共用体のメンバ名を除いて、あるネームスペースの識別子を、他のネームスペースの識別子と同じ綴りにしてはいけない。
5.7 A	識別子は、再使用すべきではない。
型
6.1 R	単なるchar型は、文字データの格納及び使用に限って用いなければならない。
6.2 R	signed char型及びunsigned char型は、通知データの格納及び使用に限って用いなければならない。
6.3 A	基本型の代わりに、サイズ及び符号属性(signedness)を示す typedef を用いなければならない。
6.4 R	ビットフィールドは、unsigned int型またはsigned int型だけで定義しなければならない。
6.5 R	signed int型のビットフィールドの幅は、2ビット長以上でなければならない。
定数
7.1 R	（０以外の）８進定数及び８進拡張表記は、用いてはならない。
宣言及び定義
8.1 R	関数は、常にプロトタイプ宣言をもち、プロトタイプ宣言は、関数定義及び関数呼び出しの両方から参照されなくてはならない
8.2 R	オブジェクト又は関数を宣言又は定義するときは、常にその型を明記しなければならない。
8.3 R	それぞれの関数宣言及び定義で与えられる仮引数の型は、一致しなければならず。、戻り値の型も一致しなければならない。
8.4 R	オブジェクト又は関数を複数回宣言する場合、それらの型に互換性がなければならない。
8.5 R	ヘッダファイル内で、オブジェクト又は関数を定義してはならない。
8.6 R	関数は、ファイルスコープで宣言しなければならない。
8.7 R	オブジェクトが単一の関数内だけでアクセスされている場合は、そのオブジェクトをブロックスコープで定義しなければならない。
8.8 R	外部オブジェクト又は外部関数は、単一のファイル内だけで宣言しなければならない。
8.9 R	外部結合をもつ識別子は、唯一の外部定義をもたなければならない。
8.10 R	外部結合が必要な場合を除き、ファイルスコープに存在するオブジェクト又は関数すべての宣言及び定義は、内部結合にしなければならない。
8.11 R	static記憶クラス指定子は、内部結合をもつオブジェクト並びに関数の定義及び宣言に対して用いなければならない。
8.12 R	外部結合をもつ配列を宣言するときは、明示的にサイズを記述するか、初期化によって暗黙的にサイズを定義しなければならない。
初期化
9.1 R	すべての自動変数は、用いる前に値を代入しなければならない。
9.2 R	配列及び構造体を０以外で初期化する場合は、構造を示し、それに合わせるために波括弧 "{ }" を用いなければならない。
9.3 R	すべての要素を明示的に初期化する場合を除き、列挙子リストでは、先頭以外のメンバを明示的に初期化するために、"=" 構文を用いてはならない。
算術型変換
10.1 R	次の条件に該当する場合、整数型の値を異なる潜在型に暗黙的に変換してはならない。 a)同じ符号属性(signedness)をもつより大きな整数型への変換でない場合 b)式が複合式である場合 c)式が定数でなく、関数の実引数である場合 d)式が定数でなく、return式である場合
10.2 R	次の条件に該当する場合、浮動小数点型の式の値を異なる型に暗黙的に変換してはならない。 a)より大きな浮動小数点型への変換でない場合 b)式が複合式である場合 c)式が関数の実引数である場合　 d)式がrturn式である場合
10.3 R	整数型の複合式の値は、式の潜在型と同じ符号属性(signedness)をもつ、より小さな型へのキャストだけが許される。
10.4 R	浮動小数点型複合式は、より小さな型へのキャストだけが許される。
10.5 R	ビット単位の演算子　~ 及び　<< が、潜在型の　unsigned char　又は unsigned shortであるオペランドに適用される場合、その結果は、そのオペランドの潜在型へ直ちにキャストさせる。
10.6 R	すべての符号なし型の定数には、接尾語　"U" を付けなければならない。
ポインタの変換
11.1 R	関数ポインタは、汎整数型以外の任意の型との間で変換してはならない。
11.2 R	オブジェクトポインタは、汎整数型、オブジェクト型を指す他のポインタ、voidポインタを除く任意の型との間で変換してはならない。
11.3 A	ポインタ型と汎整数型との間でキャストすべきではない。
11.4 A	オブジェクト型を指すポインタとオブジェクト型を指す異なるポインタとの間でキャストすべきではない。
11.5 R	ポインタで指し示された型からconst修飾やvolatiles修飾を取り除くキャストを行ってはならない。
式
12.1 A	式中におけるC言語の演算子優先順位規則への依存は、極力制限すべきである。
12.2 R	式の値は、規格が認められるどのような順序で評価されようとも、同じでなければならない。
12.3 R	sizeof演算子は、副作用がある式に用いてはならない。
12.4 R	論理演算子 && 又は｜｜の右側のオペランドには、副作用があってはならない。
12.5 R	論理演算子 && 又は｜｜のオペランドには、一次式なければならない。
12.6 A	論理演算子(&&,｜｜,!) のオペランドは、実質的なブール型になるべきである。実質的なブール型である式は、(&&,｜｜,!) 以外の演算子のオペランドとして用いるべきではない。
12.7 R	ビット単位の演算子は、潜在型が符号付きのオペランドに対して適用してはならない。
12.8 R	シフト演算子の右側のオペランドの値は、０以上、かつ、左側のオペランドの潜在型のビット幅未満でなければならない。
12.9 R	単項マイナス（ー）演算子を、潜在型が符号なしの式に用いてはならない。
12.10 R	カンマ演算子は、用いてはならない。
12.11 A	符号なし整数定数式の評価では、ラップアラウンドが発生しないようにすべきである。
12.12 R	浮動小数点お潜在的なビット表現は、用いてはならない。
12.13 A	インクリメント（＋＋）演算子及びデクリメント（ーー）演算子は、式中で他の演算子と混在させるべきではない。
制御文の式
13.1 R	ブール値が生成される式の中で代入演算を用いてはならない。
13.2 A	オペランドが実質的なブール型である場合を除き、０との比較テストは明示的に行うべきである。
13.3 R	浮動小数点式は、等価又は非等価のテストをしてはならない。
13.4 R	for文の制御式は、浮動小数点型のオブジェクトを含んではならない。
13.5 R	for文の３つの式には、ループ制御に関わるものだけを記述しなければならない。
13.6 R	forループの中で繰返しカウンタとして用いる数値変数は、ループの本体内で変更してはならない。
13.7 R	結果が不変になるブール演算は、許されない。
制御フロー
14.1 R	到達しないコードがあってはならない。
14.2 R	空文でない場合には、次のいずれかの条件を満たさなければならない。 a)実行方法にかかわらず、１つ以上の副作用があること b)制御フローを変更すること
14.3 R	前処理の前の状態で、空文は、それ自身(;)を１行におかなければならない。ただし、空文のあとの最初の文字が、空白類文字であるという条件が満たされれば、空文の後にコメントを入れることができる。
14.4 R	goto文を用いてはならない。
14.5 R	continue文を用いてはならない。
14.6 R	繰返し文では、ループを終了させるためのbreak文の使用を最大でも１つだけに留めなければならない。
14.7 R	関数では、関数の最後に唯一の出口がなくてはならない。
14.8 R	switch, while, do ... while, for 文の本体を構成する文は、複合文でなければならない。
14.9 R	"if(式)"構造の後には、複合文を続けなければならない。elseキーワードの後には、複合文又は他のif文を続けなければならない。
14.10 R	すべての　if ... else if　構造は、else節で終了しなければならない。
switch文
15.1 R	switchラベルは、それを直接う内包している複合分が、switch文の本体である場合にだけ用いなければならない。
15.2 R	空でないswitch節は、無条件break文で終了しなければならない。
15.3 R	switch文の最後の節は、default節でなければならない。
15.4 R	switch式では、実質的なブール型になる値を用いてはならない。
15.5 R	すべてのswitch文には、最低でも１つのcase節を記述しなければならない。
関数
16.1 R	可変個引数をもつ関数を定義してはならない。
16.2 R	関数は、直接的か間接的かにかかわらず、その関数自身を呼び出してはならない。
16.3 R	関数プロトタイプ宣言では、すべての仮引数に対して識別子を指定しなければならない。
16.4 R	関数の宣言とその定義で用いられる識別子とは一致しなければならない。
16.5 R	仮引数をもたない関数は、仮引数をvoid型で宣言しなければならない。
16.6 R	関数に渡される実引数の数は、仮引数の数と一致しなければならない。
16.7 A	関数プロトタイプ内のポインタ仮引数は、指し示しているオブジェクトを変更する目的でポインタが用いられていない場合、constへのポインタとして宣言すべきである。
16.8 R	戻り値の方が非voidの関数の場合、すべての出口で、式をもつ明示的なreturn文を記述しなければならない。
16.9 R	関数識別子には、前に&を付けるか、括弧付きの仮引数リスト（空でも可）を指定して用いなければならない。
16.10 R	関数がエラー情報を戻す場合、エラー情報をテストしなければならない。
ポインタ及び配列
17.1 R	ポインタ算術は、配列又は配列要素を扱うポインタにだけに適用しなければならない。
17.2 R	ポインタ減算は、同じ配列の要素を扱うポインタにだけに適用しなければならない。
17.3 R	>,>=, <, <= は、同じ配列を扱う場合を除き、ポインタ型に適用してはならない。
17.4 R	ポインタ算術で許される形式は、配列添字付けだけでなければならない。
17.5 A	オブジェクトの宣言では、３段階以上のポインタ間接参照を記述すべきではない。
17.6 R	自動記憶域にあるオブジェクトのアドレスを、そのオブジェクトの存在が終了した後にまで持続期間をもつ他のオブジェクトに代入してはならない。
構造体及び共用体
18.1 R	すべての構造体及び共用体の型は、コンパイル単位の最後に完全でなくてはならない。
18.2 R	オブジェクトを、重複するオブジェクトに代入してはならない。
18.3 R	メモリ領域は、無関係な目的で再使用してはならない。
18.4 R	共用体は、用いてはならない。
前処理指令
19.1 A	ファイル内で、#include 文の前には、他の前処理指令又はコメントだけを記述すべきである。
19.2 A	#include指令のヘッダファイル名には、非標準文字を記述すべきではない。
19.3 R	#include指令の後には、<filename>又は"filename"が続かなければならない。
19.4 R	Cマクロは、波括弧で囲まれた初期化子、定数、括弧で囲まれた式、型修飾子、記憶域クラス指定子、do-while-zero構造だけに展開されなければならない。
19.5 R	マクロは、ブロック内で#define又は#undefしてはならない。
19.6 R	#undefを用いてはならない。
19.7 A	関数形式マクロよりも関数を用いるべきである。
19.8 R	実引数のすべてを指定せずに、関数形式マクロを”呼出し”してはならない。
19.9 R	関数形式マクロの引数には、前処理指令のような字句を記述してはならない。
19.10 R	＃又は＃＃のオペランドとして用いられている場合を除き、関数形式マクロの定義では、仮引数のそれぞれのインスタンスを括弧で囲まなければならない。
19.11 R	前処理指令のすべてのマクロ識別子は、用いる前に定義しなければならない。ただし、#ifdef及び#ifndef前処理指令やdefined()演算子の場合には、その限りでない。
19.12 R	１つのマクロ定義内で、＃又は＃＃前処理演算子を複数回用いてはならない。
19.13 A	前処理演算子＃及び＃＃を用いてはならない。
19.14 R	defined前処理演算子は、２つの標準形式のうち、いずれかの形式を用いなければならない。
19.15 R	同じヘッダファイルの内容が２回取り込まれないように、予防措置を取らなければならない。
19.16 R	前処理指令は、前処理で除外されたとしても、構文的に意味をもつようにしなければならない。
19.17 R	すべての#else, #elif, #endif前処理指令は、それに関連する#if指令又は#ifdef指令と同じファイルに存在しなくてはならない。
標準ライブラリ
20.1 R	予約済み識別子及び標準ライブラリのマクロや関数は、定義、再定義又は定義の解消をしてはならない。
20.2 R	標準ライブラリのマクロ、オブジェクト、関数の名前は、再使用してはならない。
20.3 R	ライブラリ関数に渡される値については、その妥当性をチェックしなければならない。
20.4 R	動的ヒープメモリ割り当ては、用いてはならない。
20.5 R	エラー指示子 errno は、用いてはならない。
20.6 R	<stddef.h>ライブラリのoffsetofマクロは、用いてはならない。
20.7 R	setjmpマクロ及びlongjmp関数は、用いてはならない。
20.8 R	<signal.h>のシグナル処理機能は、用いてはならない。
20.9 R	入出ライブラリ<stdio.h>は、製品コードで用いてはならない。
20.10 R	<stdlib.h>ライブラリのライブラリ関数 atof, atoi, atolは、用いてはならない。
20.11 R	<stdlib.h>ライブラリのライブラリ関数 abort, exit, getenv, systemは、用いてはならない。
20.12 R	<time.h>ライブラリの時間処理関数は、用いてはならない。
実行時誤り
21.1 R	実行誤りが最小であることを、次の内少なくとも１つ用いて保証しなければならない。 (a)静的解析ツール/技法 (b)動的解析ツール/技法 (c)実行時誤りをチェックするための明示的なコーディング

３．NASA（原文コピー）
１０個でいいらしいです。

概要Wiki

Avoid complex flow constructs, such as goto and recursion.

All loops must have fixed bounds. This prevents runaway code.

Avoid heap memory allocation.

Restrict functions to a single printed page.

Use a minimum of two runtime assertions per function.

Restrict the scope of data to the smallest possible.

Check the return value of all non-void functions, or cast to void to indicate the return value is useless.

Use the preprocessor sparingly.

Limit pointer use to a single dereference, and do not use function pointers.

Compile with all possible warnings active; all warnings should then be addressed before release of the software.

詳細な原文

４．Google C++ Style Guide
長いので、下のＵＲＬを参照ください。
https://google.github.io/styleguide/cppguide.html