はてなキーワード: 命名規則とは
「駅うら」と同じような命名規則ではないだろうか
多人数でシステム開発をする場合「統一性があったほうが読みやすい」なんて理由で、言語別・組織別・プロジェクト別にコーディング規約があるものだけど、そんなに乱立しているなら個人別の規約があっても何も問題はないはず。
これは詭弁だろうか? でも個人的な開発や、開発中に読むサンプルコードも含めて、自分がいくつのコーディング規約に関わっているか考えてみると、個人から見た統一性は失われているわけだ。
「整理」と「整頓」という言葉がある。前者は秩序立てること、後者は見た目を揃えること。本を分野別・用途別に並べれば整理、大きさ別に並べれば整頓となる。
コーディング規約は専ら整頓のルール。読めない人にとって「きれい」に見せるルール。
コードの意味に関わらないからこそ、実装後に修正ができる。さもなければ、正しいコードは自然とコーディング規約に適うものになるはず。コードの正しさと無関係だから、正しいコードでもコーディング規約違反だったり、コードを理解していない人でも指摘できたりする。
コーディング規約を作って発表する人もいる。でもそれがどれだけ生産性を上げるかについては考えていない。作りっぱなし。そんなルールに「あとで読む」タグを付ける人たちは、プログラミング言語に表現の幅があることを欠点と捉えているのだろうか。本来そういったルールを作っていいのは言語の考案者だけのはずなのに。
あるにはあるけど、言語に組み込まれているライブラリと同じ規則がベストなので、やっぱり規約は要らない。
あとは自己満足。
そもそも、静的型付け言語みたいに、インターフェイスを型で揃える必要ないけど(ダックタイピング)。
命名規則で充分だろ。Pythonでは'_'を先頭につけるのが標準。
Javaのビルドのほうが遥かにめんどくさいじゃん。Eclipse無しに複数ファイルコンパイルとか、プロでもできないやつ多いんじゃね?
我が家に初めてパソコンが来たのは2006年頃。FMVのよくわからないモデル。
当時は住んでいるところにまだADSLしか引かれてなかったのでADSL回線。
俺がインターネットをし始めた年前後にインターネット上ではYouTubeが生まれたりと動画共有サービスが流行っていた。いまでこそ著作権コンテンツはすぐに削除されてしまうが、当時はアニメがそのままあげられていたし、VeohとかStage6とか他のストリーミングサイトでもアニメが見放題だった。俺はその頃放送されていた「涼宮ハルヒの憂鬱」を見てからアニメにハマってしまったクチだ。
しかし当時は回線もあまり速くない。動画を見ていたらしばしばロード待ちになっていたし。そもそもまだ地上波はほとんどがSD画質だったわけで、今のように高画質なHD動画なんてなかった。というか俺の家にはHDの画面がなかった(1280x1024とか1024x786)。
ネットである時期からやたらニコニコ動画のサイトに誘導されることが多くなった。俺はβ時代は知らないがγにハゲたおっさんの選挙演説動画を教えられてアカウントを取得した。当時はまだニコニコ動画のサーバが貧弱だったため、会員登録してもその先で「ID開放待ち」というのが待っていた。ようやくIDが開放されてサイトを見てみると「らきすた」というアニメ動画が上がっていたので見てみるとおもしろい。毎週平日の朝7時ぐらいにあげられるため、学校にいく前にらきすたを見るのが習慣となった。
当時はまだニコニコ動画ではH.264エンコードを採用してなかったため、VP6を使っていたらしいが上下反転させたりエンコードにめちゃくちゃ時間がかかったりと、当時上げていた人も大変だったんだろうなとおもう。
ニコニコ動画と平行してぐらいかP2Pにも手を染めた。Winnyのウイルス問題が起きた後ぐらいであったか、その頃ニコニコ動画でも流石にアニメアップロードの浄化作戦が始まっていて、地方民である俺はアニメを見る方法がなくなっていた。その代替策として当時ネットの友人に教えてもらったのがPerfect DarkというP2Pソフトだった。俺にとっては夢の様なソフトで、アニメがいくらでも転がっていてしかもHDの高画質(しかしその動画はDVDやTV放送をアプコンしただけ)。糞遅いADSL回線でがんばっていろんなアニメをダウンロードしていた。
他にも同人誌やエロゲーというジャンルを知ったのもこの時。「(C72)[作者名]作品名(元ネタ).rar」みたいな非常に効率化されたファイル命名規則、.rarとかいうみたこともなかった拡張子、.isoはDaemon Toolsでロードしたら読めるなんていうのを知る機会は多分こんなことしてないと得られないんじゃないか。
そんなことしてたらなんだかんだで成人してしまい、今ではこういうことをするリスクが私生活に影響を及ぼしそうでそういうことは一切していないわけだが、当時やっていたことが少なからず今の生活で生きている気がする。
HTMLとCSS, JavaScriptはちょっとだけ分かる
dotinstallとか見てブラウザでタイマー作ってわーいって喜んでるくらいのスキル感。
→本を買ってやるのは安上がりだけど途中で挫折しそう
→じゃあお金稼ぎながら学んだらいいんじゃ
バイト始めることになった
バイト始まる
課題を出されて、できたら業務に入れる
誰も教えてくれない
ググってググってググりまくる
ひーひー言いながら2~3週間でなんとか終えた
なんとかなった
このときくらいにパーフェクトPHPを読んだ。FWは、つくれる!
あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね
分かった気になる←分かってない
GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない
FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービスの受託をやる
まあ良い経験になった
フレームワークいくつかやって、web開発のいろんな概念やtipsがたくさん頭に入ってきて、
あーあれかーくらいには思えるようになった
DBのCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインでコード生成,認証周りのプラクティス ...
さて、バイトが本格的?になってくる
一人で開発 責任おもい
でもなんか躓いた。
書いたコードに自信が持てない
これでいいのか不安になって手が進まない
セキュリティで手直しはたくさんもらった
フレームワークにはDB操作のライブラリがちゃんとついてるのにそれ見ずに自分でSQL組み立てて案の定エスケープしてないし、とか
でも、なんとか完成させた
プッシュして、マージされて、できちんと本番環境で動いてる。やったね。
Rubyを知った
PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。
Railsも知った
それからは空いている時間の大半をRubyとRailsにつぎ込んだ
まずはRailsTutorialをやってみた
テスト周りでつまづいたけどなんとか終わらせた
dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ
はじめはRubyを理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた
はじめてのRuby・はじめてのプログラミング・たのしいRuby・プログラミング言語Ruby... 入門系の本を乱読した
PHPでさんざん苦労していたからか、Rubyでオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた
その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra(支那虎じゃなかった)やらについて学んだり、
メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatzの言葉痺れたなー
バイトのほうも何とかこなせるようになってきた 成長すげー
Vagrantをかじる
AWSでいろいろ遊ぶ
webスクレイピングとか検索APIとか使ってムフフな画像をアハーンしたりして遊んでた
Rubyで言語をつくろうだの、スクリプティングを極めようだの、JavaとRubyがどうだの。
メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。
借りられる本は借りて済ませた。全部買ってると破産する
他にもRubyとつかない本もいろいろ。
プログラマが知りたい97の何とか。いい本
Rubyの関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる
OOPと全く違う。
就活はじめるよー
まあ、エンジニア枠で探すことにする
エントリーめんどくさい
ので、1社受けて落ちたら次の会社エントリーするという作戦にした
無計画玉砕作戦
とはいえ、なんとかなると思ってやってく
気を揉む期間
やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない
せめてよく使ってる言語くらいはのっけておいて欲しい。
で、1社選んで応募して、選考が始まった
面接、失敗したなと思ったところもあったが
嘘つかない
知らないことを知ってるように話さない
は通せたので良かったと思う。
で、進んでいって最終面接。これもなんかよく分からないうちに終わってた
相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる
うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。
前から気になってた会社ではあった。勝手にリスペクトしてた会社。
自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる
いろいろと運が良かった。嬉しい
他の会社はどうしようかな。
受けてみたい気もするけれど、エントリーがめんどくさい
続けるかどうかは未定だけど、ひとまず休憩することにする
WordPressのテーマ「STINGER」がアツいらしい!
Advent Calendarも作成されてるし、これは使えそうだぞ~!!11
http://www.adventar.org/calendars/90
えぇ。色々とマンセーされてるみたいだからダウンロードしてみました
これはヒドい・・・・
(コーディングルール?何それ?タブとスペース?何か違うの?)
たださ、これの製作者ってPHP・・いやJavaScriptすら分かってないんじゃねーの?
ひっどいわ。コメントすらまともに書けてねーんだ
死ぬ気か?
挙げだしたらキリがないので
> STINGERは、WordPressの初心者の方でも簡単にSEOに強く、アフィリエイトも出来るテンプレートです。
初心者の人に教えてあげたいけど、これよりもっといいのあるよ、ただそれはSTINGERではない
SEOに効果があったとか書いてるブログは何をもって効果があったとしてるか知らんが
SEOなんてようは中身だろ。もちろんソースも関わってくるけどSTINGER見た限りでは
・ディレクトリ構成ぐらいきちんとしろよ(逆に何で /images だけあんの?)
・開発環境に入ってるデフォルトのフォーマッターでいいからフォーマットしてくれ
・ファイルの命名規則ぐらいちゃんとしたら?("itiran"って何だよ。イーティランって英語あんのかと思ったわ)
・もうコピペはやめろ
コピペで良い物を作りあげるのもエンジニアとしては必要とされる事かもしれんが
こんな危ないコピペテーマを、「初心者でも安心」と言わんばかりのキャッチコピーをうたって配布してんだからタチが悪いわ。
製作者さんよ。
これさ、不具合が出て直せんの?
そんな危ないコードを配布してるのに危機感もったらどうなんだ?
ウイルスばら撒いてるようなもんだぞ?
追記:
http://anond.hatelabo.jp/20131222235456
やっぱり変なのも沸いてるみたい
簡単に拡散して貰えるからって乗っかってくる奴らも多いんだろうな。
リンク先のブログが月間30万アクセスとか眉つばも良い所だわ。
100歩譲っても運営者のアクセスが30万とかそんな感じ。
Web制作業をしてるんだが、最近「別の業者に依頼したけど、効果が出ないので御社でお願いします」みたいな依頼が増えてきた気がする。まぁ、料金だけ見て判断したから痛い目あったんだな~とは思うんだけど、クライアントはなぜかその業者を庇う。「効果は出ませんでしたが、担当者は凄く良い人でした」みたいな事を言う。だったら、その良い人に任せて効果が出るように努力してもらえば良い話だと思うのだが。
このクライアント以外にも「最近、仕事が忙しいようで連絡が滞りがちになっちゃったんです。大変みたいなので、御社に依頼しました」とか「SNSとかスマホとか最近のWebに関する事は知らないって言われました。仕方ないですよねー」みたいに言う。
俺が客なら「こっちが先に契約してるのに、忙しいから出来ないってどういうこと!?」「SNSやスマホぐらい、触りだけでも知っとけよ…」って思うんだけど、そんな文句はひとつも言わずに、とにかくその業者を庇う。
でも、その業者が作ったサイトを見たら、コーディングも適当だし、命名規則にも沿っていない。明らかに”ホームページ制作ソフトで見た目だけ重視してホームページ作りました”って感じだ。明らかに手抜きか、知識がない素人作品で、非常に引き継ぐのが面倒なものになってる。
だから、「サイトの中身見たけど、めちゃくちゃでしたよ」って言うんだけど、やっぱり「一生懸命やってくれたので…」と庇う。俺の性格が悪いだけだろうか。
前半分と、後ろ半分は言いたいことが違うから。
に突っ込まれた。という事でいい?
位置エネルギー というか ポテンシャル 単体は 定義しようと思えば テンソルでもベクターでもスカラーでも そのいずれでも定義可能であるが(ベクトルポテンシャルが存在している)
エネルギー交換の法則をベースに考えると、ポテンシャルエネルギーはスカラー量であるほうが便利であるから、ポテンシャルエネルギーを位置エネルギーとしたんだなぁ。という話。(和訳したと言うよりもスカラーポテンシャルが持つエネルギーをポテンシャルエネルギーと命名した)
ポテンシャルのエネルギーは スカラーポテンシャルとベクターポテンシャルがある(らしい)し ベクターやテンソルと考えることにも非合理性はないのに
なぜ、ポテンシャルのエネルギーであるところのポテンシャルエネルギー=位置エネルギーを わざわざスカラー量に限定したのか? という話で 繰り返しになるけど エネルギー交換の法則をベース にしているんだなぁと。
思った ということ。
つまり僕は ポテンシャルのエネルギーと ポテンシャルエネルギーの違いがわからなかったけど、うっすらわかって、まだまだ趣味の範囲で勉強するよという話。(用語が不正確ですまんね)
逆に言えば、仮に 運動エネルギーをベクターで表す社会があったとしたら、位置エネルギーもベクター量だった可能性が高いんだなぁ。という 話。
命名規則の話かね。
2010/05/16 23:40
こんにちは。昨日会った者です(これで特定するには情報不足だけど、まあわかるよね)。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います(斜め読みしかしてませんが)。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法(マクロを大文字化しない、ルーチン名を大文字で始めるなど)だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル(ハードウェアに近い)処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 (スタート地点が内点でないとすれば 3)であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから(容量の節約にすらなりません)。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます!cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました!
そうではなくて、独自規格から始まったものが後日改変されて、正しく定義され規格化された場合、その日以後の新プロジェクトはその規格に従ってくれという事。(例外もあるだろうが)
当初true/falseという物はなかったが のちのちC++などのために定義された その定義の中には if(false){がelse節になるという自明の理が含まれている。
であるならば、falseという名前を含んだものがifでthen節になるルールを、後発規格ができたあとに作るな。という事。
そういうものが必要であるならば、ON/OFFであるとかActive/Inactiveであるとか、命名規則が矛盾しないルールを作って、規格化されたルールとまぎらわしい、ルールを作るのは、誤用の観点から、なぜ、そんな事をするのか?害悪じゃないのか?という事。
なぜならば、後発規格で定義された標準仕様に反するから、新規参入メンバーが混乱し、同一視した結果、意図しない潜在バグが発生するおそれもあり、教育コストの面からのデメリットしか無く、経済的メリットが挙げられない。コンパチビリティーで先発規格に合わせるのは除外して。(MS定義のFALSEなど、旧システムのfalseは仕方がない)
同様に int,short,long の定義は short<long でありint は適宜最適な長さ という意味なので my_longなどを独自定義せずに 4バイトが欲しいならDWORD(先発規格)かint32_tを定義するか使え</p>
いつまで、my_longを定義しているんだ!いい加減 規格に対応しろ という事。
10頃ライブラリを呼び出します。lib1_true lib2_true lib3_true lib4_true ・・・・ lib1がtrueだったときにlib2にtrueを渡して・・・その結果をlib3に・・・載せ替えて・・・ってどんだけ、コンパチの確認を目視でしなきゃならんのだと・・・。
各個人、各会社で独自仕様でしかも、C/C++の規格と紛らわしいとか、やめてくれ。可能なかぎりC/C++の規格で使えるものは使ってくれよ。と
最初はあんまり気にせず、とにかくたくさん書いて読めば良いと思う。
結果が同じなら、無理に難しく書く必要なんてまったく無いし。
何か良く知らないけど、無理に難しく書くことに凝る人とかいるけど、あまり意味ないし。
有名なコードをたくさん読んでいると、そこに流れる共通マインドみたいなものが感じられるから、
その中でコレが良いって思ったものを取り入れれば良いよ。
作法とかなんとか、言う人がいるけど、大抵は・・・宗教だし。
でもなんだろう、なんでもいいから、命名規則はしっかりポリシーを持って欲しいと思う。それがアレば、あとはなんでもいいや。
その代わり丁寧に作って欲しい。考慮漏れとか、ちゃんと調べてないとか、エラーハンドリングが中途半端とか、そういう方がよっぽど問題。
1行1行意味を考えて、丁寧にサボらず作っていれば実力は上がっていくよ。
給料は上がらないかも知れないけどw。
これは言ったらいけないのかも知れないけど、今の日本のプログラム業界の大半は、プログラム技術を身につけるより、転職するかポジション争いをするか、中間搾取できる会社に行くかそんな方が給料の上がりは速いきがする。でも、それなら、最初から証券会社にでも務めた方がマシという物。
元増田です。
以下、所感です。
ある分かりやすい規則に基づいて変数名を決めるというルールが徹底されていないこと=整合性が取られていないことが問題なのでは?
たすかに。
だがしかし、命名規則をかっちり決めることができないからこそ、
「原則略さない」とりいう分かりやすい規則を規定すればチーム内、及び引き継ぎ後のコードの可視性は大幅にアップするのではないだろうか。
変数名60文字とかになってもよいと?
ぎりぎり25文字くらい?
単語を全部並べるというか、重要単語をピックアップして並べる方がいいね。
訂正します。
タイプ数を減らしたいでござる
ソースが汚いと知ってる言語でも読めない。キレイだと知らない言語でも少し読める。
個人の経験から行くと、
コーディング規約が決められ守られている/きっちり設計されているプロジェクトのコードは読み易い。
そうでないソースは読みにくい。
この辺りがきっちりしてると読み易い。
実際、長年使ってこられた古いソースなのどは読み込めば読み込むほど、過去どういうバグがあって、どういう経緯でそういう書き方になったのかが見えてくる。
そうかな?古いプロジェクトのコードは担当コロコロかわっているのか、
書き方が統一的でなくて読みにくいこと多いけどな。
あとから問題が発覚して、お客さまの業務の影響あたえるので場当たり的な修正を実施。