  |
はてなキーワード: 返値とは
コードの重複があるわけでもない状況で、コードを関数ごとに分離するメリットデメリットを知りたいという話ですよね。
コードの重複がある場合に関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。
画面に収まらないサイズのコードは複数の関数に分割するのが一般的だとは思います。
理由は元増田も書かれている通り、長いと理解の限度を超えるからです。
コードは意味があるまとまりで短ければ短いほど理解がしやすいと思います。
グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さらに理解がしやすいです。
また、関数に分けておけば、関数が仕様通りに動くかの確認するユニットテストも簡単に書けます。
ユニットテストでは関数がさらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります。
分割して、複数の関数を呼び出すようにすることのデメリットは、
下手糞が切り分けるとなんでそういう切り分けになったかわからないところで切り分けられてかえって可読性が損なわれるとか、
関数の機能が拡張してより多く・あるいは少なくの情報が必要な時に関数インタフェースの変更が必要になることとか、
関数を置いているファイル内の場所を変えたときにバージョン管理システムが追っかけてくれないことがあるとか
くらいでしょうか。
いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います。
まず、関数の名前をやっている工程を表すものにすることですね。
「データの取り込み」 とか 「データの突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。
また、関数が何をしてくれるのかも関数のコメントとしてつけておくとよいと思います。
例えば、
filename引数で指定されたファイルからデータを取り込み、JSONフォーマットで返す
返値: JSONフォーマットされた取り込まれたデータ。例: [{'employee name': '山田 太郎', 'employee id': 1}]
例外: filenameを開けない場合はFileOpenError、JSONにコンバートできなかった場合はConvertError
みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。
あと、コードを連続で読みたい場合、ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います。
これはどういう意味でしょうか？同じものを表すのに関数ごとに別の変数名を付けているとか？
もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか？
ある関数のローカル変数が他の関数のローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当な名前が付けられるイメージです。
今時のプログラミング言語なら変数のスコープが関数の中にとどまるような書き方ができると思うのですが。
関数インタフェースを定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。
そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。
参考までに。
InfinityはJavaScriptが標準で持っていてどこからでもアクセスできる定数（読み取り専用変数）の名前。その名のとおり無限大を表す
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Infinity
min, maxはこの関数内で定義されている普通の変数。定義がないように見えるかもしれないが、引数のところに書いてあるので使用できる
で、valueにはたぶん文字列が入っているのでparseInt(value, 10)で10進数の数値に変換するわけだが（parseIntの第二引数は基数）、
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/parseInt
このときvalueが未定義だったり、まったく数値化できない謎の文字列が入っていたりすると「NaN」という特殊な数値になってしまい、こいつは厳密には0ではないため問題を引き起こすので、そういう変な値がとれてしまった場合はちゃんと0にする必要がある
「parseInt(value,10) || 0」と書くことにより「左辺（parseIntの返値）を真偽値とみなして判定し、もし偽として判定される値（0, NaNのほかnull, undefined等が該当する）であれば||の右辺（0）を採用する」という意味になる
.clamp()って標準のメソッドにあったっけ…？まあ一般的に想像すれば、数値がmin ～ maxの範囲を超えていたら範囲内におさめるってことじゃないの
Rコンソールに一行ずつコマンドを入力してもいいけど、実際に使うにはテキストファイルにコマンドを書いて（ソースコード）一気に実行させる方が楽。
source('hogehoge.R')
hogehoge.Rというのがソースコードを書いたファイル（ソースファイル）の名前。
CRANという、CPANのパクリがある。膨大な数のライブラリがあるので、好きなものをインストールするには、
install.packages('hoge',dependencies=TRUE)
とするのが楽。
＞ あ<-1 ＞ あ [1] 1
a<-1 b=2 1-＞a
どれでもいい。但し推奨されてるのは一番上。Rの人は「束縛」という言葉を使いたがる傾向があるけど、どっちでもいいと思う。
余談だけど、関数の引数の中で代入できる、しかもその値をそのあとの引数で使える。これ実は便利。
＞ sum(a<-1,a) [1] 2
＞ a [1] 1 ＞ str(a) num 1 ＞ summary(a) Min. 1st Qu. Median Mean 3rd Qu. Max. 1 1 1 1 1 1
最後のsummaryはRっぽい。strっていうのはstringではなくstructの略（だと思ってる）。Rの変数はいくらでも複雑な構造になり得るけど、そのときにぱっと見がわかるように構造を出力してくれる。
Rの基本はベクトル。
ベクトルの作り方はいくらでもあるけど、例示するのが早いでしょう。
＞ x<-1:3
＞ y<-c(TRUE, FALSE, TRUE)
＞ z<-c("a","b","c")
＞ x
[1] 1 2 3
＞ y
[1] TRUE FALSE TRUE
＞ z
[1] "a" "b" "c"
他にもいっぱいあるし、関数の返値がベクトルってこともよくある。
＞ runif(3) [1] 0.2200965 0.6391403 0.1089252
一様乱数を三個作った。
＞ x<-letters[1:5] ＞ x [1] "a" "b" "c" "d" "e" ＞ x[2] [1] "b" ＞ x[4:5] [1] "d" "e" ＞ x[c(1,3,5)] [1] "a" "c" "e"
こんな感じで、[]の中に添え字でアクセス。1-indexなので注意。2,3番目の例では添え字にもベクトルを使って、複数の要素に一気にアクセスしてる。
＞ x[3]<-"z" ＞ x [1] "a" "b" "z" "d" "e"
でOK。
要望があれば続くかも。
C/C++にいくつか思うこと （ちなみに、プログラマ始めたのはCができた頃でC++よりも私のプログラマ歴の方が長い）
Cはポインタ というか、ポインタを使いこなすことで、チューニングしていく言語だから ポインタ使いたくない＝チューニングしたくない
って人は他の高級言語で良いと思う。ただ、動画などの処理をC/C++又はアセンブラ以外で書く人というのは、あまり聞かないので
速度が必要＝C/C++って事かと思う。
昔、全くチューニングしていない、CとJavaを比べて同じ速度だからJavaでもOKというレポートを読んだことがあるのだが、あれは酷かった。
Ｃはチューニングしたときに、もっとも伸びしろが大きく、必要な場合アセンブラと並記できることで、ほぼアセンブラという領域まで
チューニングできるところが魅力。その際、ポインタは無くてはならない。知っておくべき技術。
繰り返しになるけどチューニングしない人には意味がない言語と言われればその通り。
また、ポインタだけではなく、レジスタについても知っておくとＣでの伸びシロが大きくなる。
そして、少なくともアセンブラレベルでのＰＵＳＨ，ＰＯＰ，ＣＡＬＬは覚えておいた方がよい。
関数コールをすると、レジスタ類の待避がアセンブラレベルでは走り、その上、スタックに引数や返値を積んでジャンプするという
ものすごく遠大な処理がアセンブラレベルでは走っているが、Ｃレベルでは１行の関数コールに見える。
という事を理解しておくと、Ｃ＋＋でのインライン関数の重要性や、再帰関数が実行時にはかなり重い理由が頭の中に浮かんでくる。
こういう言い方をすると、最近はＣＰＵが早いから大丈夫とか言う人が多いが、じゃぁＷｉｎｄｏｗｓ Ｖｉｓｔａは売れましたか？と聞きたい。
少なくともチューニングが必要な事もある。必要ないこともある。という事で選択すれば良いと思う。
たかだか、数行のスクリプトでチューニング不要ならそりゃ、Ｐｅｒｌつかうさ
参考までに書いておくと、個人的感覚ではＣ＋＋はオブジェクト指向言語ではない。
アセンブラにまで行き着く Ｃ言語を大規模開発する時に最低限必要となる抽象化をするための言語
そのために、まともにＯＯＰで設計するとＣ＋＋では重くなる事が多い。いかに、崩せるかがキモ。
またＣ＋＋使いか？エセＣ＋＋使いか？の見分け方は
constを正しく使えるか？参照を正しく使えるか？ vtableの説明ができるか？
という質問に正しく答えられるか？で見分けると結構見分けがつくと思っている。
COBOLにもローカル変数やサブルーチンの引数はあるんだけど、それを使っちゃいけない企業文化で育った結果、他の言語でもその慣習を押し通したコードを書き続ける人が多いみたい。要はCOBOL以外の言語を勉強してないだけなんだけど。
業務経歴書にCOBOLって書いてあったら書類で不採用…ってしちゃった方が面接に使う時間を減らせて楽そうとも思うんだけど、「それ明らかに偏見・理不尽だろ」って自分ツッコミが入っるのでそれはやってないんだよね。
でも実際問題今までにお会いした「COBOLから業界に入った人」はみんなこんな感じで、ウチでは採用できない確率100%なんだよなあ。求む！偏見を覆せるCOBOLer！なんつってな。普通にまともにプログラムが書ける人ならCOBOL歴の有無なんかどうでもいいです。むしろ業務経験の有無すらどうでもいい。