これからコードを書く人に絶対やって欲しいこと
1 ：仕様書無しさん：
もしくはやって欲しくないこと
先輩方のアドバイスをください
先輩方のアドバイスをください
|
|
|
【萌え画像】うちの子猫に初音ミクの格好させてみた(*´Д`)ﾊｧﾊｧ
http://engawa.2ch.net/test/read.cgi/jobs/1361676127/
http://engawa.2ch.net/test/read.cgi/jobs/1361676127/
疑問形とか「とりあえず」のコメントを残すな
常識を勉強しろ
まず自分の頭で考えろ
人のせいにするな、コピペしたからなんて理由になんねーよ
まず自分の頭で考えろ
人のせいにするな、コピペしたからなんて理由になんねーよ
俺に後始末させるな
テストコード書け
修正の量(分かりやすく言えばdiff結果）を最小限にしようとするな。
再設計を行なって、正しく修正しろ。
再設計を行なって、正しく修正しろ。
最初から、最高のやり方でやれ。最高のやり方を探せ。
「お前にはまだ早い」だとという言葉に耳を貸すな。
「お前にはまだ早い」だとという言葉に耳を貸すな。
短いコードであってもパッと見て意味がわからないのなら
関数（メソッド）を作れ。
コメントを書くぐらいなら
適切な名前の関数を作ったほうが良い。
例えば、正規表現を書くよりも、その正規表現で
やりたいことを意味する関数を作ったほうがいい。
関数（メソッド）を作れ。
コメントを書くぐらいなら
適切な名前の関数を作ったほうが良い。
例えば、正規表現を書くよりも、その正規表現で
やりたいことを意味する関数を作ったほうがいい。
動的型付け言語なら高機能なテキストエディタを使え
静的型付け言語ならIDEを使え。
なぜなら、動的型付け言語ではIDEのサポートが十分に得られない。重いだけ。
静的型付け言語はコード自体は冗長になるが、IDEのサポートで大幅に生産性が上がる。
静的型付け言語ならIDEを使え。
なぜなら、動的型付け言語ではIDEのサポートが十分に得られない。重いだけ。
静的型付け言語はコード自体は冗長になるが、IDEのサポートで大幅に生産性が上がる。
人力テストは極力なくせ。
人力テストとは、ブラウザを開いてフォームに値を入れてクリックするとか
アプリを起動してメニューを選んでクリックするとか、
出力ファイルを眺めておかしい所がないかチェックするとか、
そういうことを人間が毎回操作してテストすることだ。
人力テストとは、ブラウザを開いてフォームに値を入れてクリックするとか
アプリを起動してメニューを選んでクリックするとか、
出力ファイルを眺めておかしい所がないかチェックするとか、
そういうことを人間が毎回操作してテストすることだ。
理由が書いてない（納得出来ない）
コーディング規約はゴミだ。作るな。従うな。
初心者のためのコーディング規約は糞だ。
（難しくてわからないから）○○機能は使わないこと。
糞な規約の例として
三項演算子は使わない。
クラスは作らない。
継承は使わない。
等がある。
コーディング規約はゴミだ。作るな。従うな。
初心者のためのコーディング規約は糞だ。
（難しくてわからないから）○○機能は使わないこと。
糞な規約の例として
三項演算子は使わない。
クラスは作らない。
継承は使わない。
等がある。
コードは書くことよりも、読む時のことを考えろ。
短く書いたとしても、読みにくければそれは駄目なコードだ。
コーディングにかける時間の8割は、コードを読むことに使わている。
短く書いたとしても、読みにくければそれは駄目なコードだ。
コーディングにかける時間の8割は、コードを読むことに使わている。
人売り営業のためのスレ
最初から正しいコードを書くことにこだわるな。どうせ無理だ。
そうではなく良くないコードから正しいコードへ書き換える手段を身につけれ。
そうではなく良くないコードから正しいコードへ書き換える手段を身につけれ。
循環的複雑度。これを早い段階で計測できるようにしろ。
客観的にコードの汚さ、目安が計測できる。
これは各言語ごとにツールが有るはずだ。
客観的にコードの汚さ、目安が計測できる。
これは各言語ごとにツールが有るはずだ。
警告は有効にし、警告レベルは最大にしろ。
エラーはログに表示させ、そのログを見ることを覚えろ。
場合によっては、それができる仕組みを作れ。
あれ？ なぜか動かない？原因がよくわからない。などという時
実はちゃんと設定やコードを書けば、起きてるエラーが取得できる事が多い。
余談だが、データベースの設定に警告レベルがあったりもする。
エラーはログに表示させ、そのログを見ることを覚えろ。
場合によっては、それができる仕組みを作れ。
あれ？ なぜか動かない？原因がよくわからない。などという時
実はちゃんと設定やコードを書けば、起きてるエラーが取得できる事が多い。
余談だが、データベースの設定に警告レベルがあったりもする。
初心者が何かに関して勉強したいと思ったら、本は最低二冊買え。
簡単でわかりやすい本と、難しいが間違いが少なく詳しく書いてある本だ。
いきなり難しい本では挫折するが、簡単な本には間違いが多い。
簡単な本は不要になったら捨てて良い。
簡単でわかりやすい本と、難しいが間違いが少なく詳しく書いてある本だ。
いきなり難しい本では挫折するが、簡単な本には間違いが多い。
簡単な本は不要になったら捨てて良い。
相手が自分と同じ知識を持っていると思うな。
それがたとえ先輩でもだ。
分かりやすく書くことに労力を惜しむな。
耳を貸すなとかいうネガティブな言葉が出て来たら、自分の中でその理由が納得できるまでは鵜呑みにするな。
それがたとえ先輩でもだ。
分かりやすく書くことに労力を惜しむな。
耳を貸すなとかいうネガティブな言葉が出て来たら、自分の中でその理由が納得できるまでは鵜呑みにするな。
めっちゃ勉強になりますわ
「言語・ライブラリにバグが有るようです」
「こういうことは出来ないようです」
初心者が口にしたら怒られるセリフ。
なぜなら実際には「お前が間違ってるから」
「こういうことは出来ないようです」
初心者が口にしたら怒られるセリフ。
なぜなら実際には「お前が間違ってるから」
ソースコード管理ツールを使え。
gitやsubversionのことだ。
gitやsubversionのことだ。
特定の言語をディスるな。
特に自分がよく知らない言語はディスるな。
反論されて恥をかくだけ。
言語をディスっていいのは、何かの言語の作者だけだ。
言語の作者が自分で作った言語を褒めて、他の言語をディスるのは
営業的な意味で当然やるべき行為だからだ。
だが他人がそれを真似るな。鵜呑みにするな。
特に自分がよく知らない言語はディスるな。
反論されて恥をかくだけ。
言語をディスっていいのは、何かの言語の作者だけだ。
言語の作者が自分で作った言語を褒めて、他の言語をディスるのは
営業的な意味で当然やるべき行為だからだ。
だが他人がそれを真似るな。鵜呑みにするな。
26 ：仕様書無しさん：2013/03/10(日) 23:02:59.30
コードと直接関係はないけど
何かでエラーが出たりした時に、
なにも調べず、質問サイトで質問はやめて欲しい。
何かでエラーが出たりした時に、
なにも調べず、質問サイトで質問はやめて欲しい。
エラーメッセージ（英語）を読むこと
お前らが言うようなこと実践出来るような裁量をコーダーに与えられるの？
さすがにマ板だな。
「先輩の言うことを良くきけ」がなかった。
ニュース系の板のプログラムスレには絶対いるのに。
「先輩の言うことを良くきけ」がなかった。
ニュース系の板のプログラムスレには絶対いるのに。
聞く必要はない
盗め(使えるところだけ)
盗め(使えるところだけ)
>>25
反論されて恥をかくっていうか、特定の言語しか使えなくて、しかも
その言語の知識も中途半端な人にかぎって、言語の話題は感情的になるから
デリケートに扱ったほうがいいな。
DISる意図がなくても、うっかり話題をふったりしたらエキサイトされるとかあるから。
反論されて恥をかくっていうか、特定の言語しか使えなくて、しかも
その言語の知識も中途半端な人にかぎって、言語の話題は感情的になるから
デリケートに扱ったほうがいいな。
DISる意図がなくても、うっかり話題をふったりしたらエキサイトされるとかあるから。
33 ：仕様書無しさん：2013/03/11(月) 19:24:40.65
◆電波王の顔写真が公開されるプログラム◆
１．メモ帳に↓をコピペする
for(;;){ WScript.Echo('このウィンドウは永久に消えません。m9（＾Д＾）プギャー'); }
２．ファイル名を↓で保存する
電波王顔.avi .js
これだけでOK！
１．メモ帳に↓をコピペする
for(;;){ WScript.Echo('このウィンドウは永久に消えません。m9（＾Д＾）プギャー'); }
２．ファイル名を↓で保存する
電波王顔.avi .js
これだけでOK！
こういうときどういう顔していいかわからないけど、とりあえず笑えばいいのかな
笑えばいいと思うよ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗ
>>25
最近こういうの流行ってるのかね。
このまえスラドで動的.vs.静的型言語みたいなスレがたったときも、作者で無いのに
文句言うなとか、ポジショントークでけなしてるとか言うやついたわ。
オタクがアニメとか漫画の議論で「なら自分で書いてみろ」って言ったり
「なんとか監督が声優を評価しないのは、タレントを起用するためのポジショントーク」みたな
ことを言うけど、技術的な話にそういう論法を持ち込まないでほしいわ。
きもい。
最近こういうの流行ってるのかね。
このまえスラドで動的.vs.静的型言語みたいなスレがたったときも、作者で無いのに
文句言うなとか、ポジショントークでけなしてるとか言うやついたわ。
オタクがアニメとか漫画の議論で「なら自分で書いてみろ」って言ったり
「なんとか監督が声優を評価しないのは、タレントを起用するためのポジショントーク」みたな
ことを言うけど、技術的な話にそういう論法を持ち込まないでほしいわ。
きもい。
>>29
実践できなければ、裁量権のないコーダーとして働いてもらうしかないな。
実践できなければ、裁量権のないコーダーとして働いてもらうしかないな。
煽りスレかと思ったら良スレだったわ
1行ごとに、なぜそう書いたのか理由を意識しながら書き進めること。
ジジイどもが後生大事にしてる、FORTRAN時代から引き継がれている
「プログラミングの常識」を全部投げ捨てろ
ループカウンタはi、j、数値はn、文字はcとか、慣例的な一文字変数が当たり前だと思うな
何の目的で使われる変数なのか、直接変数名として表せ
「ちゃんとコメントを書く」とか馬鹿げたことをするな
全行にコメントを入れるとか死んだ方がいい
コメントとは、コードだけで何をしている処理なのか上手く表現できなかったときに
恥ながら書くものだと思え
コードはどんどん直せ
「動いてるコードは触るな！」とかいう老害の言うことに耳を傾けるな
テストファーストは理想論
ケント・ベックも「ちっちゃいプロジェクトもいちいちテストドリブンで作るのはメンドイよねw」
って言ってる
だからテストユニットなんて気にせずどんどん汚いコードは書き直せ
悦に浸れるくらい綺麗なコードはバグも湧かない
「プログラミングの常識」を全部投げ捨てろ
ループカウンタはi、j、数値はn、文字はcとか、慣例的な一文字変数が当たり前だと思うな
何の目的で使われる変数なのか、直接変数名として表せ
「ちゃんとコメントを書く」とか馬鹿げたことをするな
全行にコメントを入れるとか死んだ方がいい
コメントとは、コードだけで何をしている処理なのか上手く表現できなかったときに
恥ながら書くものだと思え
コードはどんどん直せ
「動いてるコードは触るな！」とかいう老害の言うことに耳を傾けるな
テストファーストは理想論
ケント・ベックも「ちっちゃいプロジェクトもいちいちテストドリブンで作るのはメンドイよねw」
って言ってる
だからテストユニットなんて気にせずどんどん汚いコードは書き直せ
悦に浸れるくらい綺麗なコードはバグも湧かない
> ループカウンタはi、j、数値はn、文字はcとか、慣例的な一文字変数が当たり前だと思うな
> 何の目的で使われる変数なのか、直接変数名として表せ
何の目的かわかることが目的なので、
一文字でも問題ない。
for(int i=0; i < str.length; i++) {
}
これ見ればiは文字列の中の文字の一だってわかるだろ？
ならば問題ない。スコープがカギだ。
スコープを小さくすることで、目的がわかるならばiで構わん。
> 何の目的で使われる変数なのか、直接変数名として表せ
何の目的かわかることが目的なので、
一文字でも問題ない。
for(int i=0; i < str.length; i++) {
}
これ見ればiは文字列の中の文字の一だってわかるだろ？
ならば問題ない。スコープがカギだ。
スコープを小さくすることで、目的がわかるならばiで構わん。
教えたがる奴の言うことは信用するな
そうだな、入門書のコーディングから抜け出すのか、初心者からのレベルアップだな。
>>44
言い返せなかった時点でお前の負けだよｗ
言い返せなかった時点でお前の負けだよｗ
42じゃねえけど
for (int loopCounterForNantoka = 0; i < stringForNantoka.length; loopCounterForNantoka++) {
}
とか書いてるアホが居たらループカウンタのほうは速攻で i とかにリファクタリングするけどな
for (int loopCounterForNantoka = 0; i < stringForNantoka.length; loopCounterForNantoka++) {
}
とか書いてるアホが居たらループカウンタのほうは速攻で i とかにリファクタリングするけどな
for (int loopCounterForNantoka = 0; loopCounterForNantoka < stringForNantoka.length; loopCounterForNantoka++) {
}
}
>>47
そら、loopCounterForNantokaが何の意味も持たないからだな。
>>41が言ってるのは
for (int customerIndex = 0; customerIndex < sales.customers.length; i++) {
のほうが
for (int i = 0; i < sales.customers.length; i++) {
よりマシつーぐらいの意味だろ。
普通は
for (int customerIndex : sales.customers) {
だけどな。
そら、loopCounterForNantokaが何の意味も持たないからだな。
>>41が言ってるのは
for (int customerIndex = 0; customerIndex < sales.customers.length; i++) {
のほうが
for (int i = 0; i < sales.customers.length; i++) {
よりマシつーぐらいの意味だろ。
普通は
for (int customerIndex : sales.customers) {
だけどな。
スコープが小さいなら
短い変数名で構わない。
短い変数名で構わない。
リポジトリと凡ミスチェッカではじけるならならなんでも良い
i,jなんかは不可
for(int i=0; i < str.length; j++) {
}
とか迷惑
i,jなんかは不可
for(int i=0; i < str.length; j++) {
}
とか迷惑
一文字変数絶対禁止は、馬鹿ほどがんじがらめのルールを好む事をよく表しているな。
>>52
浅はかだね。何で否定派がいるのか考えたほうがいいよ
浅はかだね。何で否定派がいるのか考えたほうがいいよ
大体仕事の場合は、一文字の変数名はカウンタを含めて、殆どコーディング規約で禁止されている。
i、j、k、iiで回ってる4重ループ見たときには、書いたやつに殺意が湧いた
>>54
変数台帳で通し番号管理しているところはお呼びでないのでお帰りください
変数台帳で通し番号管理しているところはお呼びでないのでお帰りください
変数を台帳で管理してるかのような
極論を持ち出さないと反論できない時点でw
極論を持ち出さないと反論できない時点でw
1文字だと検索した時に視認性が悪くて不便なんだよ。最低3文字くらいは欲しい。
いまだかつて、単なるループカウンタを検索したいと思った事などないんだが。
何か間違ってるぞ、そのプログラム。
何か間違ってるぞ、そのプログラム。
お前プログラム書いたことないだろ
>>60って本当にわかりやすい土方だなw
バカ丸出しw
バカ丸出しw
ループカウンタを「単なるループカウンタ」としてしか使ったことがないコーダーなのだろう。
ループカウンタを別の用途に使わないでください（笑）
プログラマがこんなに頭の悪い奴ばっかりとは思わなかったわｗ
その代表が>>67ですね。
ズレてる奴はさっさとプログラマやめたほうがいいよｗ
>>65
それはないわｗ無理して反論しようとすんなｗ
それはないわｗ無理して反論しようとすんなｗ
ループカウンタをループ以外の目的に使いたい無能がいるから
１文字変数禁止みたいなキチガイルールができる。
１文字変数禁止みたいなキチガイルールができる。
モニタはWUXGAが当たり前の今の自体、十数文字くらいの変数名どうということはない
fm[i].Enable();
と、
fileMenu[selectedItemIndex].Enable();
では、どっちが意味を理解しやすいか言うまでもない
前者の書き方で、さらにコメント添えるとかアホの極み
配列の添え字はiじゃなきゃヤダヤダとかいう低脳は、もうプログラマ引退した方がいい
fm[i].Enable();
と、
fileMenu[selectedItemIndex].Enable();
では、どっちが意味を理解しやすいか言うまでもない
前者の書き方で、さらにコメント添えるとかアホの極み
配列の添え字はiじゃなきゃヤダヤダとかいう低脳は、もうプログラマ引退した方がいい
selectedItemIndexがループカウンタとか、キチガイじゃねーの
うわぁ…
selectedItemIndex
wwwwww
wwwwww
Javaの長ったらしい変数名は諸悪の根源
foreachだろJK
今時for使うとか無いわ
今時for使うとか無いわ
selectedItemIndexよりiのほうがいいと思うバカは今すぐプログラマやめたほうがいい
ループカウンタの話だぞ？文脈読めないバカは今すぐプログラマやめたほうがいい
インデントはスペースで統一しろ
tabとスペースが混じったコードはうんこ
処理を書いた行にはコメントを入れるな
hogehogehogehogehogehogehogehogehogehogehogehogehogehogehoge();//コメントが最後にあると読みにくいときがある
tabとスペースが混じったコードはうんこ
処理を書いた行にはコメントを入れるな
hogehogehogehogehogehogehogehogehogehogehogehogehogehogehoge();//コメントが最後にあると読みにくいときがある
ループカウンタで selectedItemIndex とか書いてるアホが居たら速攻で i とかにリファクタリングするわ
コードうんぬんの話じゃないんだけど質問
自分で使うものなら作ったことあって、今後アプリ開発するつもりです
引っ越すから回線はWimaxでいこうと思ってるんだけど、回線の速度はどれぐらい必要かな？
TRY Wimaxでの測定では下り速度3.1Mbps、上り速度0.3Mbps
下りに関しては文句ないぐらいなんだけど、上りがよく分からない
アップロードって頻繁にするかな？
自分で使うものなら作ったことあって、今後アプリ開発するつもりです
引っ越すから回線はWimaxでいこうと思ってるんだけど、回線の速度はどれぐらい必要かな？
TRY Wimaxでの測定では下り速度3.1Mbps、上り速度0.3Mbps
下りに関しては文句ないぐらいなんだけど、上りがよく分からない
アップロードって頻繁にするかな？
どういう場合も、iやjが許されないって
言ってる奴って、根拠あるの？
言ってる奴って、根拠あるの？
そりゃprintするだけならiでいいだろ
そんな業務はないと思うけど
そんな業務はないと思うけど
業務はなくても、関数は小さくしていくもの。
小さい関数では、iという変数でも問題ないという話。
printがiでいいならば、
単なるループ変数もiでよいということ。
小さい関数では、iという変数でも問題ないという話。
printがiでいいならば、
単なるループ変数もiでよいということ。
変数名にnなんとかlpszなんとかって付けるの気持ち悪いからやめて
C系統からの悪習なんだが
C系統からの悪習なんだが
添字が複数あるところでi,j,kを使われるのは困るが
iだけで済むのならそれでよかろうて
iだけで済むのならそれでよかろうて
いまどきハンガリアンなんか使ってるとこあるのか
Microsoftでもとっくにやめたのに
Microsoftでもとっくにやめたのに
selectedItemIndexForFileMenuUsedAsALoopCounter
愛がなければこんな言い争いは起こらない
94 ：仕様書無しさん：2013/03/25(月) 09:48:44.34
アイちゃん
昔ループカウンタにhogefugaIndexとか長い名前使ってみたら超読みにくくなってすぐやめた。
長い名前を好む人たちって、長いメソッド書いてそうだな。
平均で20行以上ありそう。
平均で20行以上ありそう。
for (i = foo_length; i++; i < MAX_SIZE_OF_FOO) putchar(bar[i]);
i 絶対悪派は、こういったコードでもループカウンタの i を否定するのかな？
for (index_of_foo = foo_length: index_of_foo++; index_of_foo < MAX_SIZE_OF_FOO)
putchar(bar[index_of_foo]);
こちらのほうが可読性が優れている.....？
分かりませんw
i 絶対悪派は、こういったコードでもループカウンタの i を否定するのかな？
for (index_of_foo = foo_length: index_of_foo++; index_of_foo < MAX_SIZE_OF_FOO)
putchar(bar[index_of_foo]);
こちらのほうが可読性が優れている.....？
分かりませんw
>> for (i = foo_length; i++; i < MAX_SIZE_OF_FOO)
ﾜﾛﾀ
ﾜﾛﾀ
言語にもよるけど無限ループするなw
は？
>>49 も変更漏れがw
もしかしてこのスレってプログラミング初心者ばっかりなの？
iはindexの略
数学の添え字でiやjを使うのをfortranが取り入れて、そこから広まった習慣。
ichijitekiのi
>>103
jとkは？
jとkは？
>>106
混乱することもあるので使わない
混乱することもあるので使わない
つーか、カウンタを検索した事ない、世界が違うプログラマって、何のプログラム作ってるの？
ドライバとかか？
ドライバとかか？
カウンタ検索するぐらいなら、
カウンタの条件の方を検索するだろ？
なんたら.lengthのなんたらとか。
カウンタの条件の方を検索するだろ？
なんたら.lengthのなんたらとか。
IDENTIFCATION DIVISION。
JYOSHI KOUSEI
カウンタそのものを検索するシーンのがわからん
実例を出してくれ
実例を出してくれ
ループ変数に長い名前つけるとか、
世の中にはいろんなキチガイがいるんだなぁ
勉強になるは
世の中にはいろんなキチガイがいるんだなぁ
勉強になるは
暗黙の型宣言
>勉強になるは
>勉強になるは
>勉強になるは
>なるは
>なるは
>なるは
>は
>は
>は
日本語も使えない脳足りんがプログラミング言語とかw
>勉強になるは
>勉強になるは
>なるは
>なるは
>なるは
>は
>は
>は
日本語も使えない脳足りんがプログラミング言語とかw
今時2ch特有の言い回しにマジレスするアホが居るとは
それ以外に言い返すところなかったんか…？
それ以外に言い返すところなかったんか…？
とりあえず短い変数名を使う場合はスコープを狭くしておくれ。
グローバルでiとかｊとかｋとか使うんだったら、せめて名前空間だけでもつけておいてくれ。
ローカルでも遠いところに宣言するなら変数名が長くなってもいいからわかりやすくしてくれ。
間違っても不可解な短縮形にするのはやめてくれ。
今時floatよりもdoubleの方が早いと言ってむやみに倍精度にしないでくれ。
とにかく半年後や1年後に自分が読んでも恥ずかしくないコードを書いてくれ。
頼むよ。
グローバルでiとかｊとかｋとか使うんだったら、せめて名前空間だけでもつけておいてくれ。
ローカルでも遠いところに宣言するなら変数名が長くなってもいいからわかりやすくしてくれ。
間違っても不可解な短縮形にするのはやめてくれ。
今時floatよりもdoubleの方が早いと言ってむやみに倍精度にしないでくれ。
とにかく半年後や1年後に自分が読んでも恥ずかしくないコードを書いてくれ。
頼むよ。
i,j,k派に答えなんて教えないよ。そのままつっぱしれ〜
やだー
グローバルでijkとか頭おかしい
グローバルの i をいろんなところで利用しまくって特定のケースで無限ループに陥るってアホソースは昔見たことある
流石に笑いをこらえきれなかった
流石に笑いをこらえきれなかった
JISSUU は整数
SEISUU は実数
SEISUU は実数
ijkでも別にいーじゃんかby愛の女子高生
>>124
20行でも必要だろう？目視で探すのか？
20行でも必要だろう？目視で探すのか？
iループを他のループで囲うことになったらどうすんの？
h使うの？
h使うの？
for(k
for(j
for(i
じゃないのか？
for(j
for(i
じゃないのか？
>>127-128
愛の前にはエッチがあるだろ常識的に考えて
愛の前にはエッチがあるだろ常識的に考えて
>>97
どっちもバグってるだろカスw
どっちもバグってるだろカスw
>>131
10年以上普通にやってれば、何回かは見るよ。
10年以上普通にやってれば、何回かは見るよ。
コーディング規約にも2種類あってね。
一つは、いろんなやり方があって、どれでもいいが統一しましょうってだけの規約。
例えばインデントはスペースいくつにするか？みたいな。
後はディレクトリ構成とか日本語英語対応表とか。
こういう規約はどこでも必要。
もう一つは、素人プログラマに生産性マイナスみたいなコードを
書かせない様にするための縛り。一行80文字とかそういうの。
プロならそんな縛りがなくても見やすいコードを書ける。
プロなら一行80文字というルールがなくてもたいてい80文字以内に収めるし、
超える場合は改行した場合と比較して見やすい方で書く。
プロが多い所なら一行80文字という規約はデメリットをもたらすだけの意味のない規約だが、
素人ばかりならデメリット以上にメリットがあるから仕方なく必要。
ループ変数のiも同じでしょ。規約なくてもプロならスコープが小さい場合にだけ使う。
だけど素人ばかりなら、真似てスコープが広いものにまで使う。
だから素人向けに縛り規約を作る。（もちろんそれはプロの間ではデメリットになる）
一つは、いろんなやり方があって、どれでもいいが統一しましょうってだけの規約。
例えばインデントはスペースいくつにするか？みたいな。
後はディレクトリ構成とか日本語英語対応表とか。
こういう規約はどこでも必要。
もう一つは、素人プログラマに生産性マイナスみたいなコードを
書かせない様にするための縛り。一行80文字とかそういうの。
プロならそんな縛りがなくても見やすいコードを書ける。
プロなら一行80文字というルールがなくてもたいてい80文字以内に収めるし、
超える場合は改行した場合と比較して見やすい方で書く。
プロが多い所なら一行80文字という規約はデメリットをもたらすだけの意味のない規約だが、
素人ばかりならデメリット以上にメリットがあるから仕方なく必要。
ループ変数のiも同じでしょ。規約なくてもプロならスコープが小さい場合にだけ使う。
だけど素人ばかりなら、真似てスコープが広いものにまで使う。
だから素人向けに縛り規約を作る。（もちろんそれはプロの間ではデメリットになる）
スコープが小さくたって、変数名はちゃんと意味があるものにしたほうがいい。
i, j, kで満足するのは素人。
i, j, kで満足するのは素人。
i, j, kというのはループ変数という意味がちゃんとあります。
誰もaという変数名を使えなんて言ってないでしょ？
誰もaという変数名を使えなんて言ってないでしょ？
あとからループの外にループが必要になることなど論理的にあり得ない
ロジックが二重ループになる時点で人間のクズ。
プログラムを修正して２重ループが思い浮かんだら
どっか論理がおかしい、最適解ではないと普通のプログラマなら
気づいて思いなおすだろうね。
どっか論理がおかしい、最適解ではないと普通のプログラマなら
気づいて思いなおすだろうね。
つまりお手上げ状態で打つ手がないから起こりえないことにせざるを得ない、
ってことだね。一文字派の完敗宣言と認識した。
ってことだね。一文字派の完敗宣言と認識した。
理屈こねて答えから逃げる面々w
二重がダメならi,j,kなんていらないじゃん
でも、i以外使うなとは言わないよね
二重がダメならi,j,kなんていらないじゃん
でも、i以外使うなとは言わないよね
何か修正が入った時、近くの関連コードを修正せずに
新しいコードを追加して済ませようとするのは
やめなさい。
触らぬ神に祟りなしで、既存のものをそのままにして
追加だけしていこうとするから、すぐにコードが汚くなる。
新しいコードを追加して済ませようとするのは
やめなさい。
触らぬ神に祟りなしで、既存のものをそのままにして
追加だけしていこうとするから、すぐにコードが汚くなる。
元々あるループの内や外に、更にループを足すような変更は絶対にするな。
>>139
> iループをループで囲うことになったらどうするの？>>127にも書いたけど。
何か問題でも？ i, j, kと続けることになってるし、
もしそれでコードが複雑になるのであれば、
iを違う名前にスレばいいじゃない。
あくまで、スコープが小さい（＝コードが短い）場合は
iでいいといってるだけ。
コードが長くなったなら、変更すればいいだけじゃない。
> iループをループで囲うことになったらどうするの？>>127にも書いたけど。
何か問題でも？ i, j, kと続けることになってるし、
もしそれでコードが複雑になるのであれば、
iを違う名前にスレばいいじゃない。
あくまで、スコープが小さい（＝コードが短い）場合は
iでいいといってるだけ。
コードが長くなったなら、変更すればいいだけじゃない。
数学的帰納法でいえば、なん重目かわからない一文字変数が永遠に増えてづけるということだね。
呆れて開いた口が塞がらないよ。現在医学ではこの開いた口は塞がらないかもね。
呆れて開いた口が塞がらないよ。現在医学ではこの開いた口は塞がらないかもね。
ぷぷぷ。負け惜しみ。
変なやつだな。一文字変数はi,j,kの３つしかでてないのに
永遠に増えるとか、どういう根拠？
2重ループでもあまりやるものではないと言われてる。
3重ループはもっとやらない。
コードがシンプル（シンプルならたいてい１重ループ）の時はiでいい。
という話なのに、複雑な場合はどうすんの？とか
最初の前提から外れてるだろ。
永遠に増えるとか、どういう根拠？
2重ループでもあまりやるものではないと言われてる。
3重ループはもっとやらない。
コードがシンプル（シンプルならたいてい１重ループ）の時はiでいい。
という話なのに、複雑な場合はどうすんの？とか
最初の前提から外れてるだろ。
一文字推奨派が右往左往w
二重ループがダメならjとkはいつ使うの？
ねえねえ？
二重ループがダメならjとkはいつ使うの？
ねえねえ？
コードがシンプルで2重ループが必要なときだろ？
ijkの弊害を理解した上でシンプルでスコープの小さい簡単なループにはiを使っても良いって言ってんの
高々10行以下のコードに
ループカウンタで selectedItemIndex (笑)とか可読性減らしてる
挙句の果てに20行のときはどうすんの？とか2重3重ループのときはどうすんの？とか聞いて来ること自体おかしい
その時は分かりやすい違う名前にすればいい
高々10行以下のコードに
ループカウンタで selectedItemIndex (笑)とか可読性減らしてる
挙句の果てに20行のときはどうすんの？とか2重3重ループのときはどうすんの？とか聞いて来ること自体おかしい
その時は分かりやすい違う名前にすればいい
>>154
ループの中のコードがあとから増えることとか全然考えないんだな
ループの中のコードがあとから増えることとか全然考えないんだな
>>155
ループの中のコードの行数が多かったり複雑ならi以外の名前を命名すればいいじゃん
ループの中のコードの行数が多かったり複雑ならi以外の名前を命名すればいいじゃん
考える必要性を全く感じない
ループ内の行数が極端に増えないように追加しろ
どうしてもそのループ内に直接増やさざるを得ないなら変数名リファクタリングしろ
そのくらいのこともできないほどアホなのか
ループ内の行数が極端に増えないように追加しろ
どうしてもそのループ内に直接増やさざるを得ないなら変数名リファクタリングしろ
そのくらいのこともできないほどアホなのか
「その時は分かりやすい違う名前にすればいい」
「変数名リファクタリングしろ」
その考えがあるなら最初からやっとけよw
横着すんな
「変数名リファクタリングしろ」
その考えがあるなら最初からやっとけよw
横着すんな
短い範囲で糞長い変数名連発されると読みにくいってば
160 ：仕様書無しさん：2013/03/27(水) 02:52:52.21
ループカウンタ論争
157に完全同意
10行前後の生存範囲の一時変数なんざカスみたいな命名で問題ない
むしろコイツは短命の一時変数だと認識できて読みやすくなる
ループカウンタごときに厳密な命名をしておかないと検索できない(笑)って
どんなコード書いたらそんなことになるんだ
スクロールしまくらないと最後までたどり着けないような超大作メソッド？
むしろコイツは短命の一時変数だと認識できて読みやすくなる
ループカウンタごときに厳密な命名をしておかないと検索できない(笑)って
どんなコード書いたらそんなことになるんだ
スクロールしまくらないと最後までたどり着けないような超大作メソッド？
>>162はわかりやすい「シッタカ素人」だねえw
この問題については、言語の文化圏に合わせた方が良い
Javaならループカウンタであっても冗長な名前にするべきだし（コーダは底抜けにアホが多い）
他の言語なら1文字でも良い
Javaならループカウンタであっても冗長な名前にするべきだし（コーダは底抜けにアホが多い）
他の言語なら1文字でも良い
>ループカウンタごとき
という程度のコードしか書いた事がないんだねw
バカ丸出しww
という程度のコードしか書いた事がないんだねw
バカ丸出しww
>>142
2重ループは普通に使う。例えば九九の表。
内側のループで外側のカウンタを計算に使うから、内側を関数にしてカウンタを引き渡すより分かりやすい。
>>154
ループ内が20行など普通にある。
ちなみに50や100行も普通にある。
例えば、項目の多いプリンタ出力や入力項目チェック、項目の多いDBテーブル検索や登録。
上記九九の例と合わせれば、2重ループで数十行など普通にある。
2重ループは普通に使う。例えば九九の表。
内側のループで外側のカウンタを計算に使うから、内側を関数にしてカウンタを引き渡すより分かりやすい。
>>154
ループ内が20行など普通にある。
ちなみに50や100行も普通にある。
例えば、項目の多いプリンタ出力や入力項目チェック、項目の多いDBテーブル検索や登録。
上記九九の例と合わせれば、2重ループで数十行など普通にある。
>>169先生は項目が多くても行数を圧縮できるらしい。すごすぎる
>>170
お前がダメすぎるだけだって
お前がダメすぎるだけだって
・一文字変数禁止
・{ } は省略するな
・条件演算子禁止
この類の教条主義的なコーディングルールって、アレな人にかぎって大好きだよね。
https://github.com/git/git/blob/master/combine-diff.c
http://tools.oesf.biz/android-4.2.0_r1.0/xref/frameworks/base/core/java/android/app/Activity.java
上がgitのコードで下がandroidのコードだけど、世間から評価を受けてるプロダクツを
書いて、実践的にコーディングスタイルを考えてる人たちはそういうのにこだわってないんだよね。
こういう例を見せると「それは上級者向けの書き方で、ヘタクソのいる現場では・・・」みたいな
悲しい言い訳が始まるんだけど、読みやすいコードに上級者向けもヘタクソ向けもないから。
あとこういう言い訳をする人ってそろいもそろって「自分は分かってるよ。でも自分以外のヘタクソが・・・」
みたいな口ぶりなのが余計悲しくなるね。
・{ } は省略するな
・条件演算子禁止
この類の教条主義的なコーディングルールって、アレな人にかぎって大好きだよね。
https://github.com/git/git/blob/master/combine-diff.c
http://tools.oesf.biz/android-4.2.0_r1.0/xref/frameworks/base/core/java/android/app/Activity.java
上がgitのコードで下がandroidのコードだけど、世間から評価を受けてるプロダクツを
書いて、実践的にコーディングスタイルを考えてる人たちはそういうのにこだわってないんだよね。
こういう例を見せると「それは上級者向けの書き方で、ヘタクソのいる現場では・・・」みたいな
悲しい言い訳が始まるんだけど、読みやすいコードに上級者向けもヘタクソ向けもないから。
あとこういう言い訳をする人ってそろいもそろって「自分は分かってるよ。でも自分以外のヘタクソが・・・」
みたいな口ぶりなのが余計悲しくなるね。
自分の主張に合致したソースを引っ張ってきてドヤ顔
まあわからん人にはずっとわからんよ
まあわからん人にはずっとわからんよ
自分の主張に合致したっていうか、一文字変数禁止のほうが少数派なんじゃないの。
{ } 省略禁止は意見が分かれると思うけど。
プログラマの大半が技術的なことに興味薄くて、入門書と職場のコードくらいしか
見たことなくて、ガラパゴス的なコーディングスタイルになってしまってるような
ところくらいだと思う > 一文字変数禁止
{ } 省略禁止は意見が分かれると思うけど。
プログラマの大半が技術的なことに興味薄くて、入門書と職場のコードくらいしか
見たことなくて、ガラパゴス的なコーディングスタイルになってしまってるような
ところくらいだと思う > 一文字変数禁止
NとかFとかmikakaの案件でも一文字変数禁止は見たことないな
コードコンプリート、プログラミング作法、リーダブルコードとか、
ああいうお作法本なんかでも (世間で一定の評価を受けている
ようなのでは)一文字変数禁止とか皆無なんじゃないの。
ああいうお作法本なんかでも (世間で一定の評価を受けている
ようなのでは)一文字変数禁止とか皆無なんじゃないの。
>>167
＞>>154
＞ループ内が20行など普通にある。
＞ちなみに50や100行も普通にある。
＞例えば、項目の多いプリンタ出力や入力項目チェック、項目の多いDBテーブル検索や登録。
＞上記九九の例と合わせれば、2重ループで数十行など普通にある。
書いてることが的外れすぎ
10行程度のループの話してるのに20,50,100行の話が出てくること自体おかしい
行数が多いなら分かりやすい命名すればいいだろ？
＞>>154
＞ループ内が20行など普通にある。
＞ちなみに50や100行も普通にある。
＞例えば、項目の多いプリンタ出力や入力項目チェック、項目の多いDBテーブル検索や登録。
＞上記九九の例と合わせれば、2重ループで数十行など普通にある。
書いてることが的外れすぎ
10行程度のループの話してるのに20,50,100行の話が出てくること自体おかしい
行数が多いなら分かりやすい命名すればいいだろ？
そうすれば？
もしくはループ内行数を倍増させないように改修すれば？
もしくはループ内行数を倍増させないように改修すれば？
俺は最初からi,j,kなんて使わないから
そんな糞みたいな習慣を他人に啓蒙すんな
自信がないから言葉が汚くなるんですね
184 ：仕様書無しさん：2013/03/27(水) 11:46:37.92
糞ではないという反論は無し、と。
2chで相手の表現にケチを付け出したら
それぐらいしか言い返せないぐらい窮してる証だと認識してる
それぐらいしか言い返せないぐらい窮してる証だと認識してる
でもiを検索したことがある奴はいないんだよね
つまりリファクタリングしたことがないってことだよね？
つまりリファクタリングしたことがないってことだよね？
リネームとか検索でやってたら危ないから、IDEのリファクタリングの機能を使うようにな。
リファクタリングが発生する時点でそのプログラムが根本的におかしいことに気付け。
世間のまっとうな人たちは一文字変数を使ってるって時点でもう議論の必要も感じない。
で、iループを別のループで囲うことになったらどうするの？
>>190
他の名前にすれば?
他の名前にすれば?
>>191
jですか？それともhですか？
jですか？それともhですか？
だからメソッド化するなり切り出せよ
なんで多重ループを好んで議題にするんだ
なんで多重ループを好んで議題にするんだ
>>173 のようなコードをガッツリ書いてるような人でも平気で i やら j 使って
二重ループとか書いてるし、なんら問題ないと思うけどね。
コーディングタイルの話で、あんまり細かいところで「こういう書き方でバグを防げる」とか
言って一般的でないスタイルを押す人って、テクニックに走りすぎてると思うわ。
二重ループとか書いてるし、なんら問題ないと思うけどね。
コーディングタイルの話で、あんまり細かいところで「こういう書き方でバグを防げる」とか
言って一般的でないスタイルを押す人って、テクニックに走りすぎてると思うわ。
うちは変数名の先頭にプレフィックスを7文字付けなきゃいけないから関係ない
ループ以前に、１関数の中が100行とかあったら、検収で落とすぞバカ野郎
>>176
それは君がコーディング規約を見ていないだけだろう。mikakaなんて特に厳しい。第一、i_付けろとかだたら、最低でもi_cntとかになる。
それは君がコーディング規約を見ていないだけだろう。mikakaなんて特に厳しい。第一、i_付けろとかだたら、最低でもi_cntとかになる。
>>178
行数が多いなら分かりやすい名前にするなら、何で最初から分かりやすい名前にしない？
行数が多いなら分かりやすい名前にするなら、何で最初から分かりやすい名前にしない？
CUDAやらOpenCLなんかを使ってると、
今でも行列演算をベタにループで書くこともあると思うが、
そんな場合はi, jで良いと思うがなぁ
数式の添字だってそうなんだし
今でも行列演算をベタにループで書くこともあると思うが、
そんな場合はi, jで良いと思うがなぁ
数式の添字だってそうなんだし
久々に見たら糞スレになっててﾜﾛﾀ
>>205
そういう報告はけっこうですから。
そういう報告はけっこうですから。
>>177
ライブラリ提供の物や、フレームワーク等で修正する人か限られている物ならば、ある程度自由にかいてもいいだろう。
また、入門書では学習ポイントが分かりやすいように、変数名をシンプル書く傾向がある。
しかし業務プログラムは違う。
コーディング規約をクリアした上で、他人にも読み易いコードを書く。
プロとしては当然の事だ。
ライブラリ提供の物や、フレームワーク等で修正する人か限られている物ならば、ある程度自由にかいてもいいだろう。
また、入門書では学習ポイントが分かりやすいように、変数名をシンプル書く傾向がある。
しかし業務プログラムは違う。
コーディング規約をクリアした上で、他人にも読み易いコードを書く。
プロとしては当然の事だ。
>>203
いまどき全ソースレビューするのか？バブリーだな。
いまどき全ソースレビューするのか？バブリーだな。
>>207
そこに上げられている本は、初心者用に分かりやすくするために実践から離れたコードを
教えるって趣旨の本じゃないし。
一文字変数禁止がコードの質を上げるか下げるかって話なのに、一文字変数を書かないのが
プロだって反論したって、話をループさせるだけじゃん。
そこに上げられている本は、初心者用に分かりやすくするために実践から離れたコードを
教えるって趣旨の本じゃないし。
一文字変数禁止がコードの質を上げるか下げるかって話なのに、一文字変数を書かないのが
プロだって反論したって、話をループさせるだけじゃん。
selectedItemIndexよりiのほうが読みやすいとか思い込んでるバカは勝手にそうしてたらいいんじゃないかな？
ただ、プロを自称してほしくないけど。本当のプロに迷惑だから。
ただ、プロを自称してほしくないけど。本当のプロに迷惑だから。
>>208
レビューしないところもあるんだ。
レビューしないところもあるんだ。
2chのコーディングスタイルの議論って結局「おれプロだから」ってだけが根拠の人が暴れだして終わっちゃうよね。
> 一文字変数がコードの質を上げるって？どういう理屈だ？
必要もないのに、長ったらしい変数名にすることで
コードの質が下がる。・・・のに比べれば上がるということでしょう？
必要もないのに、長ったらしい変数名にすることで
コードの質が下がる。・・・のに比べれば上がるということでしょう？
218 ：仕様書無しさん：2013/03/27(水) 23:59:32.23
プロ降臨age
結局は算術のように記号化・抽象化するのがいいのか、それとも自然言語に近づけるのがいいのか
という議題になってしまうな。
という議題になってしまうな。
>>215
やってるから言ってんだよ
やってるから言ってんだよ
>>221
ならないだろう、変数名の話だぞ。
ならないだろう、変数名の話だぞ。
>>224
そんな事いわれると、ちょっと切なくなるじゃねーか。
そんな事いわれると、ちょっと切なくなるじゃねーか。
初心者が多いなら一文字を許可したほうがいいだろうな
soeji1, soeji2... とかやりそうw
エディタ批判まで始めたのかw
iを使わなければいいだけなのにw
iを使わなければいいだけなのにw
いや、はっきりさせておこう。
お前のエディタには単語で検索する機能がないのか？
お前のエディタには単語で検索する機能がないのか？
有料ソフトと比べたらいけないのかもしれないけど、
ひでまるには単語で検索機能がついてる
http://www.shuiren.org/chuden/teach/hidemaru/images/15.png
ひでまるには単語で検索機能がついてる
http://www.shuiren.org/chuden/teach/hidemaru/images/15.png
iを検索したことがあるのかって言っていた人は
何が言いたかったんだろうねｗ
普通に検索できるじゃん。
何も困らないじゃん。
何が言いたかったんだろうねｗ
普通に検索できるじゃん。
何も困らないじゃん。
>>235
本当に無いのなら、そのエディタは捨てたほうがいい。
本当に無いのなら、そのエディタは捨てたほうがいい。
238 ：仕様書無しさん：2013/03/28(木) 02:52:10.30
VS2012ってどうなの？
正規表現が使えます
単語で検索できないなら
半角スペース含めて
△i△
で検索したらよいように思える
半角スペース含めて
△i△
で検索したらよいように思える
>>232
使うのは主にEclipse、VisualStudio、mifes、vi、メモ帳。
使うのは主にEclipse、VisualStudio、mifes、vi、メモ帳。
>>237
捨てろってviとメモ帳は捨てようがないが。
捨てろってviとメモ帳は捨てようがないが。
>>238
http://www.atmarkit.co.jp/fdotnet/special/vs2012review/vs2012review_02.html
単語単位って書いてあるな。
IDE含めてプログラマ向けのエディタならある機能だな。
http://www.atmarkit.co.jp/fdotnet/special/vs2012review/vs2012review_02.html
単語単位って書いてあるな。
IDE含めてプログラマ向けのエディタならある機能だな。
>>240
(i)とか[i]を書くときにスペース空けるやついるの？
(i)とか[i]を書くときにスペース空けるやついるの？
>>228
一文字変数つかってないソースって、すごい初心者っぽく見えるわ。
一文字変数つかってないソースって、すごい初心者っぽく見えるわ。
単語単位で検索できないエディタってメモ帳くらいなんじゃないの?
>>244
VB厨
VB厨
まだループカウンタで揉めてるのかよｗｗｗ
いいよ俺iつかうし
いいよ俺iつかうし
i は使用禁止とか言ってるのって、コードを書くのにメモ帳を使ってる連中か．．．
いくら議論したところで最終的に、iは勝つ
いま楽するか、あとで楽するか。それだけの問題。
後から楽できる i のほうが優れてるな。
スレを見ててわかったこと。
一文字変数を使うやつは50代以上のロートルPGで
おそらく現代的なPGに対応できず、ここ数年は
自宅警備員か土木土方をしている。
過去の栄光が忘れられずプログラマ板のレスを読んでは
昔を懐かしみ、古い知識で議論を挑むが現代の高レベルPGには太刀打ちできず
スレを荒らす毎日を過ごしている。
一文字変数を使うやつは50代以上のロートルPGで
おそらく現代的なPGに対応できず、ここ数年は
自宅警備員か土木土方をしている。
過去の栄光が忘れられずプログラマ板のレスを読んでは
昔を懐かしみ、古い知識で議論を挑むが現代の高レベルPGには太刀打ちできず
スレを荒らす毎日を過ごしている。
意味の無い理論をふりかざして可読性の低いコードを書いて
致命的なバグを頻発させてるのは現代的なPGのほうなんですけどねｗ
どっちのほうが社会的に悪影響及ぼしてるかは明白
致命的なバグを頻発させてるのは現代的なPGのほうなんですけどねｗ
どっちのほうが社会的に悪影響及ぼしてるかは明白
一文字変数を一律禁止ってルールの現場って
「こいつらに抽象的なことを言っても理解できなし、ちょっと複雑なルールになると守れないし、
単純に一律禁止がいいだろうな」
みたいにプログラマーがバカにされてるよ。
「こいつらに抽象的なことを言っても理解できなし、ちょっと複雑なルールになると守れないし、
単純に一律禁止がいいだろうな」
みたいにプログラマーがバカにされてるよ。
これ以上一文字ルールについて話したいなら、専用スレ立てろよ。
ここまで来るといい加減スレ違いだ。
ここまで来るといい加減スレ違いだ。
これからコードを書く人に絶対やってほしいこと
＝技術的な宗教論争に参加しない。
どんなに説得しても相手が考えを変えることはないし、
議論すること自体が人生の浪費となる。
＝技術的な宗教論争に参加しない。
どんなに説得しても相手が考えを変えることはないし、
議論すること自体が人生の浪費となる。
ディベートは相手を説得させることが目的じゃないぞｗ
潜在的な課題を掘り下げて広く知ってもらうためにあるんだからな。
潜在的な課題を掘り下げて広く知ってもらうためにあるんだからな。
片方が適当に粘ってるだけで「宗教論争」(どっちもどっち、根拠が無い)みたいに
言い出す人がでてくるよね > 2ch
言い出す人がでてくるよね > 2ch
ii にしたら、単語の一部まで引っかかることはないのに。
単語単位の検索を知らないプログラマーが少なからずいるってのに軽く衝撃を受けてる。
>>254 はギャグかどうか微妙だったけど、マジで透視してるつもりだったのか。
キモ。
キモ。
>>254があたりかどうかは知ったことでないけど、
古い知識や古い常識にとらわれて、最近の開発環境や開発状況を
まるで理解していないことはわかる。
全ソースレビューとか。
intellisenseが当たり前のこの時代、変数を１文字で表現するのは
百害あって一利なし。可読性の面からもrefactorの面からも保守の面からも、
現役のプログラマーにはまったく支持されない。
古い知識や古い常識にとらわれて、最近の開発環境や開発状況を
まるで理解していないことはわかる。
全ソースレビューとか。
intellisenseが当たり前のこの時代、変数を１文字で表現するのは
百害あって一利なし。可読性の面からもrefactorの面からも保守の面からも、
現役のプログラマーにはまったく支持されない。
iって何ですか？
インデックスです。
じゃあindexってちゃんと書けよ。
これが理解できないのは人間のクズ。
インデックスです。
じゃあindexってちゃんと書けよ。
これが理解できないのは人間のクズ。
項目が多くても行数増やさないとか、
後からループを2重に修正しないとか、
コーディング規約無視とか、
一文字変数とか、
これでやってるとすると、高齢のドライバ屋としか思えないな。
後からループを2重に修正しないとか、
コーディング規約無視とか、
一文字変数とか、
これでやってるとすると、高齢のドライバ屋としか思えないな。
iを単語検索できるのはわかるけど
iをリファクタリングするとき
ダブルクリックするの大変じゃないか？
iをリファクタリングするとき
ダブルクリックするの大変じゃないか？
変数にi使いたいやつはi使って長い変数使いたいやつは長い変数使えばいいのになんでそんな簡単なことも思いつかないのか
自分の意見押し付けて楽しい？
自分の意見押し付けて楽しい？
そんなコーディング規約が存在するような
ドカタ仕事してる方が悪いってことだよ
ドカタ仕事してる方が悪いってことだよ
「検索してリファクタリング」とか平気で言い放てるほうが
最近の開発環境や開発状況をまるで理解していない
って感じだよ？
最近の開発環境や開発状況をまるで理解していない
って感じだよ？
>>273
二文字変数使っとけば良かったのでは？
二文字変数使っとけば良かったのでは？
277 ：仕様書無しさん：2013/03/28(木) 20:36:48.16
プロ暴れとるなー
いまどきeclipseなんて使うなよ
>>273
コーディングする前にコーディングルールを知らないってのがよく分からない。
コーディングする前にコーディングルールを知らないってのがよく分からない。
こらこら、今時１文字の変数名なんて使っちゃうような
頭の悪いおじさんに長い変数名なんか強制したら、
日本語ローマ字で変数名つけられちゃうよ。
無能だと割り切って関わらずにクビにするのがいいよ。
頭の悪いおじさんに長い変数名なんか強制したら、
日本語ローマ字で変数名つけられちゃうよ。
無能だと割り切って関わらずにクビにするのがいいよ。
一文字だとミスクリックするってガチのジジイじゃんｗ
>>269
そんなのってそんな頻繁にあるの?
if の条件で定数を左に置くって話のときなんかも、= と ==を間違えたら今どき
警告でるから素直に書けばいいよって言っても、
「警告が出ないコンパイラがあったらどうするんだ！プロなら100年に一回のミスにも備えるんだ」
みたいな無理な話をしだしてたな。
そんなのってそんな頻繁にあるの?
if の条件で定数を左に置くって話のときなんかも、= と ==を間違えたら今どき
警告でるから素直に書けばいいよって言っても、
「警告が出ないコンパイラがあったらどうするんだ！プロなら100年に一回のミスにも備えるんだ」
みたいな無理な話をしだしてたな。
>>281
世界的に広く成果が認められている人が書いてるコードも、平気で一文字や二文字の変数を使ってるしな。
2chの自称プロとか若者とか頭のいいプログラマより、実際成果を出してる人のスタイルのほうを信頼するわ。
世界的に広く成果が認められている人が書いてるコードも、平気で一文字や二文字の変数を使ってるしな。
2chの自称プロとか若者とか頭のいいプログラマより、実際成果を出してる人のスタイルのほうを信頼するわ。
>>284
ダブルクリック?
ダブルクリック?
>>284
いや皆があんたみたいな年寄りな訳じゃないからｗ
いや皆があんたみたいな年寄りな訳じゃないからｗ
一文字変数が駄目な理由に「クリックしにくいから」って新しいな。
つか結構マウス使うのな
マウスあんまり使わんわ
マウスあんまり使わんわ
291 ：仕様書無しさん：2013/03/28(木) 21:14:59.20
トラックボールってどうなの
>>290
タッチパッドか？さらに厳しくなると思うが…
タッチパッドか？さらに厳しくなると思うが…
キーボードを１回叩けばいいだけの話なのに、
なぜわざわざマウスを細かく操作して苦労せにゃならんの？
これが自称今時のプロなのかw
なぜわざわざマウスを細かく操作して苦労せにゃならんの？
これが自称今時のプロなのかw
もうそろそろ、空気読んでない奴が
グローバル変数に変数名一文字を使うのかよっていいそうだな。
変数名iというのはループ変数。
ローカルよりもさらにスコープも小さいブロックスコープで
なおかつコードの量が少ない時のみOKという話。
あとでコードが長くなったどうするんだ？と言っている奴は理解できん。
ループ変数にかぎらず、コードが長くなったら分割するだろ？修正するだろ。
長くなったら修正すればいいだけ。
動いているコードは修正してはいけないという間違った考えが広まった結果
修正の必要があるのに、いかに既存のコードを修正せずに、コードの追加だけを
行なって修正するというアクロバティックな開発をしているバカが居る。
長くなった時に困る奴はそのたぐいなのか？
グローバル変数に変数名一文字を使うのかよっていいそうだな。
変数名iというのはループ変数。
ローカルよりもさらにスコープも小さいブロックスコープで
なおかつコードの量が少ない時のみOKという話。
あとでコードが長くなったどうするんだ？と言っている奴は理解できん。
ループ変数にかぎらず、コードが長くなったら分割するだろ？修正するだろ。
長くなったら修正すればいいだけ。
動いているコードは修正してはいけないという間違った考えが広まった結果
修正の必要があるのに、いかに既存のコードを修正せずに、コードの追加だけを
行なって修正するというアクロバティックな開発をしているバカが居る。
長くなった時に困る奴はそのたぐいなのか？
マウス使うにしても
対象変数の大体の位置をクリック
万が一ズレてたらキー操作で補正
ショートカットキーでリファクタリング開始
だろ？
いちいちマウスで変数全体を選択して右クリックからメニュー呼び出しとかで実行してるならマジでイミフ
対象変数の大体の位置をクリック
万が一ズレてたらキー操作で補正
ショートカットキーでリファクタリング開始
だろ？
いちいちマウスで変数全体を選択して右クリックからメニュー呼び出しとかで実行してるならマジでイミフ
というか、可変ピッチフォントでコード書きするなよ。
大体名前変更だろ？ その他のリファクタリングならともなく、
名前を変更したいと思った時＝その名前を目にした時＝画面に変数が表示されている
だよな？
その文字を修正する感覚でカーソル持っていって
変数名を変えれば、その他も全て変わるじゃんか。
俺ってそんなに特殊なIDE使ってるか？
名前を変更したいと思った時＝その名前を目にした時＝画面に変数が表示されている
だよな？
その文字を修正する感覚でカーソル持っていって
変数名を変えれば、その他も全て変わるじゃんか。
俺ってそんなに特殊なIDE使ってるか？
一文字一時変数拒否派はまさか変数名リファクタリングもまともにできないほどに目が悪くなったオッサンだったわけ？
容認派にあんなレッテル貼っといて。
つか、操作に無駄ありすぎだろ。だから変数名の長さとか変なこだわりが出来るんじゃね。
とどのつまり拒否している理由が「選択しにくい」とかでオシマイだったらマジで引くわ。
ここまでオレには理解できない超一流のギャグなんだよな？
容認派にあんなレッテル貼っといて。
つか、操作に無駄ありすぎだろ。だから変数名の長さとか変なこだわりが出来るんじゃね。
とどのつまり拒否している理由が「選択しにくい」とかでオシマイだったらマジで引くわ。
ここまでオレには理解できない超一流のギャグなんだよな？
短いコードの中で一文字変数を使うのが
ダメな理由って全部否定されていたよね？
コレ以上何を争う必要があるの？
ダメな理由って全部否定されていたよね？
コレ以上何を争う必要があるの？
ダメなコードは修正するという文化がないところは
今もダメなコードを生成し続けている。
全く成長していない。
今もダメなコードを生成し続けている。
全く成長していない。
他人が書いたコードは修正しなくていいのですか？
書いた人がやめたらどうするんですか？
新しい人は全員新規コード書くんですか？
面白い会社ですねｗ
書いた人がやめたらどうするんですか？
新しい人は全員新規コード書くんですか？
面白い会社ですねｗ
こういう所から
仕事してないんだなぁ臭が
だだ漏れて来るんだよなｗ
仕事してないんだなぁ臭が
だだ漏れて来るんだよなｗ
>>307
つか、それ以前に、書きはじめる前にコーディングルール読まないの?
つか、それ以前に、書きはじめる前にコーディングルール読まないの?
悪いコーディング規約もあるんで、
規約がどうとかいうのは、話す価値ないよ。
今はいいかどうか話してるだけ。
短いコードなら短い変数名で構わないという
ことで話は続行ｗ
規約がどうとかいうのは、話す価値ないよ。
今はいいかどうか話してるだけ。
短いコードなら短い変数名で構わないという
ことで話は続行ｗ
コーディングルールでしかたなく一文字変数使えないって話ならだれもルール無視してわが道を突っ走れとか言わない。
お仕事がんばってね。
お仕事がんばってね。
>294
まぁ同意できるところもあるが
ループ変数はプロトタイプ時は1文字で書きなぐる
その後リファクタリングで3文字程度に置換する
コードはバージョン管理されているのが当たり前なので
要らない部分はコメントアウトなどで残さず、ロジックからきれいに書き直す
既存のコード？知るかよ
年とった人は何故かコメントアウトにして残したがるが、糞ロジックに糞コードが残っていて
それを修正しろとか言いやがる
もうね、馬鹿かと
書き直した方が今後の保守で楽できますよと言っても、動いているからそれに追加修正で済ませろ
新規で作った工数は計上できない、テストは最小限にしたいと
もうね、馬鹿かと
糞コードは読んでも頭の中で流れねぇんだよ、脳内デバッグ不可能なんだよ
まぁ同意できるところもあるが
ループ変数はプロトタイプ時は1文字で書きなぐる
その後リファクタリングで3文字程度に置換する
コードはバージョン管理されているのが当たり前なので
要らない部分はコメントアウトなどで残さず、ロジックからきれいに書き直す
既存のコード？知るかよ
年とった人は何故かコメントアウトにして残したがるが、糞ロジックに糞コードが残っていて
それを修正しろとか言いやがる
もうね、馬鹿かと
書き直した方が今後の保守で楽できますよと言っても、動いているからそれに追加修正で済ませろ
新規で作った工数は計上できない、テストは最小限にしたいと
もうね、馬鹿かと
糞コードは読んでも頭の中で流れねぇんだよ、脳内デバッグ不可能なんだよ
>>308
大手のレガシーCのコーディング規約の殆どが、変数名の先頭にi_などの識別を付けるのを知ってるよな？
大手のレガシーCのコーディング規約の殆どが、変数名の先頭にi_などの識別を付けるのを知ってるよな？
一文字変数否定派は、規約でしかたなくそうなのか、自分でそれが有効だと思ってるのか立場をはっきりさせろよ。
>>317
一文字を使う利点はない。
一文字を使う利点はない。
みなさんはプロトタイプとか書き捨てコードとか書かないの
そういう時でも、変数名をいちいち付けてるの
もうね、馬鹿かと
まず、動くの作れや
それから改良していけばええやん
いちいち規約がどうだこうだ言ってる奴に限って、糞ロジックなコードを完成させている
シンプルに作れやシンプルに
Simple is best!
そういう時でも、変数名をいちいち付けてるの
もうね、馬鹿かと
まず、動くの作れや
それから改良していけばええやん
いちいち規約がどうだこうだ言ってる奴に限って、糞ロジックなコードを完成させている
シンプルに作れやシンプルに
Simple is best!
大手はみんな i なんか使わないって言われても、どこまで一般的な話か確認しようがないしな。
コーディングルールに関しては、ローカルな規約とか個人的な意見とかはあんまり興味ないし。
ネットで確認できる範囲の有名プロダクツは、だいたいふつーに一文字変数を使ってるし、
そういうのを書いてる人は、ソースの読みやすさとか保守性に関してはそこらへんのドカタなんか
よりはるかに見識あるだろうし、一文字変数を使うのが普通だろうね。
コーディングルールに関しては、ローカルな規約とか個人的な意見とかはあんまり興味ないし。
ネットで確認できる範囲の有名プロダクツは、だいたいふつーに一文字変数を使ってるし、
そういうのを書いてる人は、ソースの読みやすさとか保守性に関してはそこらへんのドカタなんか
よりはるかに見識あるだろうし、一文字変数を使うのが普通だろうね。
最初からまともっていう考えをしている人は、
コードっていうのは常に変わってくということを知らないのか？
要求は変わるし、間違いするし、スキルも上がる。
最初からまともという考えだと、成長できないぞ。
最初から不可能な完ぺきを求めるのではなく、
成長していくためにはどうするかを考えるべきだ。
コードっていうのは常に変わってくということを知らないのか？
要求は変わるし、間違いするし、スキルも上がる。
最初からまともという考えだと、成長できないぞ。
最初から不可能な完ぺきを求めるのではなく、
成長していくためにはどうするかを考えるべきだ。
一文字変数で、リリースさてるだろ
有名プロダクツ
有名プロダクツ
一文字の変数を二文字や三文字にしたって、上の一文字だとクリックできないみたいな
人くらいにしかメリットないね。
フルスペルの単語を二つとか三つつなげてインデックスにして、読みやすくなるって思ってる人は
ろくにコードを書いたことがないんだろ。
人くらいにしかメリットないね。
フルスペルの単語を二つとか三つつなげてインデックスにして、読みやすくなるって思ってる人は
ろくにコードを書いたことがないんだろ。
>>324
改良する時間は貰うんじゃない。
開発時間に入れるんだよ。
どうせ汚いコードを頑張って理解して
そしてまた忘れて、また汚いコードを読みなおすのも
汚いコードを綺麗にして、将来も含めて
読みやすくするのも
大して時間は変わらん。
改良する時間は貰うんじゃない。
開発時間に入れるんだよ。
どうせ汚いコードを頑張って理解して
そしてまた忘れて、また汚いコードを読みなおすのも
汚いコードを綺麗にして、将来も含めて
読みやすくするのも
大して時間は変わらん。
ましてや変数名の変更なんて
間違いが起こる可能性も殆ど無い
簡単な作業だしな。
間違いが起こる可能性も殆ど無い
簡単な作業だしな。
>324
普通の人より作るのも書くのも早いから割りと時間がとれるんだよ
リファクタリングですと言って直すときもあるし
最近のIDEなら正規表現で置換とか変数名の変更するもの数秒で終わるし何ら問題にならない
タイプするのが面倒で、タイプするとタイポする可能性があるので、IDEに補間してもらってるし
どうせ後から仕様変更くるのに、厳密に名前付けてられっかよ
普通の人より作るのも書くのも早いから割りと時間がとれるんだよ
リファクタリングですと言って直すときもあるし
最近のIDEなら正規表現で置換とか変数名の変更するもの数秒で終わるし何ら問題にならない
タイプするのが面倒で、タイプするとタイポする可能性があるので、IDEに補間してもらってるし
どうせ後から仕様変更くるのに、厳密に名前付けてられっかよ
坊やだからさ
>>322
だから、さわる人が限られるライブラリやフレームワークは、その人の趣味になる事が多いんだよ。
あんなのは作った本人が直すんだから。
逆に趣味丸出しで見にくくして、他の人に直せなくするぐらいだ。
だから、さわる人が限られるライブラリやフレームワークは、その人の趣味になる事が多いんだよ。
あんなのは作った本人が直すんだから。
逆に趣味丸出しで見にくくして、他の人に直せなくするぐらいだ。
>>327
一文字変数がダメって人は、自分の職場のソースしか見たことないのかね。
世間的に評価の高いプロダクツのソースで一文字変数が使われてるのを見て「きたねーソースだな」とか
思ってたらすごい自信だよね。
一文字変数がダメって人は、自分の職場のソースしか見たことないのかね。
世間的に評価の高いプロダクツのソースで一文字変数が使われてるのを見て「きたねーソースだな」とか
思ってたらすごい自信だよね。
>>333
> だから、さわる人が限られるライブラリやフレームワークは、その人の趣味になる事が多いんだよ。
それはクローズド限定だね。
オープンソースのライブラリやフレームワークは
さわる人に限りがない。
> だから、さわる人が限られるライブラリやフレームワークは、その人の趣味になる事が多いんだよ。
それはクローズド限定だね。
オープンソースのライブラリやフレームワークは
さわる人に限りがない。
>>333
大人数で保守されていて、限られた人間しか見ないとか趣味的にやってるわけじゃないよ。
大人数で保守されていて、限られた人間しか見ないとか趣味的にやってるわけじゃないよ。
>>337
お前は何一つ見てないくせにｗ
お前は何一つ見てないくせにｗ
>>325
はあ？趣味ならそれでいいけど仕事でそれはねえよ
一つ一つ完成品を作っていかなければ終わらない
仕様変更を受ける受けないはまた別の話
>>329
なんで最初から綺麗に書かないの？
同じ工程に二度も三度も手をかけてそれでプロと言えるのか？
はあ？趣味ならそれでいいけど仕事でそれはねえよ
一つ一つ完成品を作っていかなければ終わらない
仕様変更を受ける受けないはまた別の話
>>329
なんで最初から綺麗に書かないの？
同じ工程に二度も三度も手をかけてそれでプロと言えるのか？
客観的な判断がなにもないのもいかんので
”一文字変数が使われてない” という証拠を得るため
githubのTrending Reposのコードをいくつか見てみたよ。
結論？ 一文字変数みんなつかっていたさ。
畜生め。
”一文字変数が使われてない” という証拠を得るため
githubのTrending Reposのコードをいくつか見てみたよ。
結論？ 一文字変数みんなつかっていたさ。
畜生め。
>>340
アイデア勝負みたいな作品じゃなくて、安定性とか保守性が評価されてるようなのね。
アイデア勝負みたいな作品じゃなくて、安定性とか保守性が評価されてるようなのね。
一文字だと汚いっていうのが
そもそも間違いなんだよなぁ。
そもそも間違いなんだよなぁ。
絵を描く時最初っから綺麗に書けばいいのに
小説書くとき最初っから綺麗に書けばいいのに。
みたいなもんだよなぁ。
小説書くとき最初っから綺麗に書けばいいのに。
みたいなもんだよなぁ。
>>342
パフォーマンスみたいな議論なら、ベンチマークでもとれば一発だけど
コーディングスタイルは、生産性とか保守性とか数字にして評価しにくいからね。
(IBMみたいなところはやってるけど)
結局、成果を出してる人やら組織を参考にするのが一番だな。
「俺はプロだから」とか「現場を知ってる」みたいのが根拠の話はもういいわって感じ。
たとえば富士通の何とかって大プロジェクトではこうだったとか、そういう話なら
いろいろ聞いてみたいけど、そういう具体的は話は絶対でないしな。
パフォーマンスみたいな議論なら、ベンチマークでもとれば一発だけど
コーディングスタイルは、生産性とか保守性とか数字にして評価しにくいからね。
(IBMみたいなところはやってるけど)
結局、成果を出してる人やら組織を参考にするのが一番だな。
「俺はプロだから」とか「現場を知ってる」みたいのが根拠の話はもういいわって感じ。
たとえば富士通の何とかって大プロジェクトではこうだったとか、そういう話なら
いろいろ聞いてみたいけど、そういう具体的は話は絶対でないしな。
1文字変数ってFortranとかBasicとかメモリの制約が厳しかった時代のメモリ節約テクなんでしょ。
そんな応急処置的なテクニックを現代まで引きずる必要は全くないと思うんだけど。
そんな応急処置的なテクニックを現代まで引きずる必要は全くないと思うんだけど。
コンパイラで変数名を短くしてもメモリの節約にはならないし、一文字変数を使ってる人はそんなことくらい分かってると思うよ。
誰もメモリ節約という理由で一文字変数使ってねーよｗ
スコープが小さく、大層な名前をつけるまでもない場合に
つけてるだけ。ほんの数回使うだけの一時的な変数に
長い名前使って何の意味があるんだ？
スコープが小さく、大層な名前をつけるまでもない場合に
つけてるだけ。ほんの数回使うだけの一時的な変数に
長い名前使って何の意味があるんだ？
>>350
ちなみに行が増えたら振りなおすんだっけ？本気で言ってんの？
ちなみに行が増えたら振りなおすんだっけ？本気で言ってんの？
>>251
行増やす以上に大変な作業なのか？
行増やす以上に大変な作業なのか？
行増やすときに一緒に変えればいいだけ。
あとで変えるならなぜ最初から変えなくていい名前にしないのか理解できん
あとで変えるかどうかわからん場合の話だろｗ
未来なんて誰にもわからんよ。
だからわからん未来の為に冗長な名前をつける必要はない。
コードが短いのだから、短い変数名で良い。
未来なんて誰にもわからんよ。
だからわからん未来の為に冗長な名前をつける必要はない。
コードが短いのだから、短い変数名で良い。
その基準でいいならループ以外の変数もaとかzとかでいいよな？
だから別スレ立ててそっちでやれよ
>>278
リファクタ使えよ…
リファクタ使えよ…
一文字の変数名はOKといったが
変な名前を許可するなんて言ってないからなぁ。
例えばPerlではソートの時の比較関数で
変数名aとbに値が代入される。
zは三次元座標の変数として使われる。
変な名前を許可するなんて言ってないからなぁ。
例えばPerlではソートの時の比較関数で
変数名aとbに値が代入される。
zは三次元座標の変数として使われる。
変数に正しい名前を与えるのが難しい場合もあるからな。
そういう時は、時間をかけて悩んで、結果中途半端な名前にするより
狭いスコープに区切って、サクっと一文字変数にした方が分かりやすくなる事も多い。
そういう時は、時間をかけて悩んで、結果中途半端な名前にするより
狭いスコープに区切って、サクっと一文字変数にした方が分かりやすくなる事も多い。
ループカウンタにiを使う話してんのにすり替えてるやつがいるな
そもそもスレに則ってるのかどうかも怪しいが…
絶対にやって欲しくない重要な問題ってことだよな！
絶対にやって欲しくない重要な問題ってことだよな！
こういうくだらない宗教論争に加わってはダメだということだけはよくわかっただろう？
>>363
ループカウンタがiの人も、長くなったら振りなおすのか？
ループカウンタがiの人も、長くなったら振りなおすのか？
だから長くしないってば
>>368
では君の会社では、OSSソースを理解できる人と、業務ソース理解できる人はどちらが多い？
では君の会社では、OSSソースを理解できる人と、業務ソース理解できる人はどちらが多い？
>>316
私は i_i, i_j, i_k をループカウンタにしてます
私は i_i, i_j, i_k をループカウンタにしてます
もうそれindex1,index2,index3でいいだろw
記号を挟むとダブルクリックで選択できないエディタが云々
>>371
ループ変数は1文字じゃないと可読性が落ちます！ゲラ
ループ変数は1文字じゃないと可読性が落ちます！ゲラ
>>370
それじゃ、仕方ない。
それじゃ、仕方ない。
>>370
俺はiii jjj kkk
俺はiii jjj kkk
変数名にハイフンｗｗｗ
コードが短い所に、短い変数名をつけても
可読性もメンテナンス性も悪くならない。
なんせコードが短いんだからね。
長くなった時の書き換えも大変ではない。
なぜならコードが短いのだから。
修正してから、長くすればいいだけ。
可読性もメンテナンス性も悪くならない。
なんせコードが短いんだからね。
長くなった時の書き換えも大変ではない。
なぜならコードが短いのだから。
修正してから、長くすればいいだけ。
>>373
配列の添え字にindex1とか使われるとソースがぐちゃっとした感じになって読みにくいね。
int BubSort(int x[], int n)
{
int index1, index2, temporary;
for (index1 = 0; index1 < n - 1; index1++) {
for (index2 = n - 1; index2 > index1; index2--) {
if (x[index2 - 1] > x[index2]) {
temporary = x[index2];
x[index2] = x[index2 - 1];
x[index2 - 1]= temporary;
}
}
}
}
配列の添え字にindex1とか使われるとソースがぐちゃっとした感じになって読みにくいね。
int BubSort(int x[], int n)
{
int index1, index2, temporary;
for (index1 = 0; index1 < n - 1; index1++) {
for (index2 = n - 1; index2 > index1; index2--) {
if (x[index2 - 1] > x[index2]) {
temporary = x[index2];
x[index2] = x[index2 - 1];
x[index2 - 1]= temporary;
}
}
}
}
スコープの広さに応じて
変数名の長短もコントロールすると
コードにメリハリが付いて読み易くなるよ！
変数名の長短もコントロールすると
コードにメリハリが付いて読み易くなるよ！
>>379
それはおまえが無能だから
それはおまえが無能だから
煽ったら答えをもらえるのは小学生までです。
答えを出せないという方向が
正解ということもあるのです。
正解ということもあるのです。
ここのスレの人、『C#ショートコードプログラミング』とか読んでそうだなｗ
やっぱり逃走か。所詮一文字禁止を主張するキチガイなんぞ
こんなもんだよ。
こんなもんだよ。
代案も何も、一文字変数に反対してる人たちって>>379が読みやすいって感性なんでしょ?
そもそもアルゴリズムからして超初心者級じゃね？
>>393
よけいゴチャゴチャ度が増したような気が
int BubSort(int sortTable[], int tableLength)
{
int index1, index2, temporary;
for (index1 = 0; index1 < tableLength - 1; index1++) {
for (index2 = n - 1; index2 > index1; index2--) {
if (sortTable[index2 - 1] > sortTable[index2]) {
temporary = sortTable[index1];
sortTable[index2] = sortTable[index2 - 1];
sortTable[index1 - 1]= temporary;
}
}
}
}
よけいゴチャゴチャ度が増したような気が
int BubSort(int sortTable[], int tableLength)
{
int index1, index2, temporary;
for (index1 = 0; index1 < tableLength - 1; index1++) {
for (index2 = n - 1; index2 > index1; index2--) {
if (sortTable[index2 - 1] > sortTable[index2]) {
temporary = sortTable[index1];
sortTable[index2] = sortTable[index2 - 1];
sortTable[index1 - 1]= temporary;
}
}
}
}
一文字反対派は、こんな10数行程度のコードでも、バーンと「こう書けば読みやすいだろ」とか出せないんだね。
こうか。
int BubSort(int sortTable[], int tableLength)
{
int index1, index2, temporary;
for (index1 = 0; index1 < tableLength - 1; index1++) {
for (index2 = tableLength - 1; index2 > index1; index2--) {
if (sortTable[index2 - 1] > sortTable[index2]) {
temporary = sortTable[index2];
sortTable[index2] = sortTable[index2 - 1];
sortTable[index2 - 1]= temporary;
}
}
}
}
int BubSort(int sortTable[], int tableLength)
{
int index1, index2, temporary;
for (index1 = 0; index1 < tableLength - 1; index1++) {
for (index2 = tableLength - 1; index2 > index1; index2--) {
if (sortTable[index2 - 1] > sortTable[index2]) {
temporary = sortTable[index2];
sortTable[index2] = sortTable[index2 - 1];
sortTable[index2 - 1]= temporary;
}
}
}
}
>>387
テトリスのコードを短く書く人の本？
テトリスのコードを短く書く人の本？
class CSVParser {
static void Main() {
TextFieldParser p = new TextFieldParser("text.csv",
System.Text.Encoding.GetEncoding("Shift_JIS"));
using (p) {
p.TextFieldType = FieldType.Delimited;
p.SetDelimiters(","); // 区切り文字はコンマ
while (!p.EndOfData) {
string[] r = p.ReadFields(); // 1行読み込み
foreach (string f in r) {
string s = f;
s = s.Replace("\r\n", "n"); // 改行をnで表示
s = s.Replace(" ", "_"); // 空白を_で表示
Console.Write(s + "\t"); // TAB区切りで出力
}
Console.WriteLine();
}
}
}
static void Main() {
TextFieldParser p = new TextFieldParser("text.csv",
System.Text.Encoding.GetEncoding("Shift_JIS"));
using (p) {
p.TextFieldType = FieldType.Delimited;
p.SetDelimiters(","); // 区切り文字はコンマ
while (!p.EndOfData) {
string[] r = p.ReadFields(); // 1行読み込み
foreach (string f in r) {
string s = f;
s = s.Replace("\r\n", "n"); // 改行をnで表示
s = s.Replace(" ", "_"); // 空白を_で表示
Console.Write(s + "\t"); // TAB区切りで出力
}
Console.WriteLine();
}
}
}
一文字変数バージョン
int BubSort(int table[ ], int n)
{
int i, j, temp;
for (i = 0; i < n - 1; i++) {
for (j = n - 1; j > i; j--) {
if (table[j - 1] > table[j]) {
temp = table[j];
table[j] = table[j - 1];
table[j - 1]= temp;
}
}
}
}
int BubSort(int table[ ], int n)
{
int i, j, temp;
for (i = 0; i < n - 1; i++) {
for (j = n - 1; j > i; j--) {
if (table[j - 1] > table[j]) {
temp = table[j];
table[j] = table[j - 1];
table[j - 1]= temp;
}
}
}
}
public static void GetAlla(
string f, string p, ref ArrayList a)
{
//fにあるファイルを取得する
string[] s =
System.IO.Directory.Geta(f, p);
//ArrayListに追加する
a.AddRange(s);
//fのサブフォルダを取得する
string[] d = System.IO.Directory.GetDirectories(f);
//サブフォルダにあるファイルも調べる
foreach (string d in d)
GetAlla(d, p, ref a);
}
string f, string p, ref ArrayList a)
{
//fにあるファイルを取得する
string[] s =
System.IO.Directory.Geta(f, p);
//ArrayListに追加する
a.AddRange(s);
//fのサブフォルダを取得する
string[] d = System.IO.Directory.GetDirectories(f);
//サブフォルダにあるファイルも調べる
foreach (string d in d)
GetAlla(d, p, ref a);
}
>>399
一文字をフルスペルに直したバージョン
class CSVParser {
static void Main() {
TextFieldParser textFieldParser = new TextFieldParser("text.csv",
System.Text.Encoding.GetEncoding("Shift_JIS"));
using (textFieldParser) {
textFieldParser.TextFieldType = FieldType.Delimited;
textFieldParser.SetDelimiters(","); // 区切り文字はコンマ
while (!textFieldParser.EndOfData) {
string[] lineInfields = textFieldParser.ReadFields(); // 1行読み込み
foreach (string f in lineInfields) {
string field = f;
field = field.Replace("\r\n", "n"); // 改行をnで表示
field = field.Replace(" ", "_"); // 空白を_で表示
Console.Write(field + "\t"); // TAB区切りで出力
}
Console.WriteLine();
}
}
}
一文字をフルスペルに直したバージョン
class CSVParser {
static void Main() {
TextFieldParser textFieldParser = new TextFieldParser("text.csv",
System.Text.Encoding.GetEncoding("Shift_JIS"));
using (textFieldParser) {
textFieldParser.TextFieldType = FieldType.Delimited;
textFieldParser.SetDelimiters(","); // 区切り文字はコンマ
while (!textFieldParser.EndOfData) {
string[] lineInfields = textFieldParser.ReadFields(); // 1行読み込み
foreach (string f in lineInfields) {
string field = f;
field = field.Replace("\r\n", "n"); // 改行をnで表示
field = field.Replace(" ", "_"); // 空白を_で表示
Console.Write(field + "\t"); // TAB区切りで出力
}
Console.WriteLine();
}
}
}
ループカウンタ ｉ はやるけど
引数1文字はやらんなあ
引数1文字はやらんなあ
>>380
メリハリかぁ、それだ！
This is a pen. というのを、
this .... pen とアクセント付けて発音するか、
荒井注さんのギャグのように「ディスイズアペーン」と発音するか、
みたいな。
メリハリかぁ、それだ！
This is a pen. というのを、
this .... pen とアクセント付けて発音するか、
荒井注さんのギャグのように「ディスイズアペーン」と発音するか、
みたいな。
>>400 のテンポラリのスコープを制限したバージョン。
int BubSort(int table[ ], int len)
{
int i, j;
for (i = 0; i < len - 1; i++) {
for (j = len - 1; j > i; j--) {
if (table[j - 1] > table[j]) {
int t = table[j];
table[j] = table[j - 1];
table[j - 1]= t;
}
}
}
}
int BubSort(int table[ ], int len)
{
int i, j;
for (i = 0; i < len - 1; i++) {
for (j = len - 1; j > i; j--) {
if (table[j - 1] > table[j]) {
int t = table[j];
table[j] = table[j - 1];
table[j - 1]= t;
}
}
}
}
一文字変数別につこうていいよ派の僕ならこう書くだろうな
ファイルスコープによって関数の命名が先頭大文字か小文字で変わる
extern
int *BubbleSortForInteger(int *items, int length)
{
int i;
for ( i = 0; i < length - 1; ++i ) {
int j;
for ( j = length - 1; j > i; ++j ) {
if ( items[j-1] > items[j] ) {
int temp = items[j];
items[j] = items[j-1];
items[j-1]= temp;
}
}
}
return items;
}
インデントはタブ(4)でするけどね
始めから汎用的に作れよ糞が
ファイルスコープによって関数の命名が先頭大文字か小文字で変わる
extern
int *BubbleSortForInteger(int *items, int length)
{
int i;
for ( i = 0; i < length - 1; ++i ) {
int j;
for ( j = length - 1; j > i; ++j ) {
if ( items[j-1] > items[j] ) {
int temp = items[j];
items[j] = items[j-1];
items[j-1]= temp;
}
}
}
return items;
}
インデントはタブ(4)でするけどね
始めから汎用的に作れよ糞が
foreach (string f in lineInfields) {
string field = f;
field = field.Replace("\r\n", "n"); // 改行をnで表示
field = field.Replace(" ", "_"); // 空白を_で表示
Console.Write(field + "\t"); // TAB区切りで出力
}
ここら辺が糞冗長過ぎて腹が立つんですけど、これに切れられない奴はセンスが無いと思うな
string field = f;
field = field.Replace("\r\n", "n"); // 改行をnで表示
field = field.Replace(" ", "_"); // 空白を_で表示
Console.Write(field + "\t"); // TAB区切りで出力
}
ここら辺が糞冗長過ぎて腹が立つんですけど、これに切れられない奴はセンスが無いと思うな
また宗教論争ネタで申し訳ないけど、タブは8固定な。
インデントを8以外でしたいときはスペースで。
タブを8以外に設定して、インデントに使うのは許さん。
インデントを8以外でしたいときはスペースで。
タブを8以外に設定して、インデントに使うのは許さん。
414 ：仕様書無しさん：2013/03/29(金) 23:26:01.37
具体例あげられない宗教の人がいるらしい
ForIntegerとかｗ
比較代入部分をラムダにすればそんな制限なくなるだろｗ
比較代入部分をラムダにすればそんな制限なくなるだろｗ
Tab4だろJK
>>403
これは例だからあれだけど
> TextFieldParser textFieldParser = new TextFieldParser("text.csv",
こういう型名と同じような無意味な変数名つけるくらいなら
スコープ狭くして一文字の方がましだと思うぞ。
これは例だからあれだけど
> TextFieldParser textFieldParser = new TextFieldParser("text.csv",
こういう型名と同じような無意味な変数名つけるくらいなら
スコープ狭くして一文字の方がましだと思うぞ。
全角スペースでインデントしてるやつらが、4tabだ8tabだとかｗｗｗ
2chに書いてるんだから仕方ねえだろ
そこに突っ込むとかお前はアホか
つーかコード例投下してないのが丸わかりでﾜﾛﾀ
そこに突っ込むとかお前はアホか
つーかコード例投下してないのが丸わかりでﾜﾛﾀ
>>403
荒らしのコピペと誤解されスルー
荒らしのコピペと誤解されスルー
ループカウンタ名にjs、jc、jkを使いたいんだけど・・・
jsをまわ気か
>415 つまりこういうことですね、分かります。ひさしぶりにC言語系書いたので、コンパイル通るか不明
extern
int BubbleSort(void *items, size_t length, size_t size, int (*comparer)(const void *, const void *))
{
size_t i;
if ( items == NULL ) {
return -2;
}
if ( comparer = (int (*)(const void *, const void *))0) {
return -4;
}
for ( i = 0; i < length - 1; ++i ) {
size_t j;
for ( j = length - 1; j > i; ++j ) {
if ( comparer(items[j-1], items[j]) > 0 ) {
swapBytes((char *)items + size*(j-1), (char *)items + size*j);
}
}
}
return items;
}
/* ほんとはこんなに、ぎゅうぎゅうにしないけど行数制限が */
static void swapBytes(void *p, void *q size_t size) {
size_t i;
char *s = (char *)p;
char *t = (char *)q;
for ( i = 0; i < size; ++i ) {
char u = *s; *s = *t, *t = u;
}
}
extern
int BubbleSort(void *items, size_t length, size_t size, int (*comparer)(const void *, const void *))
{
size_t i;
if ( items == NULL ) {
return -2;
}
if ( comparer = (int (*)(const void *, const void *))0) {
return -4;
}
for ( i = 0; i < length - 1; ++i ) {
size_t j;
for ( j = length - 1; j > i; ++j ) {
if ( comparer(items[j-1], items[j]) > 0 ) {
swapBytes((char *)items + size*(j-1), (char *)items + size*j);
}
}
}
return items;
}
/* ほんとはこんなに、ぎゅうぎゅうにしないけど行数制限が */
static void swapBytes(void *p, void *q size_t size) {
size_t i;
char *s = (char *)p;
char *t = (char *)q;
for ( i = 0; i < size; ++i ) {
char u = *s; *s = *t, *t = u;
}
}
おっとitemsを返しているじゃないかreturn 0;だなあっこは
一文字の無意味な変数名ではなく
一文字で意味を表す変数名なのだから
一文字であっても適切な名前なんだがね。
一文字で意味を表す変数名なのだから
一文字であっても適切な名前なんだがね。
今度は型やプロトタイプの引数を書く派と書かない派の宗教論争か。
430 ：仕様書無しさん：2013/03/30(土) 00:02:25.14
参考になるわぁ
プロトタイプなんて1レスも話題には上がってないが･･･
あー、うんOracleのコーディング規約ね。
それもいい証拠になる。
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#547
例えばこれ、一文字の変数名を使っている
それもいい証拠になる。
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#547
例えばこれ、一文字の変数名を使っている
>>432
フォントサイズや解像度は関係ないだろ。
フォントサイズや解像度は関係ないだろ。
この文書は、Scott W. Ambler氏によって記述された
Writing Robust Java Code - The AmbySoft Inc. Coding Standards for Java v17.01d(2000.1.15)を
訳出したものです。Writing Robust Java Codeは、Java言語のコーディングに関する標準、指針をまとめた文書です。
http://www.alles.or.jp/~torutk/oojava/codingStandard/writingrobustjavacode_pidid93_c4.html#doc1_id1036
> ループカウンタは非常によく使われるローカル変数であり、C/C++でもよく使われたので、
> Javaでもi, j, kといった命名をループカウンタに使用してもよい(Gosling,Joy,Steele)。
Writing Robust Java Code - The AmbySoft Inc. Coding Standards for Java v17.01d(2000.1.15)を
訳出したものです。Writing Robust Java Codeは、Java言語のコーディングに関する標準、指針をまとめた文書です。
http://www.alles.or.jp/~torutk/oojava/codingStandard/writingrobustjavacode_pidid93_c4.html#doc1_id1036
> ループカウンタは非常によく使われるローカル変数であり、C/C++でもよく使われたので、
> Javaでもi, j, kといった命名をループカウンタに使用してもよい(Gosling,Joy,Steele)。
気になったので、直しといた。少なくともコンパイルはできる。まぁあれだ、動く動かないじゃなくて思想だけ読み取ってほしい
extern
int BubbleSort(void *items, size_t length, size_t size, int (*comparer)(const void *, const void *))
{
size_t i;
if ( items == NULL ) {
return -2;
}
if ( comparer == (int (*)(const void *, const void *))0) {
return -4;
}
for ( i = 0; i < length - 1; ++i ) {
size_t j;
for ( j = length - 1; j > i; ++j ) {
if ( comparer(items + j-1, items + j) > 0 ) {
swapBytes((char *)items + size*(j-1), (char *)items + size*j, size);
}
}
}
return 0;
}
static void swapBytes(void *p, void *q, size_t size) {
size_t i;
char *s = (char *)p;
char *t = (char *)q;
for ( i = 0; i < size; ++i ) {
char u = *s; *s = *t, *t = u;
}
}
extern
int BubbleSort(void *items, size_t length, size_t size, int (*comparer)(const void *, const void *))
{
size_t i;
if ( items == NULL ) {
return -2;
}
if ( comparer == (int (*)(const void *, const void *))0) {
return -4;
}
for ( i = 0; i < length - 1; ++i ) {
size_t j;
for ( j = length - 1; j > i; ++j ) {
if ( comparer(items + j-1, items + j) > 0 ) {
swapBytes((char *)items + size*(j-1), (char *)items + size*j, size);
}
}
}
return 0;
}
static void swapBytes(void *p, void *q, size_t size) {
size_t i;
char *s = (char *)p;
char *t = (char *)q;
for ( i = 0; i < size; ++i ) {
char u = *s; *s = *t, *t = u;
}
}
今更ながらJavaは本当に気持ちの悪い言語ですね
このドキュメントは，Sun Microsystems 社の Java Language Specification において示された，
Java 言語における標準的なコーディングを反映させたものである．
http://numata.designed.jp/javacodeconv/CodeConventions.doc.html
変数名は，その機能を表すために必要十分な短いものであるべきである．
数名の選択は，ぱっと見ただけの者にもその使用意図を示すように設計された，
覚えやすいものであるべきである．
1文字だけの変数名は，いわゆる「使い捨て」の一時的な変数を除いて，避けるべきである．
一時的な変数には，共通して，整数には i，j，k，m，n が使われ，文字には c，d，e が使われる．
Java 言語における標準的なコーディングを反映させたものである．
http://numata.designed.jp/javacodeconv/CodeConventions.doc.html
変数名は，その機能を表すために必要十分な短いものであるべきである．
数名の選択は，ぱっと見ただけの者にもその使用意図を示すように設計された，
覚えやすいものであるべきである．
1文字だけの変数名は，いわゆる「使い捨て」の一時的な変数を除いて，避けるべきである．
一時的な変数には，共通して，整数には i，j，k，m，n が使われ，文字には c，d，e が使われる．
プログラマは何故宗教論争が好きなのか
そして、宗教に嵌まってしまうのか
そして、宗教に嵌まってしまうのか
モルモン教に謝れ
ディスプレイみんな何使ってるの
VB.NETのWithは秀逸だと思った
>>449に勝手に補足
JavaScriptとVB.NETのwithの違い
■JavaScriptの場合
var a = 0;
with(obj) {
a = 1
}
obj.a が存在すれば、obj.aに1が代入されるが、
obj.a が存在しなければ、var aに1が代入される。
objの状態によって、どちらに入るかわからない。
■VB.NET（VB6）の場合
Dim a As Integer
With obj
.a = 1
a = 1
End With
aに代入する場合と、obj.aに代入する場合で
書き方が違うから混乱しない。
JavaScriptとVB.NETのwithの違い
■JavaScriptの場合
var a = 0;
with(obj) {
a = 1
}
obj.a が存在すれば、obj.aに1が代入されるが、
obj.a が存在しなければ、var aに1が代入される。
objの状態によって、どちらに入るかわからない。
■VB.NET（VB6）の場合
Dim a As Integer
With obj
.a = 1
a = 1
End With
aに代入する場合と、obj.aに代入する場合で
書き方が違うから混乱しない。
後からコードを付き足す場合は、
そこに書いてある短いコードを読む。
後に付き足す場合でも、既存のコードを読まずに
付き足すことは出来ない
そこに書いてある短いコードを読む。
後に付き足す場合でも、既存のコードを読まずに
付き足すことは出来ない
コードスニペットで自動挿入される catch(Exception e)もわざわざ
Exception exceptionに書き換えてるの？
Exception exceptionに書き換えてるの？
>>452
短いというのは何行なの？10行以内？
短いというのは何行なの？10行以内？
そういや関数は50行以内にしろと
コーディング規約で定めているところもあるらしいね。
まあ複雑度を適切な値に収めた場合、
それぐらいの行数になるもんだが。
コーディング規約で定めているところもあるらしいね。
まあ複雑度を適切な値に収めた場合、
それぐらいの行数になるもんだが。
サブルーチンの長さも宗教論争ネタだな。
短いほうがいいと思ってる人が多いんで、これ言うと盛り上がるんだけど、
IBMの調査だと120行以下のサブルーチンの場合、行数が短いほど一行
あたりのバグ数が多かったらしいね。
つまり100行のサブルーチン一個より、10行のサブルーチン10個のほうが
バグの数が多いらしい。
出典はコードコンプリート
短いほうがいいと思ってる人が多いんで、これ言うと盛り上がるんだけど、
IBMの調査だと120行以下のサブルーチンの場合、行数が短いほど一行
あたりのバグ数が多かったらしいね。
つまり100行のサブルーチン一個より、10行のサブルーチン10個のほうが
バグの数が多いらしい。
出典はコードコンプリート
それは切出方が下手で関連性が強すぎて
結局長いサブルーチンをより難しく書いてるだけ
みたいなパターンでよくある話ってやつじゃないかな
結局長いサブルーチンをより難しく書いてるだけ
みたいなパターンでよくある話ってやつじゃないかな
1つのif文の中が1000行くらいある糞コードを見る機会のほうが多い
個々のcaseは単純な巨大switch文とか、
行数は多くても
一行当たりのバグは少ないだろうな
行数は多くても
一行当たりのバグは少ないだろうな
MSDOS3.0の頃はハードディスクが30MBしか使えなくて
スペースのインデントをタブに書きかえる作業をしまくったおかげで
スペースでインデントしてるの見ると殺意が湧く
スペースのインデントをタブに書きかえる作業をしまくったおかげで
スペースでインデントしてるの見ると殺意が湧く
ハードディスク30MBに
殺意を覚えろよｗ
殺意を覚えろよｗ
サブルーチンの行数は大昔から話題になっていて、
一画面が20〜25行しかない時代でも
「スクロール無で見渡せる一画面以下」とか言ってる人がいたね。
ああいうのって、言ってる本人も守ってなかったんじゃないかって気がするわ。
一画面が20〜25行しかない時代でも
「スクロール無で見渡せる一画面以下」とか言ってる人がいたね。
ああいうのって、言ってる本人も守ってなかったんじゃないかって気がするわ。
行数じゃなくてロジックの粒度で考えればいいのにね
スクロール無しって、何行なんだ？行数が変わるじゃんって思うだろ？
でも「スクロール無で見渡せる一画面以下」っていうのは
実は意味があるんだよ。
一画面であれば、視線の移動だけでコードが読める。
実はこれが重要。スクロールがあればスクロールをする時間
上下に行ったり来たり、この時間で読んだコードが短期記憶から消えてしまう。
視線の移動だけで見れれば、スクロールに比べて視線の移動は
高速だからその分速く理解できる。
だから、超巨大ディスプレイでスクロール無しで表示できるけど
視線の移動がきついってなった場合には「スクロール無し」という条件を
満たしていても、コードの把握が困難になってしまう。
文字の大きさを考えると50行ぐらいが限界だろうね。
でも「スクロール無で見渡せる一画面以下」っていうのは
実は意味があるんだよ。
一画面であれば、視線の移動だけでコードが読める。
実はこれが重要。スクロールがあればスクロールをする時間
上下に行ったり来たり、この時間で読んだコードが短期記憶から消えてしまう。
視線の移動だけで見れれば、スクロールに比べて視線の移動は
高速だからその分速く理解できる。
だから、超巨大ディスプレイでスクロール無しで表示できるけど
視線の移動がきついってなった場合には「スクロール無し」という条件を
満たしていても、コードの把握が困難になってしまう。
文字の大きさを考えると50行ぐらいが限界だろうね。
tab8とか正気かよ
4でいーんだよ
4でいーんだよ
>>462
上巻213ページのルーチンの長さの章。
今読み直してみたらIBMの調査で120行どうこうって記憶違いだね。
BasiliとPerriconeの調査で200行以下って話だわ。
IBMの調査は500行以上のルーチンになると行数に比例してエラーの発生率が増えるって話だわ。
上巻213ページのルーチンの長さの章。
今読み直してみたらIBMの調査で120行どうこうって記憶違いだね。
BasiliとPerriconeの調査で200行以下って話だわ。
IBMの調査は500行以上のルーチンになると行数に比例してエラーの発生率が増えるって話だわ。
perlのmain関数は4000行以上あるけど読みにくいってことはなかったって感じ？
読んだことないけど
読んだことないけど
短期記憶の容量？も個人差あるんで…
tab8は神の啓示ってリーナスが言ってたよ
GoogleのJavaScript Style Guideではtabがスペース2個なんだよ
http://cou929.nu/data/google_javascript_style_guide/
Closure Linterを使いたいんだが、
そこだけが気に食わない。
http://cou929.nu/data/google_javascript_style_guide/
Closure Linterを使いたいんだが、
そこだけが気に食わない。
タブサイズの話をすると、タブとインデントの区別がついてないんじゃないかって人が混ざってくる。
スペースインデントとか邪道
>>469
なんだこのサイト？って思ったが、該当箇所を書いてあったから貼っておくわ
http://kaoriha.org/nikki/archives/000512.html
・BasiliとPerriconeによる調査では、ルーチンのサイズがエラーと反比例することがわかった。
ルーチンのサイズが増えるにつれ（最大で200行のコード）、コード1行あたりのエラーの数は減っていく（Basili and Perricone 1984）。
・別の調査では、ルーチンのサイズにエラーとの因果関係はないが、構造的な複雑さやデータの
量がエラーに関係しているという結果が出ている（Shen et al. 1985）。
・1986年の調査では、小さいルーチン（コードが32行以下）とコストまたはエラーの発生率の減少と
に相関関係はないことがわかった（Card, Church and Agresti 1986; Card and Glass 1990）。
このことは、ルーチンが大きくなるほど（コードが65行以上）、コード1行あたりの開発コストが下がることを示してい
・450個のルーチンで実験を行った調査では、小さなルーチン（コメントを含め、ステートメントの数が143行未満）は、
大きなルーチンよりもコード1行あたりのエラー率が23%高いものの、修正コストは逆に2.4倍も少ないことがわかった（Selby and Basili 1991）。
・別の調査では、コードの修正が最も発生しにくいのは、平均して100〜150行のルーチンであることがわかった（Lind and Vairavan 1989）。
・IBMの調査によると、最もエラーが発生しやすいルーチンは、500行以上のものであることがわかった。
500行を超えると、エラーの発生率はルーチンのサイズに比例する傾向にある（Jones 1986a）。
なんだこのサイト？って思ったが、該当箇所を書いてあったから貼っておくわ
http://kaoriha.org/nikki/archives/000512.html
・BasiliとPerriconeによる調査では、ルーチンのサイズがエラーと反比例することがわかった。
ルーチンのサイズが増えるにつれ（最大で200行のコード）、コード1行あたりのエラーの数は減っていく（Basili and Perricone 1984）。
・別の調査では、ルーチンのサイズにエラーとの因果関係はないが、構造的な複雑さやデータの
量がエラーに関係しているという結果が出ている（Shen et al. 1985）。
・1986年の調査では、小さいルーチン（コードが32行以下）とコストまたはエラーの発生率の減少と
に相関関係はないことがわかった（Card, Church and Agresti 1986; Card and Glass 1990）。
このことは、ルーチンが大きくなるほど（コードが65行以上）、コード1行あたりの開発コストが下がることを示してい
・450個のルーチンで実験を行った調査では、小さなルーチン（コメントを含め、ステートメントの数が143行未満）は、
大きなルーチンよりもコード1行あたりのエラー率が23%高いものの、修正コストは逆に2.4倍も少ないことがわかった（Selby and Basili 1991）。
・別の調査では、コードの修正が最も発生しにくいのは、平均して100〜150行のルーチンであることがわかった（Lind and Vairavan 1989）。
・IBMの調査によると、最もエラーが発生しやすいルーチンは、500行以上のものであることがわかった。
500行を超えると、エラーの発生率はルーチンのサイズに比例する傾向にある（Jones 1986a）。
>>477
そんな素人丸出しなことを、よくもぬけぬけと
そんな素人丸出しなことを、よくもぬけぬけと
>>478
なんだその反論w 同じだろうが
なんだその反論w 同じだろうが
>>476の内容に関して「ルーチンの長さに関しては、長年にわたって研究が
山ほど積み重ねられてきた。それらの中には、現代のプログラムに当てはまるものもあれば、
そうでないものもある。」とコードコンプリートに書いてある。
さらに長いルーチンのほうが短いルーチンよりもエラーの発生率が高いとはいえない。
長さ自体に制限を設けるよりも、ルーチンの凝集度、ネストの深さ、変数の数、
分岐の数、ルーチンを説明するのに必要なコメントの数、およびその他の
複雑さに関する問題によって決定する。
と書いてある。
がしかし、
200行を超えるサイズのルーチンについて、コストの低下、エラー発生率の低下、
またはその両方を報告している調査は一例もない。コードは200行を超えた時点で、
わかりやすさの上限にぶつかる運命にある。
と結論づけている。
山ほど積み重ねられてきた。それらの中には、現代のプログラムに当てはまるものもあれば、
そうでないものもある。」とコードコンプリートに書いてある。
さらに長いルーチンのほうが短いルーチンよりもエラーの発生率が高いとはいえない。
長さ自体に制限を設けるよりも、ルーチンの凝集度、ネストの深さ、変数の数、
分岐の数、ルーチンを説明するのに必要なコメントの数、およびその他の
複雑さに関する問題によって決定する。
と書いてある。
がしかし、
200行を超えるサイズのルーチンについて、コストの低下、エラー発生率の低下、
またはその両方を報告している調査は一例もない。コードは200行を超えた時点で、
わかりやすさの上限にぶつかる運命にある。
と結論づけている。
>>480
インデントは字下げで、タブはタブキーを押して入力する制御コード。
インデントをタブキーですることが多いんでインデント=タブと思ってる
人がいるけど別物。
GNUは、インデントはスペース二個で、8の倍数のときにタブを使うって
変態的な使い方をしてる。
インデントは字下げで、タブはタブキーを押して入力する制御コード。
インデントをタブキーですることが多いんでインデント=タブと思ってる
人がいるけど別物。
GNUは、インデントはスペース二個で、8の倍数のときにタブを使うって
変態的な使い方をしてる。
変数名ってアンダーバー使っちゃだめなの？
>>481
サブルーチンの行数の話題になると、20行とか30行とか、いや50行くらいじゃないと
書きにくいだろとか言われるけど、実際は200行まではコードの質とは無関係って
ことだな。
サブルーチンの長さは、機能単位とかコードの複雑さで決めようって話になる。
サブルーチンの行数の話題になると、20行とか30行とか、いや50行くらいじゃないと
書きにくいだろとか言われるけど、実際は200行まではコードの質とは無関係って
ことだな。
サブルーチンの長さは、機能単位とかコードの複雑さで決めようって話になる。
>>484
最近は、アルファベットの大文字小文字で変数名の単語を区切るスタイルが
多いけど、昔はアンダーバーで区切るスタイルの人も多かった。
rubyの処理系のソースも、アンダーバーで区切るスタイル。
悪くはないと思う。
最近は、アルファベットの大文字小文字で変数名の単語を区切るスタイルが
多いけど、昔はアンダーバーで区切るスタイルの人も多かった。
rubyの処理系のソースも、アンダーバーで区切るスタイル。
悪くはないと思う。
> ・BasiliとPerriconeによる調査では、ルーチンのサイズがエラーと反比例することがわかった。
> ルーチンのサイズが増えるにつれ（最大で200行のコード）、コード1行あたりのエラーの数は減っていく（Basili and Perricone 1984）。
これって、行は多いけどコピペしてるだけとかそんな気もするｗ
> ルーチンのサイズが増えるにつれ（最大で200行のコード）、コード1行あたりのエラーの数は減っていく（Basili and Perricone 1984）。
これって、行は多いけどコピペしてるだけとかそんな気もするｗ
タブ＝スペース2個はあってるだろ？
2タブ＝スペース4個だよ？
2タブ＝スペース4個だよ？
>>492
前者かな。
有名なCやC++のオープンソースプロジェクトのソースとかいくつが見てみればいいと思う。
参考までにgoogleのルール。
http://www.textdrop.net/google-styleguide-ja/cppguide.xml
前者かな。
有名なCやC++のオープンソースプロジェクトのソースとかいくつが見てみればいいと思う。
参考までにgoogleのルール。
http://www.textdrop.net/google-styleguide-ja/cppguide.xml
タブとスペース混在でインデントしてる人って結構いるの？
CamelCase と snake_case はどっちかに統一してあればいいとおもうがね
混在してるとイラッとする
混在してるとイラッとする
タブとスペースの混在は結構見る
殺意が・・・
殺意が・・・
> GNUは、インデントはスペース二個で、8の倍数のときにタブを使うって
> 変態的な使い方をしてる。
> 変態的な使い方をしてる。
タブがスペース4幅なら
こういった問題は起きなかったんだろうな。
こういった問題は起きなかったんだろうな。
>>496
変数名と関数名どちらも統一すべきですか？
変数名と関数名どちらも統一すべきですか？
>>377 を読むと、1文字変数肯定派は技術の幅が狭いことがよくわかるね。
マッカーシー先生に謝れ！
マッカーシー先生に謝れ！
>>500
関数名はcamel case、変数名はsnake caseってのはよくある話だな。
関数名はcamel case、変数名はsnake caseってのはよくある話だな。
単純に、
payment = price[cno] * quantity;
と
a = p[i] * n;
で、どちらが分かりやすいで言うとどっち？
payment = price[cno] * quantity;
と
a = p[i] * n;
で、どちらが分かりやすいで言うとどっち？
payment = price[i] * quantity;
アスペっぽいなぁ
>>505
自分で考えることもできねーなら発言すんな
自分で考えることもできねーなら発言すんな
いや、何も考えてないのは>>504だろ
for (int i = f(); g(i); i = h(i)) {
check(i);
update(i);
}
と、
for (int customer = get_first_customer(); is_valid_customer(customer); get_next_customer(customer)) {
check_customer_validity(customer);
update_customer_history(customer);
}
どっちが読みやすい？
上のほうが読みやすいという人は、アスペっぽいと思うぞ。
check(i);
update(i);
}
と、
for (int customer = get_first_customer(); is_valid_customer(customer); get_next_customer(customer)) {
check_customer_validity(customer);
update_customer_history(customer);
}
どっちが読みやすい？
上のほうが読みやすいという人は、アスペっぽいと思うぞ。
作ってる最中は上
半年後に見る場合は下
半年後に見る場合は下
一文字変数ってスコープが小さい、例えばループ変数等って話だろ？
for (int c = get_first_customer(); is_valid_customer(c); get_next_customer(c)) {
check_customer_validity(c);
update_customer_history(c);
}
十分意味わかるし、見やすいね。
for (int c = get_first_customer(); is_valid_customer(c); get_next_customer(c)) {
check_customer_validity(c);
update_customer_history(c);
}
十分意味わかるし、見やすいね。
>>512をみて、cはなんなんだ？
って思う奴は、アスペだろうな。
int c = get_first_customer(); この行から
cが何であるかは明らか。
アスペはたった三行の中で、推論が出来ない。
って思う奴は、アスペだろうな。
int c = get_first_customer(); この行から
cが何であるかは明らか。
アスペはたった三行の中で、推論が出来ない。
294 名前：仕様書無しさん[sage] 投稿日：2013/03/28(木) 21:19:49.35
もうそろそろ、空気読んでない奴が
グローバル変数に変数名一文字を使うのかよっていいそうだな。
変数名iというのはループ変数。
ローカルよりもさらにスコープも小さいブロックスコープで
なおかつコードの量が少ない時のみOKという話。
あとでコードが長くなったどうするんだ？と言っている奴は理解できん。
ループ変数にかぎらず、コードが長くなったら分割するだろ？修正するだろ。
長くなったら修正すればいいだけ。
動いているコードは修正してはいけないという間違った考えが広まった結果
修正の必要があるのに、いかに既存のコードを修正せずに、コードの追加だけを
行なって修正するというアクロバティックな開発をしているバカが居る。
長くなった時に困る奴はそのたぐいなのか？
もうそろそろ、空気読んでない奴が
グローバル変数に変数名一文字を使うのかよっていいそうだな。
変数名iというのはループ変数。
ローカルよりもさらにスコープも小さいブロックスコープで
なおかつコードの量が少ない時のみOKという話。
あとでコードが長くなったどうするんだ？と言っている奴は理解できん。
ループ変数にかぎらず、コードが長くなったら分割するだろ？修正するだろ。
長くなったら修正すればいいだけ。
動いているコードは修正してはいけないという間違った考えが広まった結果
修正の必要があるのに、いかに既存のコードを修正せずに、コードの追加だけを
行なって修正するというアクロバティックな開発をしているバカが居る。
長くなった時に困る奴はそのたぐいなのか？
大抵他人にレビューしてもらった経験がないアマチュアは上のほうが見通しがいいと言う。
しかし、書いた本人かエスパーでもなければ、具体的に何をしているのか知るにはf(), g(), h(), check(), update()を読まないとわからん。
書いた本人は各関数が何をするかわかっているから見通しがいいと勘違いする。
こういう糞コードがメンテコストを上昇させる。
これからコードを書く人は絶対にこんなオナニーコードを書いちゃいけない。
さもなくば人月50万で売られることになる。
しかし、書いた本人かエスパーでもなければ、具体的に何をしているのか知るにはf(), g(), h(), check(), update()を読まないとわからん。
書いた本人は各関数が何をするかわかっているから見通しがいいと勘違いする。
こういう糞コードがメンテコストを上昇させる。
これからコードを書く人は絶対にこんなオナニーコードを書いちゃいけない。
さもなくば人月50万で売られることになる。
上、下じゃねーよ。
for (int c = get_first_customer(); is_valid_customer(c); get_next_customer(c)) {
check_customer_validity(c);
update_customer_history(c);
}
これがわかりやすいって言ってんだろ。
ループ変数でコード短いから一文字。
この話から逃げるなよ。
for (int c = get_first_customer(); is_valid_customer(c); get_next_customer(c)) {
check_customer_validity(c);
update_customer_history(c);
}
これがわかりやすいって言ってんだろ。
ループ変数でコード短いから一文字。
この話から逃げるなよ。
>>513
いや、cはなんなんだと思って1行目を読んでやっと理解するのが通常人。
cなんてわかってるだろうと思い込むのがアスペ。
各行それぞれがself-containedで意味がわかるのが良いコード。
ループ構造全体を読まないとループ内の各行の意味がわからないコードは糞コード。
いや、cはなんなんだと思って1行目を読んでやっと理解するのが通常人。
cなんてわかってるだろうと思い込むのがアスペ。
各行それぞれがself-containedで意味がわかるのが良いコード。
ループ構造全体を読まないとループ内の各行の意味がわからないコードは糞コード。
>>511がFAでいいだろ
コンテキスト抜きで意味が分かると思うほうが完全にアスペだぞ
>>513
うわ、君ってアスペの素質十分だね。
書いた本人がわかるから読む人もわかるだろうというその発想がアスペ丸出し。
はっきり言うと、君みたいのがゴミをまき散らしてプロジェクトを炎上させるんだよ。
うわ、君ってアスペの素質十分だね。
書いた本人がわかるから読む人もわかるだろうというその発想がアスペ丸出し。
はっきり言うと、君みたいのがゴミをまき散らしてプロジェクトを炎上させるんだよ。
一文字変数禁止反対派がいきなりループ変数限定とか
スコープが短い変数限定とか条件を付けだしててわろたｗｗｗ
スコープが短い変数限定とか条件を付けだしててわろたｗｗｗ
check_customer_validity(c); という一行を読んで、
引数がcustomerだなってのはわかる。
なぜなら、この関数はcustomerを引数に取る関数だって
名前からも明らかだから。
分からないのは、このcがどうやって得られた？という問題だが
check_customer_validity(customer)と書いた所で、
このcustomerはどうやって得られたかはわからない。
結局のところ上をみないと、 get_first_customer();で
得られたんだってことはわからない。
引数がcustomerだなってのはわかる。
なぜなら、この関数はcustomerを引数に取る関数だって
名前からも明らかだから。
分からないのは、このcがどうやって得られた？という問題だが
check_customer_validity(customer)と書いた所で、
このcustomerはどうやって得られたかはわからない。
結局のところ上をみないと、 get_first_customer();で
得られたんだってことはわからない。
>>>522
最初っからそうだが？
294 名前：仕様書無しさん[sage] 投稿日：2013/03/28(木) 21:19:49.35
もうそろそろ、空気読んでない奴が
グローバル変数に変数名一文字を使うのかよっていいそうだな。
変数名iというのはループ変数。
ローカルよりもさらにスコープも小さいブロックスコープで
なおかつコードの量が少ない時のみOKという話。
最初っからそうだが？
294 名前：仕様書無しさん[sage] 投稿日：2013/03/28(木) 21:19:49.35
もうそろそろ、空気読んでない奴が
グローバル変数に変数名一文字を使うのかよっていいそうだな。
変数名iというのはループ変数。
ローカルよりもさらにスコープも小さいブロックスコープで
なおかつコードの量が少ない時のみOKという話。
スコープが3行ならいいだろう
スコープが4行ならいいだろう
そして最後には
スコープがファイル内ならいいだろう
に行き着く猿w
スコープが4行ならいいだろう
そして最後には
スコープがファイル内ならいいだろう
に行き着く猿w
>>526が猿だったｗ
>>524
>check_customer_validity(c); という一行を読んで、
>引数がcustomerだなってのはわかる。
そういう思い込みがバグを生む要因の1つ。
もしかしたらcは小切手ID(check_id)かもしれんぞ？
その小切手IDから振り出し人のチェックをする関数だったらどうする？
>check_customer_validity(c); という一行を読んで、
>引数がcustomerだなってのはわかる。
そういう思い込みがバグを生む要因の1つ。
もしかしたらcは小切手ID(check_id)かもしれんぞ？
その小切手IDから振り出し人のチェックをする関数だったらどうする？
>>527
じゃあ何行までならOKか具体的な数字で言ってみろよw
じゃあ何行までならOKか具体的な数字で言ってみろよw
関数型言語のように1行ごとに宣言的でコンテキスト独立した言語なら1文字変数でもいいが、
ここでネタになっているような逐次的コードで1文字変数は有害だな。
ここでネタになっているような逐次的コードで1文字変数は有害だな。
>>529
457 ：仕様書無しさん：2013/03/30(土) 00:35:45.32
>>455
10行ぐらいでいいんじゃね？
変数の出てくる回数や、
ifやforなんかの数でも変わってくるけど。
457 ：仕様書無しさん：2013/03/30(土) 00:35:45.32
>>455
10行ぐらいでいいんじゃね？
変数の出てくる回数や、
ifやforなんかの数でも変わってくるけど。
コードの複雑度ってのは
行数と比例しないってことぐらい
知ってるよな？
行数と比例しないってことぐらい
知ってるよな？
まずcheck_customer_validity(c);のcheckってなんだよ
validate_customer()とかvalidate_customer_id()とかhas_customer_id()とかにすべきです
変数名もcだとcustomerなのかcustomer_idなのかcustomer_discripterなのかそれ以外なのか
少なくともcustomerに関係することだけは分かります
validate_customer()とかvalidate_customer_id()とかhas_customer_id()とかにすべきです
変数名もcだとcustomerなのかcustomer_idなのかcustomer_discripterなのかそれ以外なのか
少なくともcustomerに関係することだけは分かります
>>532
比例するっつーのアホｗ
比例するっつーのアホｗ
10行も上を読まないと意味がわからん変数とか、真性の糞コードだろw
List l = new ArrayList();
Map cm = get_condition_map();
for (int c = get_first_customer(); is_valid_customer(c); get_next_customer(c)) {
check_customer_validity(c);
update_customer_history(c);
cl = get_client(c);
if(cm.containsKey(cl.get_condition())){
l.add(cl);
}
}
まだ短かいままだが少し加えただけで読みにくくなるな
Map cm = get_condition_map();
for (int c = get_first_customer(); is_valid_customer(c); get_next_customer(c)) {
check_customer_validity(c);
update_customer_history(c);
cl = get_client(c);
if(cm.containsKey(cl.get_condition())){
l.add(cl);
}
}
まだ短かいままだが少し加えただけで読みにくくなるな
一文字変数をつくる奴って、「俺は理解できるから」しか
主張がないんだよね。多人数でソースをいじっているという考慮を
しないから、他人が理解できるかどうかということを一切考えない。
同じ主張の人間が、別のスコープで同じ名前の一文字変数を別の
意味でつかったら、他の人が混乱するだろうとか、そういう考えが
できないんだろうね。
型が少ないC言語しか使えない人たちなのかな。
iで始まる型なんて最近の言語じゃ無数にあるんだけどね。
主張がないんだよね。多人数でソースをいじっているという考慮を
しないから、他人が理解できるかどうかということを一切考えない。
同じ主張の人間が、別のスコープで同じ名前の一文字変数を別の
意味でつかったら、他の人が混乱するだろうとか、そういう考えが
できないんだろうね。
型が少ないC言語しか使えない人たちなのかな。
iで始まる型なんて最近の言語じゃ無数にあるんだけどね。
>>538
一文字変数で可読性やら保守性が落ちるかって話でしょ?
上のほうで落ちないって傍証がいろいろあげられているじゃん。
コードを書いて見比べてたり、見識のある人たちがどう考えてるかとか。
一文字反対派はそれに反論しないで、ひたすら「わかりにくい」を繰り返して話をループさせてるだけ。
一文字変数で可読性やら保守性が落ちるかって話でしょ?
上のほうで落ちないって傍証がいろいろあげられているじゃん。
コードを書いて見比べてたり、見識のある人たちがどう考えてるかとか。
一文字反対派はそれに反論しないで、ひたすら「わかりにくい」を繰り返して話をループさせてるだけ。
>>504
payment = price[cno] * quantity;
payment = price[uid] * quantity;
payment = price[cnt] * quantity;
この違いは分かる？
payment = price[cno] * quantity;
payment = price[uid] * quantity;
payment = price[cnt] * quantity;
この違いは分かる？
変数にはコメントを付けろ
スレたてたからそっち行って続けてくれ
http://kohada.2ch.net/test/read.cgi/prog/1364608889/
http://kohada.2ch.net/test/read.cgi/prog/1364608889/
l = [] # 条件が満たされたクライアントの集合
cm = get_condition_map() # クライアントが満たすべき条件
for c in customers:
check_customer_validate(c)
update_customer_history(c)
if is_valid_customer(c):
break
cl = get_client(c)
if cm.has_key(cl.get_condition()):
l.add(cl)
つかなんで非オブジェクト指向的な書き方とオブジェクト指向的な書き方が混在しているんだ
cm = get_condition_map() # クライアントが満たすべき条件
for c in customers:
check_customer_validate(c)
update_customer_history(c)
if is_valid_customer(c):
break
cl = get_client(c)
if cm.has_key(cl.get_condition()):
l.add(cl)
つかなんで非オブジェクト指向的な書き方とオブジェクト指向的な書き方が混在しているんだ
スレたてたからそっち行って続けてくれ
http://kohada.2ch.net/test/read.cgi/prog/1364608889/
http://kohada.2ch.net/test/read.cgi/prog/1364608889/
l = [] # 条件が満たされたクライアントの集合
cm = get_condition_map() # クライアントが満たすべき条件
for c in customers:
check_customer_validate(c)
update_customer_history(c)
if is_valid_customer(c):
break
cl = get_client(c)
if cm.has_key(cl.get_condition()):
l.add(cl)
半角スペース使えないんだったな
cm = get_condition_map() # クライアントが満たすべき条件
for c in customers:
check_customer_validate(c)
update_customer_history(c)
if is_valid_customer(c):
break
cl = get_client(c)
if cm.has_key(cl.get_condition()):
l.add(cl)
半角スペース使えないんだったな
>>545
ごめん、俺がCのわからないJava使いだからああなった
ごめん、俺がCのわからないJava使いだからああなった
Javaドカタ
>>550はスコープを理解できないドカタ
書いた本人だって5年後に読んだら爆死するぞw
一文字変数厨って、結局入門書のループの説明にiとかjとかあったのを
何の疑いもなく使い続けているんだろうな。
一文字変数厨って、結局入門書のループの説明にiとかjとかあったのを
何の疑いもなく使い続けているんだろうな。
アスペアスペうるせぇよ、定型さん
>>552はスコープ理解のコストを自覚していないアスペ
スコープを理解できないから
全部の変数名を長くつけるというルールを覚えたドカタw
全部の変数名を長くつけるというルールを覚えたドカタw
>>554
図星？
図星？
定型には土方がお似合いだ
>>556
スコープ理解のコストを理解しているから
各行の意味をそれぞれ単独で理解しやすくするように
変数名や関数名にきちんと意味のある名前をつける
たったそれだけの簡単なことができないバカはコード書くな
スコープ理解のコストを理解しているから
各行の意味をそれぞれ単独で理解しやすくするように
変数名や関数名にきちんと意味のある名前をつける
たったそれだけの簡単なことができないバカはコード書くな
アスペのみなさんもこちらへ移動。
http://kohada.2ch.net/test/read.cgi/prog/1364608889/
http://kohada.2ch.net/test/read.cgi/prog/1364608889/
一文字変数使って平気なのは10行以上のコードを書いたことがないから
このスレッドだけIDが必要です
>>562
COBOLでも使ってろよ
COBOLでも使ってろよ
>>563
修正させられる身としては、カウンタだけならともかく、一文字変数満載コードは5行でも殺意がわく。
修正させられる身としては、カウンタだけならともかく、一文字変数満載コードは5行でも殺意がわく。
ショートコーディング(ｷﾘｯ
>>512
あ、俺これだわ
あ、俺これだわ
i がソースの複数個所で使われていて、混乱するとか、それを理解するのにコストがかかるとかさすがに屁理屈すぎるわ。
>>566
実行時のコンテクストに依存するポリモーフィズムなんて論外だよな！
実行時のコンテクストに依存するポリモーフィズムなんて論外だよな！
一文字変数を使うバカは人生の敗北者part1
http://kohada.2ch.net/test/read.cgi/prog/1364608889/
一文字変数についてはこっちでやろうね、お兄ちゃん
ここは初心者を導くスレです
http://kohada.2ch.net/test/read.cgi/prog/1364608889/
一文字変数についてはこっちでやろうね、お兄ちゃん
ここは初心者を導くスレです
>>572
しつこい死ね
しつこい死ね
ちなみに、
1 payment = price[cno] * quantity;
2 payment = price[i] * quantity;
3 a = p[i] * n;
で、3もありなのか？
1 payment = price[cno] * quantity;
2 payment = price[i] * quantity;
3 a = p[i] * n;
で、3もありなのか？
配列もリストもiなんか使わなくても回せるのに
いまだにiが必要な言語を使ってるやつは不幸だな
いまだにiが必要な言語を使ってるやつは不幸だな
ちなみに一文字変数のためにこのスレは半分消費されています
コンテキスト依存のコードって連呼してるやつ恥ずかしくないのか？
それともガチのバカ？
それともガチのバカ？
たわけ、わろた、ぐぐれかす
>>577
いいんじゃね、内容的に面白いぞ。
いいんじゃね、内容的に面白いぞ。
>>580
indexが一個ならiでいいけど複数ならそっちのほうが読みやすいよ
indexが一個ならiでいいけど複数ならそっちのほうが読みやすいよ
そろそろ昼だから昼休みの1時間は終戦な
その間に、お互い意見をまとめよう
一文字変数肯定派は、どういう時に使ってよくて、どういう時に使うべきでないか
一文字変数否定派は、何故使ってはいけないのか
世の中、最大多数の最大幸福だからな
その間に、お互い意見をまとめよう
一文字変数肯定派は、どういう時に使ってよくて、どういう時に使うべきでないか
一文字変数否定派は、何故使ってはいけないのか
世の中、最大多数の最大幸福だからな
>>575
一文字派の人でも、3を押す人はいないんじゃないの。
cnoとか意味のない名前だったら 2 の i でいいわ。
慣習としてループカウンタにiを使うって、誰でも知ってるから。
cnoでも悪いってわけじゃないけど。
一文字派の人でも、3を押す人はいないんじゃないの。
cnoとか意味のない名前だったら 2 の i でいいわ。
慣習としてループカウンタにiを使うって、誰でも知ってるから。
cnoでも悪いってわけじゃないけど。
アリゴリズムの話じゃなくて、ソースコードの可読性とか保守性の話なのが
時代だなーって思った。
時代だなーって思った。
アスペは状況に応じてルールを使い分けるのが苦手だし
低能はちょっとでも複雑なルールは覚えられない
だからアスペや低能は「一律で長い名前を付ける」って単純なルールに固執する
低能はちょっとでも複雑なルールは覚えられない
だからアスペや低能は「一律で長い名前を付ける」って単純なルールに固執する
>>580
payment = price[priceIndex] * quantity;
これはiやcntと変わらないな。
商品バスケット内の計算などなら、
payment = price[containerNo] * quantity;
ってとこだな。
1 payment = price[containerNo] * quantity;
2 payment = price[cno] * quantity;
3 payment = price[i] * quantity;
4 a = p[i] * n;
で、4もありなのか？
payment = price[priceIndex] * quantity;
これはiやcntと変わらないな。
商品バスケット内の計算などなら、
payment = price[containerNo] * quantity;
ってとこだな。
1 payment = price[containerNo] * quantity;
2 payment = price[cno] * quantity;
3 payment = price[i] * quantity;
4 a = p[i] * n;
で、4もありなのか？
ちょっと前に行数の話が出てたけど、おまえらが「この関数(メソッド)複雑だな」とか思うのって
行数や、変数、制御構文の数で言うとどのくらい？
行数や、変数、制御構文の数で言うとどのくらい？
>>590
ネストのひどいifは、他に書き方なかったんか、と呆れる
ネストのひどいifは、他に書き方なかったんか、と呆れる
>>587
状況にもよるよね。
三つも四つも複数ののテーブルを同時になめて、それぞれに独自のインデックス用の変数を
用意しなくちゃならないって状況が、そんなにないと思うけど、あったらそれぞれ
ユニークに名前をつけたほうがいいと思う。
状況にもよるよね。
三つも四つも複数ののテーブルを同時になめて、それぞれに独自のインデックス用の変数を
用意しなくちゃならないって状況が、そんなにないと思うけど、あったらそれぞれ
ユニークに名前をつけたほうがいいと思う。
職場のアホが取るに足らない作業をいつまでもいつまでもやっていたから、
「ここをこういう風にすれば速くなりますよ。」と誰でも思い付く方法を助言してやった。
すると奴は不機嫌そうに「そんな方法があるならもっと早く教えてほしかった。」と応え、ニヤニヤしていた。
普通、「なるほど。ありがとう。」だろ
感謝もできねーのかクズ
「ここをこういう風にすれば速くなりますよ。」と誰でも思い付く方法を助言してやった。
すると奴は不機嫌そうに「そんな方法があるならもっと早く教えてほしかった。」と応え、ニヤニヤしていた。
普通、「なるほど。ありがとう。」だろ
感謝もできねーのかクズ
嫌味ったらしく言った上愚痴ってるならお前が発達障害
そうじゃないなら相手が発達障害
自分の態度によって相手の態度が変わるということが理解できない奴多いからな
自分の言動が招いた結果なのに「アイツにああ言われたこう言われた」って言いふらすのが
飽きるほどよくあるパターン
そうじゃないなら相手が発達障害
自分の態度によって相手の態度が変わるということが理解できない奴多いからな
自分の言動が招いた結果なのに「アイツにああ言われたこう言われた」って言いふらすのが
飽きるほどよくあるパターン
コードを読む、ということを処理を理解することではなく
変数名や関数名から想像して理解した気分になることを指す
SEの皆様方にとっては
名前は全て説明的な長い名前であって欲しいのです
スコープなんて関係ないし、ポリモーフィズムも関係ない
だって単語から処理を想像するだけですからね
変数名や関数名から想像して理解した気分になることを指す
SEの皆様方にとっては
名前は全て説明的な長い名前であって欲しいのです
スコープなんて関係ないし、ポリモーフィズムも関係ない
だって単語から処理を想像するだけですからね
行数とソースのサイズが業績となります。
もうこの話飽きたお
アスペだの発達障害だの、
病気認定しようとするやつら多すぎるな
おまえらは医師兼プログラマーなのか
病気認定しようとするやつら多すぎるな
おまえらは医師兼プログラマーなのか
>>595
俺のいつもやっているのは2だ。
確かに3はループが1画面に収まっていて、単一ループなら容認できる。
しかし2と3には分かりにくいが差がある。
1と3を比べた方が分かるが、カウンタを見ると、なんのループか想像できる。
1は冗長に見えるが意味は分かりやすい。まあ慣れかな。
俺のいつもやっているのは2だ。
確かに3はループが1画面に収まっていて、単一ループなら容認できる。
しかし2と3には分かりにくいが差がある。
1と3を比べた方が分かるが、カウンタを見ると、なんのループか想像できる。
1は冗長に見えるが意味は分かりやすい。まあ慣れかな。
>>596
お前性格悪いだろ
お前性格悪いだろ
604 ：仕様書無しさん：2013/03/30(土) 14:42:52.27
暴れてんの1人やなぁ
>>603
でかいテキストデータを加工する作業があって、サーバーから自分のPCに転送して
秀丸の矩形選択なんかを活用してセコセコ編集して、またサーバーに戻して「ドヤ」みたいな
ベテランがいたけど、「それスクリプト使えば一瞬ですよ」とは言わないで「秀丸って
そんなことできるんですか。便利ですね」って言っておいた。
でかいテキストデータを加工する作業があって、サーバーから自分のPCに転送して
秀丸の矩形選択なんかを活用してセコセコ編集して、またサーバーに戻して「ドヤ」みたいな
ベテランがいたけど、「それスクリプト使えば一瞬ですよ」とは言わないで「秀丸って
そんなことできるんですか。便利ですね」って言っておいた。
>>605
お前性格良いなｗｗｗ
お前性格良いなｗｗｗ
スレ分かれたら途端につまらなくなったな
608 ：仕様書無しさん：2013/03/30(土) 17:30:28.66
>>605
これがプロか
これがプロか
変数の生存期間が短い場合は
ループ変数は一文字でいいのか。
いつも俺がやっていたことだな。
ループ変数は一文字でいいのか。
いつも俺がやっていたことだな。
List l = new ArrayList();
Map cm = get_condition_map();
for (int c = get_first_customer(); is_valid_customer(c); get_next_customer(c)) {
check_customer_validity(c);
update_customer_history(c);
cl = get_client(c);
if ( cm.containsKey(cl.get_condition()) ) {
l.add(cl);
}
}
短い変数名でも十分読みやすいな。
Map cm = get_condition_map();
for (int c = get_first_customer(); is_valid_customer(c); get_next_customer(c)) {
check_customer_validity(c);
update_customer_history(c);
cl = get_client(c);
if ( cm.containsKey(cl.get_condition()) ) {
l.add(cl);
}
}
短い変数名でも十分読みやすいな。
変数が5つもあったら
一文字変数だとわかりづらいだろ！
↑
これって、変数の数が少なければ
一文字変数でいいと認めているようなもんだよなｗ
一文字変数だとわかりづらいだろ！
↑
これって、変数の数が少なければ
一文字変数でいいと認めているようなもんだよなｗ
結局一文字変数禁止派は孤軍奮闘で荒らしてただけだった模様
義務教育の中でも
vと言えば速度なんだ
mと言えば質量なんだ
これらを数式内でvelocityだmassだと記述せよと言ってるみたいに見える
vと言えば速度なんだ
mと言えば質量なんだ
これらを数式内でvelocityだmassだと記述せよと言ってるみたいに見える
高校物理とかなら1文字の変数名を見ただけで意味がわかるよな。
もし高校物理で1年生の時はmは質量でvは速度を表わす変数、、
でも2年になったらmは慣性モーメントでvは電圧を表わす変数、、
3年になったらmは摩擦係数でvは光速を表わす変数、
テストでは全部出ます、ということにしたらどうなる？
高校物理程度なら1文字でも名前衝突せずに済むからいいよ。
だが情報システムでは同時に関連する概念の数が違うからな。
たった1文字で表わされた変数が何を表わすのか、
その1文字を見ただけでは判らないよ。
5行だか10行だか上に書かれたfor文とかを見ないと判らない。
それって効率的なことだと思うかい？
それぐらいなら、速度はvelocity、質量はmassと綴ったほうが効率的だと思うぞ。
もし高校物理で1年生の時はmは質量でvは速度を表わす変数、、
でも2年になったらmは慣性モーメントでvは電圧を表わす変数、、
3年になったらmは摩擦係数でvは光速を表わす変数、
テストでは全部出ます、ということにしたらどうなる？
高校物理程度なら1文字でも名前衝突せずに済むからいいよ。
だが情報システムでは同時に関連する概念の数が違うからな。
たった1文字で表わされた変数が何を表わすのか、
その1文字を見ただけでは判らないよ。
5行だか10行だか上に書かれたfor文とかを見ないと判らない。
それって効率的なことだと思うかい？
それぐらいなら、速度はvelocity、質量はmassと綴ったほうが効率的だと思うぞ。
なに、4番OKの人いるのか？
ぇ？
>>616
baka?
baka?
というようなことを>>616は言いたかったのではなかろうか
ほう
>>620
なんだってーッ！それは本当かキバヤシ！！
なんだってーッ！それは本当かキバヤシ！！
>>619
地場の中を導線が直線等速運動している場合の起電力とか
地場の中を導線が直線等速運動している場合の起電力とか
京都大学の入試とかで出そうでなんかいやだIQが違いすぎる
そりゃそうだ、大抵の問題は日本語で説明されているからなw
それに対して日本語読まないと
変数の意味がわからないじゃないか。
と文句をいうやつはイない。
変数の意味がわからないじゃないか。
と文句をいうやつはイない。
なんという的外れなつっこみ
>>614
> もし高校物理で1年生の時はmは質量でvは速度を表わす変数、、
> でも2年になったらmは慣性モーメントでvは電圧を表わす変数、、
> 3年になったらmは摩擦係数でvは光速を表わす変数、
> テストでは全部出ます
全部同じスコープ内でその3セット6種類の変数が出現するのか？
もしそうなら確かに変数名はフルスペルの方がいいが、おそらくそんな事にはならん
> もし高校物理で1年生の時はmは質量でvは速度を表わす変数、、
> でも2年になったらmは慣性モーメントでvは電圧を表わす変数、、
> 3年になったらmは摩擦係数でvは光速を表わす変数、
> テストでは全部出ます
全部同じスコープ内でその3セット6種類の変数が出現するのか？
もしそうなら確かに変数名はフルスペルの方がいいが、おそらくそんな事にはならん
コードも同じだな。
短い場合は変数名一文字でも良いというのは
そういうこと。
短い場合は変数名一文字でも良いというのは
そういうこと。
別のスコープなら混同しないというのは、
別の方程式なら同じ変数名使っても混同しない
というのに等しい馬鹿さ加減だなw
別の方程式なら同じ変数名使っても混同しない
というのに等しい馬鹿さ加減だなw
>>630
磁界中を光速の1.0x10^-7倍で移動している導線から発生する起電力で
所与の慣性モーメントの円筒状の物体を回転させる時の角速度を求めよ。
ただし、円筒状の物体は外周にて所与の摩擦係数と垂直抗力で接触しているものとする。
磁界中を光速の1.0x10^-7倍で移動している導線から発生する起電力で
所与の慣性モーメントの円筒状の物体を回転させる時の角速度を求めよ。
ただし、円筒状の物体は外周にて所与の摩擦係数と垂直抗力で接触しているものとする。
よし、飯食おう
>>632
> 別のスコープなら混同しないというのは、
普通混同しない。
お前はすべての変数名が被らないような
コーディング規約で開発してるのか？
ローカル変数は「クラス名＋関数名＋変数名」という命名規約とか？
> 別のスコープなら混同しないというのは、
普通混同しない。
お前はすべての変数名が被らないような
コーディング規約で開発してるのか？
ローカル変数は「クラス名＋関数名＋変数名」という命名規約とか？
636 ：仕様書無しさん：2013/03/30(土) 23:42:12.32
大学受験板に迷い込んだらしい
頭がパーン
1文字変数は専用スレがあるんだから、そっちでやれよｗ
一文字変数スレはキラキラネーム都市伝説論争してる...
謎だ
謎だ
「一文字でも意味がわかる」ということを
認識できないのだろうか？
認識できないのだろうか？
仕様を守りたがらないから、スレタイも守りたがらない
>>639
全部27のせいじゃねーかｗｗｗ
全部27のせいじゃねーかｗｗｗ
コードを書くときのモチベーションの保ち方を教えてください
既存の俺が入ってくる前のコードが
いかに汚くて開発効率が悪いかを訴えて
改善したコードを社内ブログに書いてストレス解消している。
いかに汚くて開発効率が悪いかを訴えて
改善したコードを社内ブログに書いてストレス解消している。
ぜひ参考にしたいわぁ
日本よ、これが「馬鹿」だ！ >>635
>>646
言い返せないならレスすんなよクソガキ
言い返せないならレスすんなよクソガキ
>>647 つ >>632
f = m a
l = m ω
f = m n
これを組み合せる時に、どのmとどのmが同じで、どのmとどのmが違うのか、
立式した箇所を参照すれば混乱しないよねw
f = m aのfをf = m nに代入する時にはm1 a = m2 nにすればいいんだよねw
ほんと君って馬鹿丸出しだね。
f = m a
l = m ω
f = m n
これを組み合せる時に、どのmとどのmが同じで、どのmとどのmが違うのか、
立式した箇所を参照すれば混乱しないよねw
f = m aのfをf = m nに代入する時にはm1 a = m2 nにすればいいんだよねw
ほんと君って馬鹿丸出しだね。
>>635
>ローカル変数は「クラス名＋関数名＋変数名」という命名規約とか？
そんなことしないと変数名を被らないようにつけられないのか？
おまえ、プログラマの素質ないから、さっさと転職しろ。
勘違いするなよ、おまえのために言っているんじゃない。
おまえの書いたコードで迷惑がかかっている人達のために言っている。
>ローカル変数は「クラス名＋関数名＋変数名」という命名規約とか？
そんなことしないと変数名を被らないようにつけられないのか？
おまえ、プログラマの素質ないから、さっさと転職しろ。
勘違いするなよ、おまえのために言っているんじゃない。
おまえの書いたコードで迷惑がかかっている人達のために言っている。
>>648
スレ違い
スレ違い
反論できなくなったら「スレ違い」
わかりやすッ！
わかりやすッ！
まず、奴隷同士で戦おうとするのを止めて、
もっと広い視野を持って欲しい。
もっと広い視野を持って欲しい。
職場でのルールが今までの自分のやり方と違うからといって
職場のルールをアスペだのと罵倒する前に
なぜそのルールが出来たのか、理由を理解する習慣をつけてほしい。
職場のルールをアスペだのと罵倒する前に
なぜそのルールが出来たのか、理由を理解する習慣をつけてほしい。
>>651
反論もくそも該当スレがわざわざ有るんだからさ…
反論もくそも該当スレがわざわざ有るんだからさ…
スレが盛り上がると止めようとするやついるな
ルシャトリエの原理だろうな
しかし、有名なコーディング規約で
一文字変数は許されているのであった。
勝負ありだなｗ
一文字変数は許されているのであった。
勝負ありだなｗ
最初は「コーディング規約はクソ」と噛み付いておいて
「コーディング規約で許されているから勝ち」と勝利宣言
おめでとうw (頭が)
「コーディング規約で許されているから勝ち」と勝利宣言
おめでとうw (頭が)
「コーディング規約はクソ」っていうのは、
どこの馬の骨かしらない会社のオレオレ規約
「コーディング規約で許されているから勝ち」というのは
世界的に有名な規約。
ごっちゃにしたらいかんよ。
何か反論でもある？ｗ
どこの馬の骨かしらない会社のオレオレ規約
「コーディング規約で許されているから勝ち」というのは
世界的に有名な規約。
ごっちゃにしたらいかんよ。
何か反論でもある？ｗ
みんなやってるから、有名なグループがそうしているから、
で正当化できると思っている頭って
ほんとうにおめでたいですね。
で正当化できると思っている頭って
ほんとうにおめでたいですね。
で、反論は？
有名っていうのは理由があって有名なんだよ。
その有名を御前は打ち負かすことが出来ない。
有名っていうのは理由があって有名なんだよ。
その有名を御前は打ち負かすことが出来ない。
>>659
そんなのおまえの選択次第じゃねえかw
そんなのおまえの選択次第じゃねえかw
さっさと「ぼくのつくったきやくがゆうめいなやつよりもすぐれてるんだ」って
言って負け宣言すればいいのにｗ
言って負け宣言すればいいのにｗ
これからコードを書く人は、
>>659のような思考停止はせずに、
決め事についてちゃんと理由を考慮して
判断するようにしてくださいね。
>>659のマネをしていると
ググってコピペしただけで仕事した気になって、
レビューで問題を指摘されたら
「有名なコードからコピーしたんだい！僕は悪くない！」
とか喚き出す似非プログラマになっちゃいますよ。
>>659のような思考停止はせずに、
決め事についてちゃんと理由を考慮して
判断するようにしてくださいね。
>>659のマネをしていると
ググってコピペしただけで仕事した気になって、
レビューで問題を指摘されたら
「有名なコードからコピーしたんだい！僕は悪くない！」
とか喚き出す似非プログラマになっちゃいますよ。
一文字変数が問題ないのは、
すでに結論でてるだろｗ
その上で、有名な規約でも
認められてるって言ってるんだ。
一文字どうしても禁止っていう規約は
もう手詰まりだよ？（笑）
すでに結論でてるだろｗ
その上で、有名な規約でも
認められてるって言ってるんだ。
一文字どうしても禁止っていう規約は
もう手詰まりだよ？（笑）
おいおい、「クソな規約」っていうのは
最初っからクソだって認めてただろ？
クソな規約があるんだ、一体どうすればいいんだ！
従うしかないだろ。
って流れだっただろｗ
最初っからクソだって認めてただろ？
クソな規約があるんだ、一体どうすればいいんだ！
従うしかないだろ。
って流れだっただろｗ
これって結局嘘だったのか・・・
54 名前：仕様書無しさん[sage] 投稿日：2013/03/24(日) 14:47:42.69
大体仕事の場合は、一文字の変数名はカウンタを含めて、殆どコーディング規約で禁止されている。
54 名前：仕様書無しさん[sage] 投稿日：2013/03/24(日) 14:47:42.69
大体仕事の場合は、一文字の変数名はカウンタを含めて、殆どコーディング規約で禁止されている。
>>668
バカだから劣化した車輪の再発明が大好きなんだよな
バカだから劣化した車輪の再発明が大好きなんだよな
え、まさか、
「コーディング規約は世界に1つあれば十分」
だと本気で思ってるのか！？
頭わるっ！
「コーディング規約は世界に1つあれば十分」
だと本気で思ってるのか！？
頭わるっ！
>>673
君のような頭の悪い人間は何文字変数だろうがプログラムを書くべきじゃないと思う。
君のような頭の悪い人間は何文字変数だろうがプログラムを書くべきじゃないと思う。
生存期間が短い場合に一文字変数が問題ないという理由。
生存期間が短いので、その変数を宣言しているコードが近くにある。
そのため、今変数が何を意味しているかすぐに分かる。
そして、i, j, kなどは、慣習として一時的な数値として使うことが
知られている。そのため一文字であっても何のための変数かが明確。
略みたいなもの。意味のない名前ではない。
生存期間が短いので、その変数を宣言しているコードが近くにある。
そのため、今変数が何を意味しているかすぐに分かる。
そして、i, j, kなどは、慣習として一時的な数値として使うことが
知られている。そのため一文字であっても何のための変数かが明確。
略みたいなもの。意味のない名前ではない。
一文字変数がダメな理由
俺が読んだ入門書にそう書いてあったから。
俺が読んだ入門書にそう書いてあったから。
特に新人は、大企業になればなるほど、
しっかりとしたコーディング規約が会社にある（ように見える）ほど
外部のコーディング規約を参照するべき。
でないと、そのコーディング規約が妥当であるかわからない。
会社のだめな規約を押し付けられ、それが外部で通用しないものであることを
知らずに、技術者としてだめにさせられてしまう。
例えば世の中には関数を連番で管理するとか
一文字の変数名は絶対にダメとか意味不明な規約を作っている所が結構ある。
ダメな規約というのはその根拠が書かれていない。結論だけしか書かれていない。
ちゃんとした規約には、そうしたそういう規約を作ったかの根拠が書かれてある。
コードを書く人に絶対やってほしいこと。
しっかりとしたコーディング規約が会社にある（ように見える）ほど
外部のコーディング規約を参照するべき。
でないと、そのコーディング規約が妥当であるかわからない。
会社のだめな規約を押し付けられ、それが外部で通用しないものであることを
知らずに、技術者としてだめにさせられてしまう。
例えば世の中には関数を連番で管理するとか
一文字の変数名は絶対にダメとか意味不明な規約を作っている所が結構ある。
ダメな規約というのはその根拠が書かれていない。結論だけしか書かれていない。
ちゃんとした規約には、そうしたそういう規約を作ったかの根拠が書かれてある。
コードを書く人に絶対やってほしいこと。
特に新人は、大企業になればなるほど、
しっかりとしたコーディング規約が会社にある（ように見える）ほど
外部のコーディング規約を参照するべき。
でないと、そのコーディング規約が妥当であるかわからない。
会社のだめな規約を押し付けられ、それが外部で通用しないものであることを
知らずに、技術者としてだめにさせられてしまう。
ましてや、外部のコーディング規約を単に有名だからというだけで
金科玉条のように信じてしまうのは技術者としての死を意味する。
例えば世の中には関数を連番で管理するとか
一文字の変数名はループ変数ならオッケーとか意味不明な規約を作っている所が結構ある。
ダメな技術者というのは規約の理由について考えない。好き嫌い、有名無名で判断する。
ちゃんとした技術者は、そうしたそういう規約を作った理由についてきちんと考察し、
規約を作った人の意見を真摯に受け止める。
コードを書く人に絶対やってほしいこと。
しっかりとしたコーディング規約が会社にある（ように見える）ほど
外部のコーディング規約を参照するべき。
でないと、そのコーディング規約が妥当であるかわからない。
会社のだめな規約を押し付けられ、それが外部で通用しないものであることを
知らずに、技術者としてだめにさせられてしまう。
ましてや、外部のコーディング規約を単に有名だからというだけで
金科玉条のように信じてしまうのは技術者としての死を意味する。
例えば世の中には関数を連番で管理するとか
一文字の変数名はループ変数ならオッケーとか意味不明な規約を作っている所が結構ある。
ダメな技術者というのは規約の理由について考えない。好き嫌い、有名無名で判断する。
ちゃんとした技術者は、そうしたそういう規約を作った理由についてきちんと考察し、
規約を作った人の意見を真摯に受け止める。
コードを書く人に絶対やってほしいこと。
有名な規約って実質デファクトスタンダードだからな
俺自身は別に一文字の変数がいいとかダメとかはいわないけれど、
会社のコーディング規約がいいかどうかわからないので
外部の有名なコーディング規約を参照しろと言っているだけなんだ。
このことに誰も反論はないだろうね。
外部の有名なコーディング規約の中に一文字の変数は
場合によってはOKと書かれていたんだ。
俺の主張じゃないよ。外部の有名なコーディング規約の中に
書かれていたという事実を書いてるだけだよ。
会社のコーディング規約がいいかどうかわからないので
外部の有名なコーディング規約を参照しろと言っているだけなんだ。
このことに誰も反論はないだろうね。
外部の有名なコーディング規約の中に一文字の変数は
場合によってはOKと書かれていたんだ。
俺の主張じゃないよ。外部の有名なコーディング規約の中に
書かれていたという事実を書いてるだけだよ。
外部の有名なコーディング規約が正しいとは限らないけれど、
3つ調べて3つとも書いてあったんだ。
いや、俺が一文字の変数を場合によって認めろと言ってるわけじゃない。
書いてある者は書いてある仕方ない。
それに対して、俺は明確な反論はできないだけだ
ちなみにその3つの外部の有名なコーディング規約とは
>>433（Oracle）
>>436（Scott W. Ambler）
>>440（Sun Microsystems ）
だよ。
俺の会社、みんなもそうだろうけど、
ここまで大きい会社じゃないんでね。
説得力の違いを感じるよ。
3つ調べて3つとも書いてあったんだ。
いや、俺が一文字の変数を場合によって認めろと言ってるわけじゃない。
書いてある者は書いてある仕方ない。
それに対して、俺は明確な反論はできないだけだ
ちなみにその3つの外部の有名なコーディング規約とは
>>433（Oracle）
>>436（Scott W. Ambler）
>>440（Sun Microsystems ）
だよ。
俺の会社、みんなもそうだろうけど、
ここまで大きい会社じゃないんでね。
説得力の違いを感じるよ。
書いてあることが必ずしも正しいとは限らないじゃないか！
そういって、会社の規約を否定された。
そういって、会社の規約を否定された。
>>683 >>684
もちろんそれは否定しないよ。
一般的な規約を併せて参考にする必要はあるだろう。
ただし>>433のOracleの規約は文の書き方の説明であってa,b,cはただの例。
規約としてa,b,cの使用がOKとは書いてない。
もちろんそれは否定しないよ。
一般的な規約を併せて参考にする必要はあるだろう。
ただし>>433のOracleの規約は文の書き方の説明であってa,b,cはただの例。
規約としてa,b,cの使用がOKとは書いてない。
1文字変数なんてどうでもいいが
Oracleの規約とSunの規約って、どっちも実体はJLS規約なんじゃないの？
Oracleの規約とSunの規約って、どっちも実体はJLS規約なんじゃないの？
>>686
> 規約としてa,b,cの使用がOKとは書いてない。
残念。書いてあったｗ
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367
・Identifier Type
Variables
・Rules for Naming
Except for variables, all instance, class, and class constants are in mixed case
a lowercase first letter. Internal words start with capital letters. Variable names should
not start with underscore _ or dollar sign $ characters, even though both are allowed.
Variable names should be short yet meaningful. The choice of a variable name should
be mnemonic- that is, designed to indicate to the casual observer the intent of its use.
One-character variable names should be avoided except for temporary "throwaway"
variables.
Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.
・Examples
int i;
char c;
float myWidth;
> 規約としてa,b,cの使用がOKとは書いてない。
残念。書いてあったｗ
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367
・Identifier Type
Variables
・Rules for Naming
Except for variables, all instance, class, and class constants are in mixed case
a lowercase first letter. Internal words start with capital letters. Variable names should
not start with underscore _ or dollar sign $ characters, even though both are allowed.
Variable names should be short yet meaningful. The choice of a variable name should
be mnemonic- that is, designed to indicate to the casual observer the intent of its use.
One-character variable names should be avoided except for temporary "throwaway"
variables.
Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.
・Examples
int i;
char c;
float myWidth;
書いてない
↓
書いてあった
↓
み、みとめんぞ！
↓
書いてあった
↓
み、みとめんぞ！
>>688
>One-character variable names should be avoided except for temporary "throwaway"
>variables.
ってのは
一時的な使い捨て変数は1文字推奨
とかじゃなくて
歴史的経緯からこういう使われ方がされてるから例外にしてやるよ
ぐらいな意味だと思うが。
>One-character variable names should be avoided except for temporary "throwaway"
>variables.
ってのは
一時的な使い捨て変数は1文字推奨
とかじゃなくて
歴史的経緯からこういう使われ方がされてるから例外にしてやるよ
ぐらいな意味だと思うが。
>>691
そんなに脳内ボクシングが楽しいなら、一生やってなw
そんなに脳内ボクシングが楽しいなら、一生やってなw
695 ：仕様書無しさん：2013/03/31(日) 15:20:53.10
一文字禁止派がまともな反論できてなくて笑った
>>692
一時的な使い捨て以外は避けろって書いてあるな。avoidだし。
一時的な使い捨て以外は避けろって書いてあるな。avoidだし。
throw awayと書いてあるから、
ループ変数なら何でもオッケーというわけでもないな。
ほとんど意味のないダミー変数みたいなものならいいってことだろ。
5行10行とスコープがあって処理の重要なところに使われているようなら
普通はthrow awayなんて言わない罠
ループ変数なら何でもオッケーというわけでもないな。
ほとんど意味のないダミー変数みたいなものならいいってことだろ。
5行10行とスコープがあって処理の重要なところに使われているようなら
普通はthrow awayなんて言わない罠
>>695 めくら？
普通に英語を読める人なら
>One-character variable names should be avoided except for temporary "throwaway" variables.
を「許可」とは読まないな。
一文字変数は禁止だが、あまりにもどうでもいい変数なら強制はしない、という意味だろう。
>One-character variable names should be avoided except for temporary "throwaway" variables.
を「許可」とは読まないな。
一文字変数は禁止だが、あまりにもどうでもいい変数なら強制はしない、という意味だろう。
莫大な人数の不特定多数のプログラマに守ってほしい言語標準のコーディング規約だから、
歴史的経緯を優先してカウンタ変数に1文字を許さざるを得ないだろう。
そうしないとその時点で「規約違反」のコードばかりになってしまうから。
ところが開発企業内や開発チーム内で、これから書くコードのためのコーディング規約なら、
歴史的経緯は横において、これから書くコードはループ変数も含めて意味のある名前を付けましょう、
というのは組織での規則としてアリだと思う。
「言語標準の規約で厳格な禁止をされていないから、
どんな開発組織内ローカルの規約も許されるべきだ、
むしろ推奨すべきだ」
みたいな発想をするのって、よほど組織的な開発の経験がない人じゃないかな？
歴史的経緯を優先してカウンタ変数に1文字を許さざるを得ないだろう。
そうしないとその時点で「規約違反」のコードばかりになってしまうから。
ところが開発企業内や開発チーム内で、これから書くコードのためのコーディング規約なら、
歴史的経緯は横において、これから書くコードはループ変数も含めて意味のある名前を付けましょう、
というのは組織での規則としてアリだと思う。
「言語標準の規約で厳格な禁止をされていないから、
どんな開発組織内ローカルの規約も許されるべきだ、
むしろ推奨すべきだ」
みたいな発想をするのって、よほど組織的な開発の経験がない人じゃないかな？
結局「み、みとめんぞ！」の流れｗ
>>692
機械翻訳な。歴史的な経緯なんか語ってないからｗ
変数を除いて、すべてのインスタンス、クラス、およびクラス定数は、大文字と小文字が混在されている
小文字の最初の文字。内部の単語は大文字で始まる。変数名は、すべきである
両方が許可されていても、_やドル記号（$）文字をアンダースコアーで開始しない。
変数名は短くまだ有意義であると考える。変数名の選択はすべきである
こと呼び名つまり、余所目その使用の意図に示すために設計されています。
一文字の変数名は、一時的な"使い捨て"以外は避けるべきである
変数。
c、d、および文字のE;一時変数のための共通の名前は、J、K、m、nは整数のiです。
機械翻訳な。歴史的な経緯なんか語ってないからｗ
変数を除いて、すべてのインスタンス、クラス、およびクラス定数は、大文字と小文字が混在されている
小文字の最初の文字。内部の単語は大文字で始まる。変数名は、すべきである
両方が許可されていても、_やドル記号（$）文字をアンダースコアーで開始しない。
変数名は短くまだ有意義であると考える。変数名の選択はすべきである
こと呼び名つまり、余所目その使用の意図に示すために設計されています。
一文字の変数名は、一時的な"使い捨て"以外は避けるべきである
変数。
c、d、および文字のE;一時変数のための共通の名前は、J、K、m、nは整数のiです。
結局、一時的な使い捨てなら
OKってことなのか？
一時的な使い捨てでもNGなのか？
誰かの意見ではなく、Oracleのコーディング規約には
なんてかいてあるのさ？
わかってて言ってるけどｗ
OKってことなのか？
一時的な使い捨てでもNGなのか？
誰かの意見ではなく、Oracleのコーディング規約には
なんてかいてあるのさ？
わかってて言ってるけどｗ
>>703
おまえ、本物の馬鹿だな。このスレでの議論はいつからOracle前提になったよ？
おまえ、本物の馬鹿だな。このスレでの議論はいつからOracle前提になったよ？
規約策定時に決まったこと
↓
今も変わっていない。
↓
今でも有効。
それぐらい分かれよｗ
↓
今も変わっていない。
↓
今でも有効。
それぐらい分かれよｗ
英単語の意味まで変えようとしだしたぞｗ
言語提供者による規約はより多くの言語ユーザに貢献してもらうためのツールだが、
組織のコーディング規約っていうのは、>>708みたいなバカを追い出すためのツールでもある。
その意味で、一文字変数禁止というコーディング規約は
組織のコーディング規約としての機能を十分に果たしている
という結論ですね。
組織のコーディング規約っていうのは、>>708みたいなバカを追い出すためのツールでもある。
その意味で、一文字変数禁止というコーディング規約は
組織のコーディング規約としての機能を十分に果たしている
という結論ですね。
本当に一文字がだめなら「"使い捨て" 以外は避けるべき」って
わざわざ書かないはずだよ。
それなのにダブルクォート付きで書いてるってことは
それは極めて重要であるということ。
使い捨てなら使っていいよとわざわざ書いてあるんだよ。
わざわざ書かないはずだよ。
それなのにダブルクォート付きで書いてるってことは
それは極めて重要であるということ。
使い捨てなら使っていいよとわざわざ書いてあるんだよ。
>>710
> 変数名は短くまだ有意義であると考える。変数名の選択はすべきである
> こと呼び名つまり、余所目その使用の意図に示すために設計されています。
> 一文字の変数名は、一時的な"使い捨て"以外は避けるべきである
> 変数。
これ読んで、お前は 一時的な使い捨てでも避けるべき だと思ったの？
お前にとっては、
一時的な"使い捨て"以外は避けるべき ＝ 一時的な使い捨てでも避けるべき
なの？
> 変数名は短くまだ有意義であると考える。変数名の選択はすべきである
> こと呼び名つまり、余所目その使用の意図に示すために設計されています。
> 一文字の変数名は、一時的な"使い捨て"以外は避けるべきである
> 変数。
これ読んで、お前は 一時的な使い捨てでも避けるべき だと思ったの？
お前にとっては、
一時的な"使い捨て"以外は避けるべき ＝ 一時的な使い捨てでも避けるべき
なの？
>>711
社畜君？
社畜君？
ワロタｗ
701 名前：仕様書無しさん[sage] 投稿日：2013/03/31(日) 15:45:02.43
結局「み、みとめんぞ！」の流れｗ
701 名前：仕様書無しさん[sage] 投稿日：2013/03/31(日) 15:45:02.43
結局「み、みとめんぞ！」の流れｗ
>>716 わざわざ立てたの？
>>543にあった。
このスレ的には、
組織という狭い世界の中にとどまるな。
一般的に日本のソフトウェア技術は低いところが多い。
世界の常識（この場合はコーディング規約）をしれ。
って結論で終わりだな。
組織という狭い世界の中にとどまるな。
一般的に日本のソフトウェア技術は低いところが多い。
世界の常識（この場合はコーディング規約）をしれ。
って結論で終わりだな。
720 ：仕様書無しさん：2013/03/31(日) 16:27:17.42
み、みとめんぞ！
仕事でこれからコードを書くって人は、
社外のコードを読んで欲しいと思うね。
一流のオープンソースプロジェクトの
ソースコードなら簡単に読めるんだから。
どうせお前の会社なんて、技術力で一流に
かなう会社じゃないだろう？
そうすれば、一文字変数なんて普通に
使われてるってわかるはずなんだ。
社外のコードを読んで欲しいと思うね。
一流のオープンソースプロジェクトの
ソースコードなら簡単に読めるんだから。
どうせお前の会社なんて、技術力で一流に
かなう会社じゃないだろう？
そうすれば、一文字変数なんて普通に
使われてるってわかるはずなんだ。
このスレ的には、
組織という狭い世界の中にとどまるな。
一般的に日本のソフトウェア技術は低いところが多い。
世界の常識（この場合はコーディング規約）をしれ。
その上で、言語策定者によるコーディング規約の理由を考え、
自分のタスクにおいて適用すべきかどうか考えて運用しよう。
Oracleが禁止の例外としているからといって、
自分のチームでもオッケーだという短絡的な発想はやめよう。
って結論で終わりだな。
組織という狭い世界の中にとどまるな。
一般的に日本のソフトウェア技術は低いところが多い。
世界の常識（この場合はコーディング規約）をしれ。
その上で、言語策定者によるコーディング規約の理由を考え、
自分のタスクにおいて適用すべきかどうか考えて運用しよう。
Oracleが禁止の例外としているからといって、
自分のチームでもオッケーだという短絡的な発想はやめよう。
って結論で終わりだな。
間違っても、>>721 のように多数派を盲信するような態度は取らず、
何故彼等はそのようなコーディングスタイルを採用しているのか、
自組織ではどのようなコーディングスタイルにすべきか、
広い視野で考えよう。
何故彼等はそのようなコーディングスタイルを採用しているのか、
自組織ではどのようなコーディングスタイルにすべきか、
広い視野で考えよう。
組織のコーディング規約のほとんどは
なぜそのようなコーディング規約を採用したかの
理由が書いていない。
理由なくてルールが独り歩きしている。
こういうのは100%アウト。
そして多くは規約を作った人が「俺が理解できないから使うな」に
なっていることが多い。
これ覚えておくといいよ。
なぜそのようなコーディング規約を採用したかの
理由が書いていない。
理由なくてルールが独り歩きしている。
こういうのは100%アウト。
そして多くは規約を作った人が「俺が理解できないから使うな」に
なっていることが多い。
これ覚えておくといいよ。
多数派少数派関係なく、盲信するなでいいだろ
なんで、多数派をそんなに敵視するんだろうか？
組織には、組織の人間は多いが、
組織以外の人間は少ない。
組織にとって、多数派とは組織の人なんだけどな。
組織の人、盲信すんなよｗ
なんで、多数派をそんなに敵視するんだろうか？
組織には、組織の人間は多いが、
組織以外の人間は少ない。
組織にとって、多数派とは組織の人なんだけどな。
組織の人、盲信すんなよｗ
>>725
>多数派を盲信するな。
これは書いたが、
>少数派こそが正しいんだ。
これは書いてない。捏造するなクソ野郎。
まあ一文字変数書いてドヤ顔するようなバカは、この程度の人間ってことだな。
よくわかったよ。
>多数派を盲信するな。
これは書いたが、
>少数派こそが正しいんだ。
これは書いてない。捏造するなクソ野郎。
まあ一文字変数書いてドヤ顔するようなバカは、この程度の人間ってことだな。
よくわかったよ。
1文字変数が許される技術的理由： 社名
これ笑ったわww
これ笑ったわww
一文字変数が許される技術的根拠があるということで
随分前から結論でてるんだけどな。
「み、みとめんぞ！」
随分前から結論でてるんだけどな。
「み、みとめんぞ！」
そうだな。だめなのはダメな組織だけだな。
有名で優秀な組織もあるしな。OracleやSunみたいに。
有名で優秀な組織もあるしな。OracleやSunみたいに。
一文字禁止って言ってる人さあ
どうせまともな理由だせないんだから、素直に間違ってたこと認めちゃいなよ。
会社でも独り善がりなコーディング規約作って嫌われてんでしょ？
どうせまともな理由だせないんだから、素直に間違ってたこと認めちゃいなよ。
会社でも独り善がりなコーディング規約作って嫌われてんでしょ？
>>734
相当な古株でなければコーディング規約の作成になんて関われないぞ
相当な古株でなければコーディング規約の作成になんて関われないぞ
736 ：仕様書無しさん：2013/03/31(日) 17:43:08.03
とりあえず高度なコードを書けｗ
話はそれからだ
話はそれからだ
やるじゃん
Sun名義の規約とOracle名義の規約を別カウントしちゃうぐらいだから
変数の文字数なんて1文字でも2文字だと強弁できるだろw
変数の文字数なんて1文字でも2文字だと強弁できるだろw
一行目と二行目に
関連性が全くないんだがｗ
関連性が全くないんだがｗ
>>739は1文字禁止派の自演
そろそろエイプリルフールの準備するか。
>>692,>>699
思い込みで勝手にニュアンスを付加するな。
正確に訳すと、以下のようになる。
One-character variable names should be avoided except for temporary "throwaway" variables.
一文字名の変数の使用は避けるべき。ただし、一時的な「使い捨て」変数は除く。
思い込みで勝手にニュアンスを付加するな。
正確に訳すと、以下のようになる。
One-character variable names should be avoided except for temporary "throwaway" variables.
一文字名の変数の使用は避けるべき。ただし、一時的な「使い捨て」変数は除く。
わかりにくいコードを書くから、長くて自己説明的な名前が必要になるんだよな。
初心者が全ての行に無意味なコメントを入れるのと同じ理屈だ。
初心者が全ての行に無意味なコメントを入れるのと同じ理屈だ。
>742
なんで、一時的な「使い捨て」変数は除くんだよ？
なんで、一時的な「使い捨て」変数は除くんだよ？
リンク先ページの文章書いたやつに聞け。
というか、この程度の英文まともに読めない奴らが、ああでもない、こうでもない言い合ってるようじゃ、
結論永遠に出ないだろうな。
というか、この程度の英文まともに読めない奴らが、ああでもない、こうでもない言い合ってるようじゃ、
結論永遠に出ないだろうな。
＼
￣ヽ、 _ノ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
｀'ｰ '´
○
Ｏ
}ﾞi ｢i
ﾉ | l | ヽ
ト､ | | | l { /}
ヽ ヽ 〈､ i、 | |．ﾑ / !
ヽ ヾ,､_rL | | _r｝∠>=‐' /
＼ ： ∵爻､ ヽ |! jﾞｿ゛．： ． /
ヽ ∵ ヾk l||! _}i}∴ ∵ ／
＼ ∵{=､, cr炎ro _fiヾk： ：／
ヽ∠__ﾉｧｔ-､ /,仝yハ ∠rtゝ-‐ ' と思うサソリであった
ゞﾆヾﾊ. }K以ﾑハ //＞ ′
＞、ヽ }ﾆﾈﾈ冫：i／∠、
/へ＼ `ｰ八‐‐'_／' へヽ
〃 ＞,才¨＾¨弋ヽニニヾk
{/,＜- '/ / ＼＼ ｢|ｌ|
|{ ﾄi′ > 〉 {.{ｌ}
|l /7 ／／ !|
{{ 〈ﾊ} z'_／ k!
￣ヽ、 _ノ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
｀'ｰ '´
○
Ｏ
}ﾞi ｢i
ﾉ | l | ヽ
ト､ | | | l { /}
ヽ ヽ 〈､ i、 | |．ﾑ / !
ヽ ヾ,､_rL | | _r｝∠>=‐' /
＼ ： ∵爻､ ヽ |! jﾞｿ゛．： ． /
ヽ ∵ ヾk l||! _}i}∴ ∵ ／
＼ ∵{=､, cr炎ro _fiヾk： ：／
ヽ∠__ﾉｧｔ-､ /,仝yハ ∠rtゝ-‐ ' と思うサソリであった
ゞﾆヾﾊ. }K以ﾑハ //＞ ′
＞、ヽ }ﾆﾈﾈ冫：i／∠、
/へ＼ `ｰ八‐‐'_／' へヽ
〃 ＞,才¨＾¨弋ヽニニヾk
{/,＜- '/ / ＼＼ ｢|ｌ|
|{ ﾄi′ > 〉 {.{ｌ}
|l /7 ／／ !|
{{ 〈ﾊ} z'_／ k!
>>742
なにその中学レベルの訳文w
A should be B except for C の
except for Cは「Cは除く」よりは「Cの場合はその限りではない」のほうが原語の意味に近い。
もし「Cは除く」ぐらい強い除外をするのであれば、
A except for C should be B.
もう少し柔らかめな表現なら
A other than C should be B.
という英文になる。こんぐらいわかっとけ。
なにその中学レベルの訳文w
A should be B except for C の
except for Cは「Cは除く」よりは「Cの場合はその限りではない」のほうが原語の意味に近い。
もし「Cは除く」ぐらい強い除外をするのであれば、
A except for C should be B.
もう少し柔らかめな表現なら
A other than C should be B.
という英文になる。こんぐらいわかっとけ。
748 ：仕様書無しさん：2013/04/01(月) 08:03:47.84
>>747
＞except for Cは「Cは除く」よりは「Cの場合はその限りではない」のほうが原語の意味に近い。
勝手に自説に有利なように訳語を捻じ曲げるな。
そういう意味になる場合もならない場合もなる。
特にそういうニュアンスを示す表現が前後に無いのであれば、
except forはプレーンな「除く」という言葉を使うべき。
＞except for Cは「Cは除く」よりは「Cの場合はその限りではない」のほうが原語の意味に近い。
勝手に自説に有利なように訳語を捻じ曲げるな。
そういう意味になる場合もならない場合もなる。
特にそういうニュアンスを示す表現が前後に無いのであれば、
except forはプレーンな「除く」という言葉を使うべき。
>>747
英語につよくてカッケーです(笑)
英語につよくてカッケーです(笑)
まあどっちにしても除かれてるのなら使っていいってことじゃん。
そう。
この文が意味するところは、それ以上でもそれ以下でもない。
この文が意味するところは、それ以上でもそれ以下でもない。
いや、歴史的経緯でしかたなく見逃してあげる。というニュアンスが含まれているのだよ
>>750
ナイス中学英語！
ナイス中学英語！
しょせん参考にすぎないオラクルコーディング規約で「使っていい」とかマジで思考停止してるんだね。
なんという馬鹿w
なんという馬鹿w
元々が社内ルールで禁止されている！じゃなかったっけ？
「社内ルールで禁止されている」で思考停止しているから
その他のルールを見てみましょうねってなったわけだ。
その他のルールを見てみましょうねってなったわけだ。
で、終着点は756？
どう突っ込んだらいいのやら。。
どう突っ込んだらいいのやら。。
760 ：仕様書無しさん：2013/04/01(月) 22:47:36.37
756が一文字禁止派の結論か
結局み、みとめないぞ！だったな
結局み、みとめないぞ！だったな
思考停止馬鹿はこいつが一番最初かな。
54 名前：仕様書無しさん[sage] 投稿日：2013/03/24(日) 14:47:42.69
大体仕事の場合は、一文字の変数名はカウンタを含めて、殆どコーディング規約で禁止されている。
54 名前：仕様書無しさん[sage] 投稿日：2013/03/24(日) 14:47:42.69
大体仕事の場合は、一文字の変数名はカウンタを含めて、殆どコーディング規約で禁止されている。
762 ：仕様書無しさん：2013/04/01(月) 22:53:31.34
おもしろいなこのスレ
新人に読ませたい
新人に読ませたい
仕事で決まってるからって、思考停止しちゃだめだよ。
もっと広い範囲で調べなきゃ。
もっと広い範囲で調べなきゃ。
>>754
訳者による過剰な深読みって奴だな。
訳者による過剰な深読みって奴だな。
でも道路標識の「ただし軽車両、原付を除く」は明確な許可だもんね。
「ただし一時的な使い捨て変数を除く」が使っていいことにならないなら日本語の認識がおかしいね。
「ただし一時的な使い捨て変数を除く」が使っていいことにならないなら日本語の認識がおかしいね。
「専用スレがあるものは専用スレを使用する」という明確なルールがあるのに、
従わずこのスレを荒らし続けるキチガイが日本語の認識を語るなど
笑わせてくれる。
従わずこのスレを荒らし続けるキチガイが日本語の認識を語るなど
笑わせてくれる。
向こうのスレに流れをコピペしておいたから、以後向こうでやれ
それが人にものを頼む態度だと思ってるのか？
一文字禁止スレみたら英語とハムスターの話で持ちきりだった
話変えるけど
例えば
if(a==60 || a==70 || a==80 ||……){
if(b==120){
なんかの処理
}
}
みたいなコードを
array[] = {60, 70, 80,……}
for(int i=0; i<array_length; i++){
if(a==array[i] && b==120){
なんかの処理
break;
}
}
みたいに書いてほしいな
片っ端からif文で条件を打ち込まれると読みにくい時がある
例えば
if(a==60 || a==70 || a==80 ||……){
if(b==120){
なんかの処理
}
}
みたいなコードを
array[] = {60, 70, 80,……}
for(int i=0; i<array_length; i++){
if(a==array[i] && b==120){
なんかの処理
break;
}
}
みたいに書いてほしいな
片っ端からif文で条件を打ち込まれると読みにくい時がある
>>770
直感的にループじゃないものをループにするなよ。
そういうときは
array[] = {60, 70, 80,……}
if(in_array(a, array) && b==120){
なんかの処理
}
}
こんなかんじだろ。
もしくは /^(60|70|80|・・・)$/ みたいな正規表現にするとか。
言語の標準関数にないなら外部ライブラリ使うか自分で作ればいいだけなのに
たまに言語標準機能だけで頑張ろうとする人いるよな。
直感的にループじゃないものをループにするなよ。
そういうときは
array[] = {60, 70, 80,……}
if(in_array(a, array) && b==120){
なんかの処理
}
}
こんなかんじだろ。
もしくは /^(60|70|80|・・・)$/ みたいな正規表現にするとか。
言語の標準関数にないなら外部ライブラリ使うか自分で作ればいいだけなのに
たまに言語標準機能だけで頑張ろうとする人いるよな。
多機能メソッドは個々の機能を別メソッドに委託するだけのメソッドにしてほしい
メソッド単位でUTできないと分岐が多くなってしぬわ
メソッド単位でUTできないと分岐が多くなってしぬわ
ぶっちゃけ一文字変数名云々より、1メソッドにreturnは1つしか書いてはいけないみたいな糞ルールとかのほうが数百倍きつい
>>770
俺Javaマだけど、俺ならその最初のifをprivateなstaticメソッドとかに置く事が多いかな
isナンチャラ(a)みたいな、なにを判定してるかをコメントで説明せずメソッド名で説明するような感じにコードで書く
staticに置くのは、インスタンスに依存しないユーティリティ的な処理だから
もしくは、aがオブジェクトで、判定はOの実装に依存するなら、oのクラスに判定処理を定義してあげるってのもありだと思う
俺Javaマだけど、俺ならその最初のifをprivateなstaticメソッドとかに置く事が多いかな
isナンチャラ(a)みたいな、なにを判定してるかをコメントで説明せずメソッド名で説明するような感じにコードで書く
staticに置くのは、インスタンスに依存しないユーティリティ的な処理だから
もしくは、aがオブジェクトで、判定はOの実装に依存するなら、oのクラスに判定処理を定義してあげるってのもありだと思う
>>774
これ書こうとしたらもう書いてあった
これ書こうとしたらもう書いてあった
>>770
>>171でも言われてるけど、基本的な構文を利用してアクロバティックに実装するのは、
意図が読み取りづらくなるからできるだけ避けたほうがいいと思う(レベルの低いマが関わる環境だと得に)。
慣れてる人はその手の実装みてもすぐ意図を理解できるから困らないけど、不慣れな人だとそこで思考が一旦停止し兼ねない。
もちろん、それ(ループによる判定)だけを行うメソッドとして定義されてたら混乱はしないから問題ないよ。
そういう書き方が問題になるのは、長い処理の一部に、そういう書き方のコードを混ぜちゃうケースね。
まぁ、別メソッドにわけるなら、素直に書いたほうが後々の確認や修正も楽だと思うけどな。
private static boolean isReasonable(int a) {
if (a == 60)
return true;
if (a == 70)
return true;
if (a == 80)
return true;
：
return false;
}
みたいな
一つのifに詰め込める判定処理は、必ず「なにを判定してるのか」っていう名前が付けれる処理がいくつかあるはずだから、
可読性が悪いif文になってる場合は、判定だけをメソッド分割すると、後々見直すときやテストで理解しやすいコードになるよ。
メソッド単体でのテストもしやすくなるし。
>>171でも言われてるけど、基本的な構文を利用してアクロバティックに実装するのは、
意図が読み取りづらくなるからできるだけ避けたほうがいいと思う(レベルの低いマが関わる環境だと得に)。
慣れてる人はその手の実装みてもすぐ意図を理解できるから困らないけど、不慣れな人だとそこで思考が一旦停止し兼ねない。
もちろん、それ(ループによる判定)だけを行うメソッドとして定義されてたら混乱はしないから問題ないよ。
そういう書き方が問題になるのは、長い処理の一部に、そういう書き方のコードを混ぜちゃうケースね。
まぁ、別メソッドにわけるなら、素直に書いたほうが後々の確認や修正も楽だと思うけどな。
private static boolean isReasonable(int a) {
if (a == 60)
return true;
if (a == 70)
return true;
if (a == 80)
return true;
：
return false;
}
みたいな
一つのifに詰め込める判定処理は、必ず「なにを判定してるのか」っていう名前が付けれる処理がいくつかあるはずだから、
可読性が悪いif文になってる場合は、判定だけをメソッド分割すると、後々見直すときやテストで理解しやすいコードになるよ。
メソッド単体でのテストもしやすくなるし。
aがなんか途中でOとかoになってるけど、脳内補完で…(´・ω・｀)
>>773
それで思い出したけど、メソッドの中のコードを書く順番
function foo(value) {
1. 引数などのチェック
2. 引数およびインスタンス変数を”参照だけ”して処理を行う
3. インスタンス変数を書き換える
}
このパターンを守れない場合もあるけれど、
原則としてこの順番で書くようにするといいよ。
逆に言うとこの1〜3を混ぜて書かないほうがいい。
理由は、1でチェックを行うので2の処理を行うときは
不正な値がないことを保証できる。
2では、参照だけして処理を行う。処理結果はローカル変数に入れておく。
この時点でインスタンスの状態を変更しないことが重要。
なぜなら2の処理の途中でインスタンスの状態を変更した後で、実行時エラーが起きた時、
適切に処理しないとインスタンスの状態がよくわからないことになってしまうから。
そして3で、ローカル変数に記録された結果をインスタンス変数に代入する。
ただの代入なので実行時エラーが発生する確率は低い。
トランザクションのコミット処理みたいなもんだね。
2で処理を実行するけれどデータは反映されない。3をやって初めてデータが反映される。
それで思い出したけど、メソッドの中のコードを書く順番
function foo(value) {
1. 引数などのチェック
2. 引数およびインスタンス変数を”参照だけ”して処理を行う
3. インスタンス変数を書き換える
}
このパターンを守れない場合もあるけれど、
原則としてこの順番で書くようにするといいよ。
逆に言うとこの1〜3を混ぜて書かないほうがいい。
理由は、1でチェックを行うので2の処理を行うときは
不正な値がないことを保証できる。
2では、参照だけして処理を行う。処理結果はローカル変数に入れておく。
この時点でインスタンスの状態を変更しないことが重要。
なぜなら2の処理の途中でインスタンスの状態を変更した後で、実行時エラーが起きた時、
適切に処理しないとインスタンスの状態がよくわからないことになってしまうから。
そして3で、ローカル変数に記録された結果をインスタンス変数に代入する。
ただの代入なので実行時エラーが発生する確率は低い。
トランザクションのコミット処理みたいなもんだね。
2で処理を実行するけれどデータは反映されない。3をやって初めてデータが反映される。
>>777
それもダラダラして長いんで、
private static boolean isReasonable(int a) {
array[] = {60, 70, 80,……} ;
return in_array(a, array);
}
の方がいい。
isReasonableっていうのは、何の判定か？を示す意味がある、
in_arrayは判定処理そのものを簡略化する意味がある。
使い方の意味が違うんで両方やって良い。
あと、in_arrayであれば、ユーティリティクラスに
static、publicで定義するのでテストも書きやすい。
in_array、つまりisReasonableの処理のうち数値配列の”定義”を除いた
処理の部分がテスト済み状態になるので残りのテストが減る（不要になる）
個人的にin_arrayをテストしたならば、上に書いたisReasonableはテストは必要ないと思うな。
なぜなら、array[]の定義内容をテストすることになるわけで、
単にisReasonableとテストコードの配列内容が一致しているか？（＝ちゃんとコピペしたか？）
というくだらないテストになるから。
それもダラダラして長いんで、
private static boolean isReasonable(int a) {
array[] = {60, 70, 80,……} ;
return in_array(a, array);
}
の方がいい。
isReasonableっていうのは、何の判定か？を示す意味がある、
in_arrayは判定処理そのものを簡略化する意味がある。
使い方の意味が違うんで両方やって良い。
あと、in_arrayであれば、ユーティリティクラスに
static、publicで定義するのでテストも書きやすい。
in_array、つまりisReasonableの処理のうち数値配列の”定義”を除いた
処理の部分がテスト済み状態になるので残りのテストが減る（不要になる）
個人的にin_arrayをテストしたならば、上に書いたisReasonableはテストは必要ないと思うな。
なぜなら、array[]の定義内容をテストすることになるわけで、
単にisReasonableとテストコードの配列内容が一致しているか？（＝ちゃんとコピペしたか？）
というくだらないテストになるから。
>>779
チェックが頭なのはそうだと思うけど、インスタンスフィールドの変更タイミングはケースバイケースじゃないかな？
インスタンス変数の変更の途中で例外抜けがあり、
かつメソッドの外で復旧するような特殊な場合ならそういう処理にする必要はあると思うが、
そもそも復旧できる例外ならtry-catch句を内部にもってその場で復旧を試みるべきだろうし、
そうでないケースなら、インスタンス状態を保つこと自体に意味ない事の方が多そうな気がする
(意味があるような場合、クラス設計とか別の部分にもっと大きな問題があると思う)
なので、2、3は、必ずそのケースにする必要はないと思うな
あと、773は、結果保持用のローカル変数を用意して、分岐して分岐して保持用変数に値をつめて、
最後に保持結果を返す、みたいな糞コードをdisってるんだ…
結果が判明した時点でreturnすれば無駄なifネストやら else if とか書かなくてすむのに、
糞ルールのせいでひたすらに読み辛いコードになる、みたいな
チェックが頭なのはそうだと思うけど、インスタンスフィールドの変更タイミングはケースバイケースじゃないかな？
インスタンス変数の変更の途中で例外抜けがあり、
かつメソッドの外で復旧するような特殊な場合ならそういう処理にする必要はあると思うが、
そもそも復旧できる例外ならtry-catch句を内部にもってその場で復旧を試みるべきだろうし、
そうでないケースなら、インスタンス状態を保つこと自体に意味ない事の方が多そうな気がする
(意味があるような場合、クラス設計とか別の部分にもっと大きな問題があると思う)
なので、2、3は、必ずそのケースにする必要はないと思うな
あと、773は、結果保持用のローカル変数を用意して、分岐して分岐して保持用変数に値をつめて、
最後に保持結果を返す、みたいな糞コードをdisってるんだ…
結果が判明した時点でreturnすれば無駄なifネストやら else if とか書かなくてすむのに、
糞ルールのせいでひたすらに読み辛いコードになる、みたいな
>>780
いや、なんつーか、そのレベルの実装の良し悪しなんて好みのレベルだし、
可読性に関わるレベルでもないからどうでもいい話だと思うぞ。
JavaやらC#やら使うなら、そのあたりはそもそもコレクションに詰めておいて
containsみたいな処理でやってもいいわけだし、俺々関数を用意するような部分でもない。
ユーティリティ処理を用意して更にコードの共通化を図れ、みたいな話になっちゃうから
この話題の元々の焦点「読み辛いifをどう書き直すか」って所からは少しずれてきてるんじゃないかなって感じる。
いや、なんつーか、そのレベルの実装の良し悪しなんて好みのレベルだし、
可読性に関わるレベルでもないからどうでもいい話だと思うぞ。
JavaやらC#やら使うなら、そのあたりはそもそもコレクションに詰めておいて
containsみたいな処理でやってもいいわけだし、俺々関数を用意するような部分でもない。
ユーティリティ処理を用意して更にコードの共通化を図れ、みたいな話になっちゃうから
この話題の元々の焦点「読み辛いifをどう書き直すか」って所からは少しずれてきてるんじゃないかなって感じる。
783 ：仕様書無しさん：2013/04/02(火) 04:34:53.23
なんや一気に良スレになったな
取り敢えず、インデントはどんなルールでもいいからキッチリつけないと超高確率でバグを量産するハメになる
インデントルールは、行頭のインデントはタブでそれ以外の桁揃えはスペースってやっとけば読む奴が読みやすいタブ幅に合わせて読めるから一番"面倒が無い"
インデントをスペースでやると、書いた奴のインデント幅でしか読めない(桁揃えが混ざるとインデント幅の一括変更が完全な再整形でしか出来ない)
桁揃えにタブ使うと、一々元のタブ幅確認して合わせなきゃ表示が崩れる
インデントにタブとスペース混在させてると最悪で、読む奴が一々元のタブ幅確認しなきゃいかんし、書いた奴のタブ幅でしか読めない
「俺様と同じインデント幅・タブ幅しか許さん」って意見が頭オカシイと思うなら、行頭のインデントはタブでそれ以外の桁揃えはスペースが一番他人にやさしい
他人に読ませる気がないならどんなルールでも良いけれど、他人に読ませる気が有るなら他人にやさしいインデントルールを使うべき
インデントルールは、行頭のインデントはタブでそれ以外の桁揃えはスペースってやっとけば読む奴が読みやすいタブ幅に合わせて読めるから一番"面倒が無い"
インデントをスペースでやると、書いた奴のインデント幅でしか読めない(桁揃えが混ざるとインデント幅の一括変更が完全な再整形でしか出来ない)
桁揃えにタブ使うと、一々元のタブ幅確認して合わせなきゃ表示が崩れる
インデントにタブとスペース混在させてると最悪で、読む奴が一々元のタブ幅確認しなきゃいかんし、書いた奴のタブ幅でしか読めない
「俺様と同じインデント幅・タブ幅しか許さん」って意見が頭オカシイと思うなら、行頭のインデントはタブでそれ以外の桁揃えはスペースが一番他人にやさしい
他人に読ませる気がないならどんなルールでも良いけれど、他人に読ませる気が有るなら他人にやさしいインデントルールを使うべき
配列は遅いから使うなとか言われてた頃が懐かしいな
むしろIDE使ってるならコードフォーマットを手作業でやるな
そんな作業機械にやらせりゃいい
インデントの調整とか俺々コードスタイルとかは時間の無駄
どうしても手作業での整形が必要なコードの場合、
整形しないと読みづらくなるコードを書いてしまった事を悔やみながら
部分的にフォーマッター切って整形しよう
そんな作業機械にやらせりゃいい
インデントの調整とか俺々コードスタイルとかは時間の無駄
どうしても手作業での整形が必要なコードの場合、
整形しないと読みづらくなるコードを書いてしまった事を悔やみながら
部分的にフォーマッター切って整形しよう
インデントはコードを見やすくするために行うものであって、
インデントすることが目的じゃない。
コードフォーマッタでやる機械的なインデントが
必ずしも正解（見やすい）とは思わないんだよね。
めちゃくちゃなのを一気になおすのにはいいけれど。
例えば、関数定義の行は { で改行いれるというよくあるルールに従うとこうなるけど
obj.addCallback(function (a, b, c) {
いういろ
いういろ
いういろ
});
もしクロージャの中身が短くてたくさん並べるならこっちのほうがいいでしょ？
obj1.addCallback(function () { return a; });
obj2.addCallback(function () { return b; });
obj.3addCallback(function () { return c; });
もしこれをフォーマッタにかけるとこうなる
obj1.addCallback(function () {
return a;
});
obj2.addCallback(function () {
return b;
});
obj.3addCallback(function () {
return c;
});
インデントすることが目的じゃない。
コードフォーマッタでやる機械的なインデントが
必ずしも正解（見やすい）とは思わないんだよね。
めちゃくちゃなのを一気になおすのにはいいけれど。
例えば、関数定義の行は { で改行いれるというよくあるルールに従うとこうなるけど
obj.addCallback(function (a, b, c) {
いういろ
いういろ
いういろ
});
もしクロージャの中身が短くてたくさん並べるならこっちのほうがいいでしょ？
obj1.addCallback(function () { return a; });
obj2.addCallback(function () { return b; });
obj.3addCallback(function () { return c; });
もしこれをフォーマッタにかけるとこうなる
obj1.addCallback(function () {
return a;
});
obj2.addCallback(function () {
return b;
});
obj.3addCallback(function () {
return c;
});
場合によってはこうなるかもしれない。
obj1.addCallback(
function () {
return a;
}
);
obj2.addCallback(
function () {
return b;
}
);
obj.3addCallback(
function () {
return c;
}
);
obj1.addCallback(
function () {
return a;
}
);
obj2.addCallback(
function () {
return b;
}
);
obj.3addCallback(
function () {
return c;
}
);
いちいち変数に代入しまくるのやめてください(^q^)
短いルーチンはインデント無しでエディタで書いてコピペしちゃうな
視線の移動は少ないほうが良い
同じ段に一行しかなくて、右側がはみ出ているとか馬鹿みたいだから
s/\t/ /g
s/^ *//
と同じことをしょっちゅうやってる
視線の移動は少ないほうが良い
同じ段に一行しかなくて、右側がはみ出ているとか馬鹿みたいだから
s/\t/ /g
s/^ *//
と同じことをしょっちゅうやってる
おっと、もちろんセーブはしないよ
これからコード書く奴に勧められる事書けよ・・・
IDEのフォーマッタに任せる or 変則的なルールを使わずインデント使う、とかさ
IDEのフォーマッタに任せる or 変則的なルールを使わずインデント使う、とかさ
フォーマットルールを書き出してドキュメント化しても守れないどころか読む能力すら無い奴の方が多いし
「俺が見やすいと思うからルールを守らない」みたいな馬鹿まで出てくる始末
機械的にやるのは、そういう人による判断なんかを介させないって意味ですごく重要
>>787
目先しか見てない人には伝わらないかもしれないけど、
内容に合わせてフォーマットルールを増やすとか誰も幸せになれんぞ
全部文書化してメンバー全員に徹底できるレベルなら構わんが、ニュアンスでそういう事やるのはだめだろ
つか、見やすいと思えないならまずフォーマッターの設定を見直そう
フォーマッターで対応できないようなフォーマットルールを、メンバー全員に徹底するとか夢物語だ
「俺が見やすいと思うからルールを守らない」みたいな馬鹿まで出てくる始末
機械的にやるのは、そういう人による判断なんかを介させないって意味ですごく重要
>>787
目先しか見てない人には伝わらないかもしれないけど、
内容に合わせてフォーマットルールを増やすとか誰も幸せになれんぞ
全部文書化してメンバー全員に徹底できるレベルなら構わんが、ニュアンスでそういう事やるのはだめだろ
つか、見やすいと思えないならまずフォーマッターの設定を見直そう
フォーマッターで対応できないようなフォーマットルールを、メンバー全員に徹底するとか夢物語だ
>>794
その通り
ルールがあるんだったら守る。議論しない
議論している間にコーディングは終わる
自分流をやりたければ自分の目の前だけにする
具体的には、
インデントがあると読み難くて嫌になるなら
全行を左揃えにする仕組みを
自分用に
ととのえる。そんなに難しくない
インデントを付けるのは、人ではなくコンピュータ任せなのだから
インデントを外すのもコンピュータに任せる
その通り
ルールがあるんだったら守る。議論しない
議論している間にコーディングは終わる
自分流をやりたければ自分の目の前だけにする
具体的には、
インデントがあると読み難くて嫌になるなら
全行を左揃えにする仕組みを
自分用に
ととのえる。そんなに難しくない
インデントを付けるのは、人ではなくコンピュータ任せなのだから
インデントを外すのもコンピュータに任せる
>>794
> フォーマッターで対応できないようなフォーマットルールを、メンバー全員に徹底するとか夢物語だ
典型的な手段と目的が逆になっている例。
見やすく書くのが目的であって
フォーマットルールを作るのが目的ではない。
見やすく書くというのは技術。
技術力が高くなれば、自然と見やすい書き方ができる。
見やすい書き方が出来ない奴は技術も低いわけでバグも多いし
コードも無駄が多く冗長。
そういうのはコードレビューするわけで
見やすい書き方の指摘もそこでやる。
> フォーマッターで対応できないようなフォーマットルールを、メンバー全員に徹底するとか夢物語だ
典型的な手段と目的が逆になっている例。
見やすく書くのが目的であって
フォーマットルールを作るのが目的ではない。
見やすく書くというのは技術。
技術力が高くなれば、自然と見やすい書き方ができる。
見やすい書き方が出来ない奴は技術も低いわけでバグも多いし
コードも無駄が多く冗長。
そういうのはコードレビューするわけで
見やすい書き方の指摘もそこでやる。
コミット用共通フォーマッタと各自マイフォーマッタを持っておいて、チェックアウト時にマイフォーマッタでフォーマット、コミット時に共通フォーマッタでフォーマットすれば皆幸せ。
で、少しずつコメント位置がずれていくw
俺々フォーマッターは個人開発でやる分にはいいけど、共同開発は自分用フォーマットルールとか作ってはいけない。
共通フォーマットルールの設定が提供されてないプロジェクトの場合は、グループと相談して導入を検討したほうがいい。
あと、見やすいとかそういうくだらない理由で、手動でコードの整形するのはマージの邪魔になるだからやめたほうがいい。
自動整形がかかった状態でも可読性高いコードは書ける。書けない奴はスキルがない奴だ。
これからコードを書くって人は、手動で整形なんてやるべきじゃない。
手動で整形する必要が全く無いとは言わんが、そういうレアケースならコメントで部分的に制御する仕組みとか使えばいい。
だが、そういうテクニックはこれからコード書く人が率先して覚えておくべき事ではない。
共通フォーマットルールの設定が提供されてないプロジェクトの場合は、グループと相談して導入を検討したほうがいい。
あと、見やすいとかそういうくだらない理由で、手動でコードの整形するのはマージの邪魔になるだからやめたほうがいい。
自動整形がかかった状態でも可読性高いコードは書ける。書けない奴はスキルがない奴だ。
これからコードを書くって人は、手動で整形なんてやるべきじゃない。
手動で整形する必要が全く無いとは言わんが、そういうレアケースならコメントで部分的に制御する仕組みとか使えばいい。
だが、そういうテクニックはこれからコード書く人が率先して覚えておくべき事ではない。
正直一文字変数の話よりどうでもいい
フォーマットは何が正解で何が間違いかというはっきりとした答えがないもの。
たとえば一行の文字数を考えて見ればいい。
一行80文字というルールを作る。じゃあ81文字だったら？
強制的に改行を入れたほうが見やすいのか？
そうとは限らないだろ？
1文字ぐらいなら見逃したほうがいいし、もしかしたら
インデントが深すぎるという証拠なのかもしれない。
だとしたらコードの書き方を工夫するほうがいいかもしれない。
インデントが深すぎるという問題を直さないで、
フォーマッターにかけて、80文字以内だからOKです。でいいと思う？
見やすく書くのが目的であって、ルールを厳守するのは目的に反するんだよ。
もちろん、インデントはスペース4つで、一行の目安とかはいるけど、
フォーマットは厳密に守るべきものじゃないでしょ。
そもそもコードのフォーマットって難しい技術か？
動くコードを書くことに比べたら相当簡単だと思うんだが？
動くコードが書ける人がコード書いたら、コードも最低限のフォーマットになってるはず。
それすらできない人間は教育するか切り捨てたほうがいいでしょ？
たとえば一行の文字数を考えて見ればいい。
一行80文字というルールを作る。じゃあ81文字だったら？
強制的に改行を入れたほうが見やすいのか？
そうとは限らないだろ？
1文字ぐらいなら見逃したほうがいいし、もしかしたら
インデントが深すぎるという証拠なのかもしれない。
だとしたらコードの書き方を工夫するほうがいいかもしれない。
インデントが深すぎるという問題を直さないで、
フォーマッターにかけて、80文字以内だからOKです。でいいと思う？
見やすく書くのが目的であって、ルールを厳守するのは目的に反するんだよ。
もちろん、インデントはスペース4つで、一行の目安とかはいるけど、
フォーマットは厳密に守るべきものじゃないでしょ。
そもそもコードのフォーマットって難しい技術か？
動くコードを書くことに比べたら相当簡単だと思うんだが？
動くコードが書ける人がコード書いたら、コードも最低限のフォーマットになってるはず。
それすらできない人間は教育するか切り捨てたほうがいいでしょ？
>>802
> 理想論だね。20人中10人がレベル低かったら
> 10人分のコードレビューすんのか？時間的に無理だろ
コードの最低限度のフォーマットもできない
素人が20人中10人もいて、それでまともに開発できると本気で思ってるの？
明らかにデスマになることが目に見えてるよ。
20人中10人が素人のプロジェクトに、どうぞフォーマッター導入してください。
コードレビューもないけれど、フォーマットさえできていれば
君は大丈夫だと思うのでしょう？
> 理想論だね。20人中10人がレベル低かったら
> 10人分のコードレビューすんのか？時間的に無理だろ
コードの最低限度のフォーマットもできない
素人が20人中10人もいて、それでまともに開発できると本気で思ってるの？
明らかにデスマになることが目に見えてるよ。
20人中10人が素人のプロジェクトに、どうぞフォーマッター導入してください。
コードレビューもないけれど、フォーマットさえできていれば
君は大丈夫だと思うのでしょう？
フォーマットができないやつは 全員低レベルであってますよ？
見やすいコードの書き方が書いてある本を与えても理解できないレベルなんでしょ？
フォーマットすらできない人間のプログラムが
きちんと動くとかありえませんね。
見やすいコードの書き方が書いてある本を与えても理解できないレベルなんでしょ？
フォーマットすらできない人間のプログラムが
きちんと動くとかありえませんね。
フォーマッタすら制御できない人間のプログラムが
きちんと動くとかありえませんね。
きちんと動くとかありえませんね。
一行80文字という決まりだけど、
一文字だけ多かった今回は改行いれないほうが見やすいなぁ。
読みやすさ重視で今回だけ例外にしちゃえ。
ってことができるフォーマッターの制御方法教えて下さいｗ
コンピュータは汚くても何の問題もない。
人間が見やすいと感じるかをコンピュータが判断しろと？
AIが必要になってくるよｗ
一文字だけ多かった今回は改行いれないほうが見やすいなぁ。
読みやすさ重視で今回だけ例外にしちゃえ。
ってことができるフォーマッターの制御方法教えて下さいｗ
コンピュータは汚くても何の問題もない。
人間が見やすいと感じるかをコンピュータが判断しろと？
AIが必要になってくるよｗ
809 ：仕様書無しさん：2013/04/04(木) 02:57:48.02
久しぶりに来たらフォーマット論争になってる
また隔離スレ立てるかｗ
>>808
微妙なラインが有る場合はそのまま放置だろ
俺々フォーマッタと共通フォーマッタ使う場合、見づらいって文句言う奴は俺々フォーマッタ弄って直せばいいだけ
共通フォーマッタを全員の好みに合致するようになんて考えだしたら何の意味もない
最適なフォーマットアルゴリズムを求めて俺々フォーマッタに学習機能だの何だの搭載したいならすればいい
つか情報屋のくせにAIに夢見過ぎてないか？
微妙なラインが有る場合はそのまま放置だろ
俺々フォーマッタと共通フォーマッタ使う場合、見づらいって文句言う奴は俺々フォーマッタ弄って直せばいいだけ
共通フォーマッタを全員の好みに合致するようになんて考えだしたら何の意味もない
最適なフォーマットアルゴリズムを求めて俺々フォーマッタに学習機能だの何だの搭載したいならすればいい
つか情報屋のくせにAIに夢見過ぎてないか？
フォーマットするのは簡単な作業で
フォーマットすらできんヤツにロクなコードを書けない。
どちらも「明文化されたフォーマットルールに従って」という前提。
具体的なルールも示さない>>803を納得させるフォーマットなんて
どんな超絶ハカーにも無理w
フォーマットすらできんヤツにロクなコードを書けない。
どちらも「明文化されたフォーマットルールに従って」という前提。
具体的なルールも示さない>>803を納得させるフォーマットなんて
どんな超絶ハカーにも無理w
この話いつまでやるんだよ…
切り捨てられる低能って可哀想だね...
フォーマットなんてプロジェクト毎の規約にだまって従えばいいじゃないか。
なければ、メジャーなものを参考にして真似すればいいし。
色々ソースをいじってれば、流儀も様々だから、わざわざ俺流にこだわる程アホらしいことはないぞ。
それとも皆まともにインデントも出来ない新人レベルの人とばかり仕事してるのか？
なければ、メジャーなものを参考にして真似すればいいし。
色々ソースをいじってれば、流儀も様々だから、わざわざ俺流にこだわる程アホらしいことはないぞ。
それとも皆まともにインデントも出来ない新人レベルの人とばかり仕事してるのか？
int zero = 0;
はやめろ
はやめろ
それ面白い
読み進むと zero++; だの zero = 1; だのが出てきて頭が痛くなるパターンですねわかります
if( zero != 0 ) zero=0;
if要らねえｗｗｗ
if( $sex -eq " daisuki" ){
echo " yari man"
exit 0
}
else{
echo " uso tuki"
exit 1
}
(○´U`○
echo " yari man"
exit 0
}
else{
echo " uso tuki"
exit 1
}
(○´U`○
>>825
リテラルをロジック内にハードコードすんな
リテラルをロジック内にハードコードすんな
>>819
フォーマットはメジャーな規約に合わせるってのは賛成だよ。
だけど、参考程度にに留める。絶対に守られければいけないルールじゃない
例えば○○の後に改行を入れる（見やすくするために）という規約があっても
改行を入れないほうがもっと見やすくなる場合が稀にある。
そういう場合には規約を守らないほうがもっと優れたコードになる。
規約を守らないほうが見やすいコードになるってのは例外的なので
フォーマッターでそこまで対応するのは不可能。
せいぜい特殊なタグで囲まれた領域はフォーマッターの処理対象外にするぐらい。
（特殊なタグで囲むという手段はタグが邪魔で見にくくなるので根本的解決にならない）
だからフォーマットは最低限の目安的な規約を作って、見やすくなるならば規約を守らなくてもOK
フォーマッターは原則として使わない。（使うのはゴミコードを修正するときだけ）
フォーマットはメジャーな規約に合わせるってのは賛成だよ。
だけど、参考程度にに留める。絶対に守られければいけないルールじゃない
例えば○○の後に改行を入れる（見やすくするために）という規約があっても
改行を入れないほうがもっと見やすくなる場合が稀にある。
そういう場合には規約を守らないほうがもっと優れたコードになる。
規約を守らないほうが見やすいコードになるってのは例外的なので
フォーマッターでそこまで対応するのは不可能。
せいぜい特殊なタグで囲まれた領域はフォーマッターの処理対象外にするぐらい。
（特殊なタグで囲むという手段はタグが邪魔で見にくくなるので根本的解決にならない）
だからフォーマットは最低限の目安的な規約を作って、見やすくなるならば規約を守らなくてもOK
フォーマッターは原則として使わない。（使うのはゴミコードを修正するときだけ）
技術も俺流ならいっぱいいる
>>827
それをオナニーと言う
それをオナニーと言う
本当に技術が一流の奴なら書き方もしっかりしてると思う
まともなフォーマットでかけない奴は無能といったのが
よっぽど気に触ったのかねぇ？
よっぽど気に触ったのかねぇ？
>>827ってプログラミングはじめて2年目ぐらいによくなる病気にかかってるね。
836 ：仕様書無しさん：2013/04/05(金) 21:10:03.16
プロ2病
http://qiita.com/items/e65c8847e57a5329f336
id_10 =
books
.project(books[:category_id])
.group(books[:category_id])
.having(books[:id].count.eq(10))
.take(1)
categories
.project(Arel.star)
.where(categories[:id].eq(id_10))
# => TypeError: Cannot visit Arel::SelectManager
categories
.project(Arel.star)
.where(categories[:id].eq(id_10.ast))
.to_sql
# => SELECT * FROM "categories" WHERE "categories"."id" = SELECT "books"."category_id" 省略
たとえばこんなコードな。整形したらこうなるだろう。
id_10 = books.project(books[:category_id]).group(books[:category_id])
.having(books[:id].count.eq(10)).take(1)
categories.project(Arel.star).where(categories[:id].eq(id_10))
# => TypeError: Cannot visit Arel::SelectManager
categories.project(Arel.star).where(categories[:id].eq(id_10.ast)).to_sql
見ての通り前よりもコードが見難くなってる。
フォーマッターを使ったことがあれば、こうなることぐらいわかるだろう。
それがわからないで、機械整形（機械翻訳みたいなもんｗ）に任せられる奴は
ほんとうの意味で綺麗なコードを書けないのだろう。無頓着なだけ。
id_10 =
books
.project(books[:category_id])
.group(books[:category_id])
.having(books[:id].count.eq(10))
.take(1)
categories
.project(Arel.star)
.where(categories[:id].eq(id_10))
# => TypeError: Cannot visit Arel::SelectManager
categories
.project(Arel.star)
.where(categories[:id].eq(id_10.ast))
.to_sql
# => SELECT * FROM "categories" WHERE "categories"."id" = SELECT "books"."category_id" 省略
たとえばこんなコードな。整形したらこうなるだろう。
id_10 = books.project(books[:category_id]).group(books[:category_id])
.having(books[:id].count.eq(10)).take(1)
categories.project(Arel.star).where(categories[:id].eq(id_10))
# => TypeError: Cannot visit Arel::SelectManager
categories.project(Arel.star).where(categories[:id].eq(id_10.ast)).to_sql
見ての通り前よりもコードが見難くなってる。
フォーマッターを使ったことがあれば、こうなることぐらいわかるだろう。
それがわからないで、機械整形（機械翻訳みたいなもんｗ）に任せられる奴は
ほんとうの意味で綺麗なコードを書けないのだろう。無頓着なだけ。
>>834
viですか？ vimですか？両方出すのでどちらでもいいですけど。
http://ex-vi.sourceforge.net/
http://ex-vi.cvs.sourceforge.net/ex-vi/ex-vi/
vim
http://vim.svn.sourceforge.net/viewvc/vim/vim7/src/main.c?revision=1889&view=markup
一体これのどこがスタイルに癖があるのでしょうか？
viですか？ vimですか？両方出すのでどちらでもいいですけど。
http://ex-vi.sourceforge.net/
http://ex-vi.cvs.sourceforge.net/ex-vi/ex-vi/
vim
http://vim.svn.sourceforge.net/viewvc/vim/vim7/src/main.c?revision=1889&view=markup
一体これのどこがスタイルに癖があるのでしょうか？
>>839
いいですか？ 今はフォーマッターの話をしています。
ガキ臭いから話のすり替え早めましょう。
メソッドチェーンが世の中で使われている以上その批判は的外れにしかなりません。
では本題。メソッドチェーンを使った場合、
見やすいコードがフォーマッターで崩れます。
間違っていますか？
いいですか？ 今はフォーマッターの話をしています。
ガキ臭いから話のすり替え早めましょう。
メソッドチェーンが世の中で使われている以上その批判は的外れにしかなりません。
では本題。メソッドチェーンを使った場合、
見やすいコードがフォーマッターで崩れます。
間違っていますか？
>>840
> では本題。メソッドチェーンを使った場合、
> 見やすいコードがフォーマッターで崩れます。
これが間違い。
メソッドチェーンが悪いのではなく、分かりにくくなるようなコードでも
何でもメソッドチェーンで書く人間が悪いのだよ。
んで、フォーマッターの話をしたいのはお前だけ。
> では本題。メソッドチェーンを使った場合、
> 見やすいコードがフォーマッターで崩れます。
これが間違い。
メソッドチェーンが悪いのではなく、分かりにくくなるようなコードでも
何でもメソッドチェーンで書く人間が悪いのだよ。
んで、フォーマッターの話をしたいのはお前だけ。
フォーマッターを使っている人は
a = 123
bbbbb = 4568
ccc = 90
みたいにコードが=で綺麗に揃ってて見やすいんだよね。
なぜならそういうなるようにフォーマッターをカスタマイズするから。
フォーマッターに出来ないことはないからね。
フォーマッターでイコールがずれるなんてないない。
逆に揃っちゃう。
フォーマッターを使ってる人と
使ってない人ではコードの見やすさが違う。
このようにイコールで揃った見やすいコードは
フォーマッターを使っているからでしょ。
えぇ、全てわかっていていってますが何か？
a = 123
bbbbb = 4568
ccc = 90
みたいにコードが=で綺麗に揃ってて見やすいんだよね。
なぜならそういうなるようにフォーマッターをカスタマイズするから。
フォーマッターに出来ないことはないからね。
フォーマッターでイコールがずれるなんてないない。
逆に揃っちゃう。
フォーマッターを使ってる人と
使ってない人ではコードの見やすさが違う。
このようにイコールで揃った見やすいコードは
フォーマッターを使っているからでしょ。
えぇ、全てわかっていていってますが何か？
https://github.com/khiltd/Abacus
コロンやイコールの位置で揃えてくれるツール
揃ってないのと揃ってるのでは
やっぱり揃ってるほうが見やすい。（リンク先に比較画像あり）
でもこういうのはエディタのプラグインだから
成り立つのであって、フォーマッターで制御は不可能だろうね。
コロンやイコールの位置で揃えてくれるツール
揃ってないのと揃ってるのでは
やっぱり揃ってるほうが見やすい。（リンク先に比較画像あり）
でもこういうのはエディタのプラグインだから
成り立つのであって、フォーマッターで制御は不可能だろうね。
比較画像は意図的過ぎる
そういう風に書く奴いるんだよなぁ
何故見やすいと思っているのか分からないんだが
代入の左右の式を離すと追いかけるのが面倒だからあまり離さないで欲しいんだけどね
そういう風に書く奴いるんだよなぁ
何故見やすいと思っているのか分からないんだが
代入の左右の式を離すと追いかけるのが面倒だからあまり離さないで欲しいんだけどね
>>843,844
ん？ コロンやイコールの桁揃えは、エディタで(手作業で)編集するものではないのかな。
そのくらいのコードに対する配慮は、経験を積んだプログラマなら当たり前だと思う。
他人様の書いた大量の汚いコードを引き継いだ時に、一括整形を目的として
フォーマッタを利用するのはアリだと思うけど、今回の話題は自分のコードだよね。
ちなみに、自分はインデントはタブのみ、タブ幅４文字、かつ80桁以内というスタイル。
http://play.island.ac/codepaste/code?id=27
ん？ コロンやイコールの桁揃えは、エディタで(手作業で)編集するものではないのかな。
そのくらいのコードに対する配慮は、経験を積んだプログラマなら当たり前だと思う。
他人様の書いた大量の汚いコードを引き継いだ時に、一括整形を目的として
フォーマッタを利用するのはアリだと思うけど、今回の話題は自分のコードだよね。
ちなみに、自分はインデントはタブのみ、タブ幅４文字、かつ80桁以内というスタイル。
http://play.island.ac/codepaste/code?id=27
まさか、
AST見てメソッドチェーンが設定値以上ならば、
インデントレベルを上げて
1つのメソッド呼び出しを1行に分割して
出力する、
程度のコードも書けないでドヤってるの？
AST見てメソッドチェーンが設定値以上ならば、
インデントレベルを上げて
1つのメソッド呼び出しを1行に分割して
出力する、
程度のコードも書けないでドヤってるの？
>>849
ASTだけを見ればコード生成できるのは、コードジェネレータの場合だよ。
コードフォーマッタを設計するには、コメントの整形(桁揃え)も検討しないとね。
もちろん元のコードスタイルをできるだけ壊さないよう配慮して整形しなければならない。
また、すでに>>787,788が指摘しているように、コードを美しく整形するには、
論理的な判断というよりもケースバイケースで対処する人間的な感性が必要になる。
こんなこともあるから、>>844のようなエディタのプラグインを除けば、
全自動でコードを清書してくれるフォーマッタの設計って、とっても難しい課題なんだけどなあ....
ASTだけを見ればコード生成できるのは、コードジェネレータの場合だよ。
コードフォーマッタを設計するには、コメントの整形(桁揃え)も検討しないとね。
もちろん元のコードスタイルをできるだけ壊さないよう配慮して整形しなければならない。
また、すでに>>787,788が指摘しているように、コードを美しく整形するには、
論理的な判断というよりもケースバイケースで対処する人間的な感性が必要になる。
こんなこともあるから、>>844のようなエディタのプラグインを除けば、
全自動でコードを清書してくれるフォーマッタの設計って、とっても難しい課題なんだけどなあ....
>>851
＞ASTだけを見ればコード生成できるのは、コードジェネレータの場合だよ。
＞コードフォーマッタを設計するには、コメントの整形(桁揃え)も検討しないとね。
お前、フォーマッタ実装したことないだろ？ぷ
＞ASTだけを見ればコード生成できるのは、コードジェネレータの場合だよ。
＞コードフォーマッタを設計するには、コメントの整形(桁揃え)も検討しないとね。
お前、フォーマッタ実装したことないだろ？ぷ
人間が手動で書くコードはパターンや判断基準がある
その程度のフォーマッタを書けないやつは廃業したほうがいい
その程度のフォーマッタを書けないやつは廃業したほうがいい
>>840
メソッドチェーンを綺麗に整形するルールを書けばいい
>>852
851がトンチンカンなこと言ってるのは同感だけど、ルールがシンプルなら構文木の解析は必須じゃないからAST持ってるかは微妙じゃね
メソッドチェーンを綺麗に整形するルールを書けばいい
>>852
851がトンチンカンなこと言ってるのは同感だけど、ルールがシンプルなら構文木の解析は必須じゃないからAST持ってるかは微妙じゃね
糞汚いコードを書く馬鹿でも、フォーマッターで最低基準に揃えれるメリットの方が
自称天才()マが素晴らしいコードをフォーマッターで並に戻されるデメリットよりも優先されることだわ
なぜなら、ウンコーダーにも解析しやすいコード書いてもウンコーダーは読み解けず適当に見繕ってコピペするだけだが、
素晴らしいコード書けるくらいにスキルがある奴なら、多少汚いコードでも読み解くくらいできる
個人開発でコードフォーマットを徹底するのは存分に拘るべきだと思うが、
仕事で共同開発する場合は、汎用のフォーマッターを超えたコードの整形は邪魔以外の何者でもない
扱い辛い技術者カテゴリに所属するような、ちょっとアレなタイプのマとして扱われる人になってしまうだけ
評価に繋がらない部分に拘るのは時間の無駄だし、独りよがりのコードになってたら本末転倒
他の人間から影で「(あいつまた変な手動整形頑張ってるよ…)」って思われるだけ
そんなとこに時間かけるより、UTの実装や重複コードをなくしたりするような
リファクタリングに時間をかけたほうが数百倍メリットあるわ
自称天才()マが素晴らしいコードをフォーマッターで並に戻されるデメリットよりも優先されることだわ
なぜなら、ウンコーダーにも解析しやすいコード書いてもウンコーダーは読み解けず適当に見繕ってコピペするだけだが、
素晴らしいコード書けるくらいにスキルがある奴なら、多少汚いコードでも読み解くくらいできる
個人開発でコードフォーマットを徹底するのは存分に拘るべきだと思うが、
仕事で共同開発する場合は、汎用のフォーマッターを超えたコードの整形は邪魔以外の何者でもない
扱い辛い技術者カテゴリに所属するような、ちょっとアレなタイプのマとして扱われる人になってしまうだけ
評価に繋がらない部分に拘るのは時間の無駄だし、独りよがりのコードになってたら本末転倒
他の人間から影で「(あいつまた変な手動整形頑張ってるよ…)」って思われるだけ
そんなとこに時間かけるより、UTの実装や重複コードをなくしたりするような
リファクタリングに時間をかけたほうが数百倍メリットあるわ
>>855
自称天才マはチーム開発というのが全然見えてないんだよね
経験やスキルが足りないプログラマがいないプロジェクトなんてめったにない
自称天才マは常に自分中心で
スキルが低いやつは切り捨てればいいとか言い出す始末だし
自称天才マはチーム開発というのが全然見えてないんだよね
経験やスキルが足りないプログラマがいないプロジェクトなんてめったにない
自称天才マは常に自分中心で
スキルが低いやつは切り捨てればいいとか言い出す始末だし
>>854
> メソッドチェーンを綺麗に整形するルールを書けばいい
だからそのルールがケースバイケースだって言ってるんでしょ。
コードの綺麗さの判断というのは人間の感性の問題だから、
それをルール化することは出来ないんだよ。
人によって改行入れる場所さえ違っていたりするわけで
そういうものにルールを作るのは不可能
> AST見てメソッドチェーンが設定値以上ならば、
こういうのだって、設定値+1の場合はどうなる？
境界線付近では分割しないほうが見やすい場合があったりするわけで。
> メソッドチェーンを綺麗に整形するルールを書けばいい
だからそのルールがケースバイケースだって言ってるんでしょ。
コードの綺麗さの判断というのは人間の感性の問題だから、
それをルール化することは出来ないんだよ。
人によって改行入れる場所さえ違っていたりするわけで
そういうものにルールを作るのは不可能
> AST見てメソッドチェーンが設定値以上ならば、
こういうのだって、設定値+1の場合はどうなる？
境界線付近では分割しないほうが見やすい場合があったりするわけで。
>>856
チームの話については今は関係ないよ。
コードのフォーマットは、フォーマッターで絶対遵守な規約にするのではなく、
最低限の目安を作って、見やすさのためなら例外もあり
という規約の方がいい。これを皆共通の規約として守りましょう。って
話だから。
チーム開発だからね。規約は守りましょうｗ
結局のところ一文字変数と同じ話だよ。特定の場合において
例外はありというルールもルールとしても問題ない。
チームの話については今は関係ないよ。
コードのフォーマットは、フォーマッターで絶対遵守な規約にするのではなく、
最低限の目安を作って、見やすさのためなら例外もあり
という規約の方がいい。これを皆共通の規約として守りましょう。って
話だから。
チーム開発だからね。規約は守りましょうｗ
結局のところ一文字変数と同じ話だよ。特定の場合において
例外はありというルールもルールとしても問題ない。
>>857
だからそれをフォーマッタに反映させればいいじゃん
>>837の前者のようになるように
>>858
チーム開発はいま関係ないといいながら規約の話出すのは何なん？
チーム開発に規約はあり、フォーマッタはなし、
とかただのおまえの主観であって根拠がない
だからそれをフォーマッタに反映させればいいじゃん
>>837の前者のようになるように
>>858
チーム開発はいま関係ないといいながら規約の話出すのは何なん？
チーム開発に規約はあり、フォーマッタはなし、
とかただのおまえの主観であって根拠がない
1. ifとforを多用したコードを書くのはやめよう。よく使う処理は既に汎用的なものがないか調べよう。
判定や繰り返しは別の解決法がないかを考えよう。
ただし再帰はバグの温床だから、ループの変わりに使うのだけは気をつけて。
2. 重複コードを書くのはやめよう。
同じような処理をする場合共通化を図ろう。
最初から完璧に共通化を図る必要はないが、汎用的に使える処理かは常に検討しながら書こう。
3. 重複コードを減らすためにリファクタリングは必ずやろう。
ちなみに、リファクタリングは多少時間を置いてから見たほうが捗ることもある。
実装直後だと、まだ覚えてるから簡単に読み解ける処理がある。
後からみても仕様がすぐ頭に入るようなコードを心がけておくと、後の修正量が少なくてすむよ。
4. リファクタリングのために単体テストの設計、実装はやろう。
単体テストが作りやすいコードは見通しが良い。できるだけテストと平行して開発するように心がけよう。
動いてるコードを修正するなっていう老害が多い業界だけど、
UTがきちんと実装できていない、書いたコードは読み直せないほど汚いってのが理由だから、
これからコード書く人は、同じ轍は踏まないように、そういった馬鹿発言が飛び出すことのないようなコードを書けるようになろう。
判定や繰り返しは別の解決法がないかを考えよう。
ただし再帰はバグの温床だから、ループの変わりに使うのだけは気をつけて。
2. 重複コードを書くのはやめよう。
同じような処理をする場合共通化を図ろう。
最初から完璧に共通化を図る必要はないが、汎用的に使える処理かは常に検討しながら書こう。
3. 重複コードを減らすためにリファクタリングは必ずやろう。
ちなみに、リファクタリングは多少時間を置いてから見たほうが捗ることもある。
実装直後だと、まだ覚えてるから簡単に読み解ける処理がある。
後からみても仕様がすぐ頭に入るようなコードを心がけておくと、後の修正量が少なくてすむよ。
4. リファクタリングのために単体テストの設計、実装はやろう。
単体テストが作りやすいコードは見通しが良い。できるだけテストと平行して開発するように心がけよう。
動いてるコードを修正するなっていう老害が多い業界だけど、
UTがきちんと実装できていない、書いたコードは読み直せないほど汚いってのが理由だから、
これからコード書く人は、同じ轍は踏まないように、そういった馬鹿発言が飛び出すことのないようなコードを書けるようになろう。
>>858
明記はされてないけどマ板なんだし仕事でコード書く人の話だって考えるのは割と普通だと思う。
チームで開発しないことは昨今じゃ少ないし、このスレで出てる話題の大半はそういうとこに重きを置いてるんじゃないか。
そう考えると、むしろチームに関係の無い話題のほうが関係ないと思うが。
明記はされてないけどマ板なんだし仕事でコード書く人の話だって考えるのは割と普通だと思う。
チームで開発しないことは昨今じゃ少ないし、このスレで出てる話題の大半はそういうとこに重きを置いてるんじゃないか。
そう考えると、むしろチームに関係の無い話題のほうが関係ないと思うが。
>>860
テンプレ候補1
テンプレ候補1
>>857
>それをルール化することは出来ないんだよ。
コードにも落とせず他人に説明もできない気分で決まるようなルールがクソじゃなければなんなんだ。そんなクソルールはゴミ箱へどうぞ
>設定値+1の場合はどうなる？
分割される。特例を作りたいなら特例の条件を明文化して終了。気分的なコードの美しさ(笑)とかはゴミ箱へどうぞ
>それをルール化することは出来ないんだよ。
コードにも落とせず他人に説明もできない気分で決まるようなルールがクソじゃなければなんなんだ。そんなクソルールはゴミ箱へどうぞ
>設定値+1の場合はどうなる？
分割される。特例を作りたいなら特例の条件を明文化して終了。気分的なコードの美しさ(笑)とかはゴミ箱へどうぞ
この手の話題に喧嘩腰になる必要はないと思う。
思うが、こだわりを捨てきれない人間は年取ると確実に老害になるから気をつけような。
グループでの開発においては、機械的に実行されるフォーマットルールに沿たコードでも
見通しがよく保守しやすいようにコーディングするスキルが重要であって、
手動でコードを手直しする間違った職人魂()なんてものは重要じゃないというか、必要でもない。
「ぼくのかんがえたさいきょうにすばらしいコード」を書ける能力は、優れてるコーダーとはイコールではない。
これだけは間違いない。
そんなんばっかやってたら、「扱い辛い変な人」、「関わらないほうがよさそう」ってポジションを獲得できちゃうぞ。
思うが、こだわりを捨てきれない人間は年取ると確実に老害になるから気をつけような。
グループでの開発においては、機械的に実行されるフォーマットルールに沿たコードでも
見通しがよく保守しやすいようにコーディングするスキルが重要であって、
手動でコードを手直しする間違った職人魂()なんてものは重要じゃないというか、必要でもない。
「ぼくのかんがえたさいきょうにすばらしいコード」を書ける能力は、優れてるコーダーとはイコールではない。
これだけは間違いない。
そんなんばっかやってたら、「扱い辛い変な人」、「関わらないほうがよさそう」ってポジションを獲得できちゃうぞ。
複雑なロジックを書いて、コメントで説明するのはやめたほうがいい。
チームには必ず馬鹿が混じり、その馬鹿は他人のコードを考えなしにコピペする。
ロジックだけで読み解けるようなコメントの要らないコードを書けるようになろう。
複雑な機能は処理をメソッドで分け、メソッド名で処理説明を行えるようにしよう。
よく使われるメソッド名や変数名を考える時間を削減するために、色んなソースコードを見て単語を覚えよう。
自分は中学1年時点から英語死んでて英語力2しかないままおっきくなっちゃったけど、
コード書く上で必要になるような単語は人のコードとかで結構覚えたよ。
チームには必ず馬鹿が混じり、その馬鹿は他人のコードを考えなしにコピペする。
ロジックだけで読み解けるようなコメントの要らないコードを書けるようになろう。
複雑な機能は処理をメソッドで分け、メソッド名で処理説明を行えるようにしよう。
よく使われるメソッド名や変数名を考える時間を削減するために、色んなソースコードを見て単語を覚えよう。
自分は中学1年時点から英語死んでて英語力2しかないままおっきくなっちゃったけど、
コード書く上で必要になるような単語は人のコードとかで結構覚えたよ。
そもそもコードの整形と、コードそのものの善し悪しは別物。
整形方法はチーム内で統一出来てればいいだけ。それだけ。
整形方法はチーム内で統一出来てればいいだけ。それだけ。
一つ書き忘れた
javadoc見たいなのはちゃんと書くべきだけど、メソッド中のコードの説明コメントは不要。
コメントが必要な複雑な処理は、コメントで説明しても、馬鹿は読まないし読み解けなくて、
よくわからずにそのままコピペしてくれる。
コメントが必要ないくらいに処理が理解できるような簡単なコードにすることは、長期的に見ると割と重要。
javadoc見たいなのはちゃんと書くべきだけど、メソッド中のコードの説明コメントは不要。
コメントが必要な複雑な処理は、コメントで説明しても、馬鹿は読まないし読み解けなくて、
よくわからずにそのままコピペしてくれる。
コメントが必要ないくらいに処理が理解できるような簡単なコードにすることは、長期的に見ると割と重要。
ウチの業界は仕様書も半端なら設計もしない業界だから
コメントにいろいろ残してる。
この処理は何時来たメールに書いてあった要望だとか。
コメントにいろいろ残してる。
この処理は何時来たメールに書いてあった要望だとか。
ケースバイケースだからフォーマッタ実装できないというバカは
(1) 自分の要求項目すら定式化できない糞エンジニア
(2) 同じコードも気分次第でコロコロフォーマットが変わって周囲を惑わせていることに気付かないアホ
のどちらかだカス
(1) 自分の要求項目すら定式化できない糞エンジニア
(2) 同じコードも気分次第でコロコロフォーマットが変わって周囲を惑わせていることに気付かないアホ
のどちらかだカス
>>866
完全に手段と目的が反対になっている。
ケースバイケースなためフォーマッターが
判断不可能でより見やすくかける例
（これらは実例提示ずみ）が存在する。
それなのに手段のために、目的に反するのに
型にはめることが正しいと思ってる。
まるで自分で判断できないロボット。
物事の判断を機械に決められている。
完全に手段と目的が反対になっている。
ケースバイケースなためフォーマッターが
判断不可能でより見やすくかける例
（これらは実例提示ずみ）が存在する。
それなのに手段のために、目的に反するのに
型にはめることが正しいと思ってる。
まるで自分で判断できないロボット。
物事の判断を機械に決められている。
>>871
> ケースバイケースだからフォーマッタ実装できない
これは正しい。
例 この場合、改行を入れたほうが見やすいかどうか？
obj.setParams({id: 1, name:"test"});
obj.setParams({
id: 1,
name:"test"
});
obj.setParams(
{
id: 1,
name:"test"
}
);
関数の引数がハッシュであれば改行を入れる、インデントするなど具体的なルールを定めてください。
なお、文字が長かったらなどというのは具体的ではないので、
具体的な文字数を言うこと（○文字以上など）
> ケースバイケースだからフォーマッタ実装できない
これは正しい。
例 この場合、改行を入れたほうが見やすいかどうか？
obj.setParams({id: 1, name:"test"});
obj.setParams({
id: 1,
name:"test"
});
obj.setParams(
{
id: 1,
name:"test"
}
);
関数の引数がハッシュであれば改行を入れる、インデントするなど具体的なルールを定めてください。
なお、文字が長かったらなどというのは具体的ではないので、
具体的な文字数を言うこと（○文字以上など）
ケースバイケースなのはいい
その仕様を定義すらできねーのか無能
その仕様を定義すらできねーのか無能
>>876
俺の正解は、見やすいかどうかはケースバイケースで変わるから
ルールは決められないってことだ。
お前にとっての正解は、俺の意見と反対。
つまり、見やすいかどうかはケースバイケースではなく
ルールを決められるってことだろ？
じゃあお前にとっての正解を見せなさいって言ってるんだよ。
なに？お前自分の意見も言えないの？
俺の正解は、見やすいかどうかはケースバイケースで変わるから
ルールは決められないってことだ。
お前にとっての正解は、俺の意見と反対。
つまり、見やすいかどうかはケースバイケースではなく
ルールを決められるってことだろ？
じゃあお前にとっての正解を見せなさいって言ってるんだよ。
なに？お前自分の意見も言えないの？
ルールが決められないって人の
答えは「ルールを決めない」だよ。
ルールが決められな言ってる人は
見事に答えを言ってる。
ルールが決められるって言ってる人は、
そのルールを提示しないと答えを言ってることにならないね。
答えは「ルールを決めない」だよ。
ルールが決められな言ってる人は
見事に答えを言ってる。
ルールが決められるって言ってる人は、
そのルールを提示しないと答えを言ってることにならないね。
>>881
馬鹿はお前だよ。
お前はケースバイケースではなくルールを決められるといった。
ならばその証明をする義務がある。
今は俺の意見は関係なく、お前が見やすいというルールを提示すればいいだけ
その後で、そのルールは本当にどんな場合でも見やすいのか
検証することになる。
馬鹿はお前だよ。
お前はケースバイケースではなくルールを決められるといった。
ならばその証明をする義務がある。
今は俺の意見は関係なく、お前が見やすいというルールを提示すればいいだけ
その後で、そのルールは本当にどんな場合でも見やすいのか
検証することになる。
>>880
お前が言ってるのは、「オレが今思い浮かべた数字が何か当ててみろ」というのと同じだ。
正解はお前しか知らない。オレが何を答えたって、お前は別の数字を「正解」として示せば、オレの答えは「間違い」になる。
なぜなら、本当の正解はお前の脳内にしかない。オレには検証不可能だからだ。
「おまえが納得するフォーマット」ってのはそれと同じぐらいバカ丸出しな問題設定なんだよ。
お前が言ってるのは、「オレが今思い浮かべた数字が何か当ててみろ」というのと同じだ。
正解はお前しか知らない。オレが何を答えたって、お前は別の数字を「正解」として示せば、オレの答えは「間違い」になる。
なぜなら、本当の正解はお前の脳内にしかない。オレには検証不可能だからだ。
「おまえが納得するフォーマット」ってのはそれと同じぐらいバカ丸出しな問題設定なんだよ。
「ケースバイケースで見やすくなるようにする」と言い切るからには
「見やすいと見やすくないの境目となる条件」があるわけだ
そこを数字なり数式なりプログラミング可能なレベルで定義できないとか
全くプログラマに向いてない
ぶっちゃけそういったクライアントの曖昧な要求を
どうにかしてプログラミングするのがプログラマの仕事だろ
プログラマと言えないようなコーダーなら話にならん
「見やすいと見やすくないの境目となる条件」があるわけだ
そこを数字なり数式なりプログラミング可能なレベルで定義できないとか
全くプログラマに向いてない
ぶっちゃけそういったクライアントの曖昧な要求を
どうにかしてプログラミングするのがプログラマの仕事だろ
プログラマと言えないようなコーダーなら話にならん
数学っぽく言い換えると、
俺は「証明できない問題が世の中にある」と言った。
奴は「世の中に証明できない問題はない。証明できない奴が馬鹿なだけ」と言った。
証明できない問題はないというならば、"奴" は証明が難しい問題を
証明してみせるべきだ。（"奴" が馬鹿という答えもあるがｗ）
そしてその後で本当にその証明が正しいか検証するのは当然の話。
俺は「証明できない問題が世の中にある」と言った。
奴は「世の中に証明できない問題はない。証明できない奴が馬鹿なだけ」と言った。
証明できない問題はないというならば、"奴" は証明が難しい問題を
証明してみせるべきだ。（"奴" が馬鹿という答えもあるがｗ）
そしてその後で本当にその証明が正しいか検証するのは当然の話。
コードのフォーマットが見やすいかどうかはケースバイケースだろ
そのルールを作れるって言ってる奴は馬鹿なんじゃないの？
そのルールを作れるって言ってる奴は馬鹿なんじゃないの？
> 俺は「証明できない問題が世の中にある」と言った。
言ってませんね
「ケースバイケースだ」というからには
それは証明できない問題ではない
言ってませんね
「ケースバイケースだ」というからには
それは証明できない問題ではない
もし、そんな完璧なフォーマッターがあれば、
オープンソース（じゃなくてもいいけど）のソフトには、
ユニットテストと同じようにフォーマッターのルールを
つけてるんじゃないのか？
じゃあなぜフォーマッターのルールが（ほとんどか全くか）
見かけないのはなぜ？って疑問にならない？
オープンソース（じゃなくてもいいけど）のソフトには、
ユニットテストと同じようにフォーマッターのルールを
つけてるんじゃないのか？
じゃあなぜフォーマッターのルールが（ほとんどか全くか）
見かけないのはなぜ？って疑問にならない？
>>889
たしかにそのとおり、盲点だった。
何らかのコードがフォーマッターに従っているというのなら
フォーマッターとそのルールが存在するはずだ。
そのルールを適用して、それが本当に見やすいか
検証すればいいだけじゃないか。
まずルールが存在するかどうかだな。
この時点で見つからなければ
そんなルールは作れないって答えになるが
さすがにあるだろｗ
たしかにそのとおり、盲点だった。
何らかのコードがフォーマッターに従っているというのなら
フォーマッターとそのルールが存在するはずだ。
そのルールを適用して、それが本当に見やすいか
検証すればいいだけじゃないか。
まずルールが存在するかどうかだな。
この時点で見つからなければ
そんなルールは作れないって答えになるが
さすがにあるだろｗ
はあ？
「言ってませんね」は
「ケースバイケース」と「証明できない」はノットイコールだと言っているのですよ？
意味がわかりませんか？
どこまでお馬鹿なのですか
「言ってませんね」は
「ケースバイケース」と「証明できない」はノットイコールだと言っているのですよ？
意味がわかりませんか？
どこまでお馬鹿なのですか
「言い換えると」はニアリーイコールでしょ
フォーマッタを
フォーマット前のプログラム文字列からフォーマット後のプログラム文字列への関数
として考えれば、途中にどんなケースバイケースな判断があったって、
入力と出力のペアを列挙できれば関数として定式化可能だ。
できないのであれば、それは自分がどんな理由でどうフォーマットしたか意識していない幼稚さの証明でしかない。
>>873に関して言えば、
入力と出力のペアを生成するのは>>873自身だということを理解せずに
他人様に定式化しろと言い出した時点で>>873は思考停止している。
はっきり言って、論理的思考能力を疑わざるをえない。
フォーマット前のプログラム文字列からフォーマット後のプログラム文字列への関数
として考えれば、途中にどんなケースバイケースな判断があったって、
入力と出力のペアを列挙できれば関数として定式化可能だ。
できないのであれば、それは自分がどんな理由でどうフォーマットしたか意識していない幼稚さの証明でしかない。
>>873に関して言えば、
入力と出力のペアを生成するのは>>873自身だということを理解せずに
他人様に定式化しろと言い出した時点で>>873は思考停止している。
はっきり言って、論理的思考能力を疑わざるをえない。
おいおい、「証明できない」にイコールなのは「ルールが決められない」ってことだろ
ケースバイケースがイコールなんて誰も言ってないよ
俺は「"証明できない" 問題が世の中にある」と言った。
奴は「世の中に "証明できない" 問題はない。"証明できない" 奴が馬鹿なだけ」と言った。
これを元に戻すと
俺は「"ルールを決められない"問題が世の中にある」と言った。
奴は「世の中に"ルールを決められない"問題はない。"ルールを決められない"奴が馬鹿なだけ」と言った。
ケースバイケースがイコールなんて誰も言ってないよ
俺は「"証明できない" 問題が世の中にある」と言った。
奴は「世の中に "証明できない" 問題はない。"証明できない" 奴が馬鹿なだけ」と言った。
これを元に戻すと
俺は「"ルールを決められない"問題が世の中にある」と言った。
奴は「世の中に"ルールを決められない"問題はない。"ルールを決められない"奴が馬鹿なだけ」と言った。
「ケースバイケース」はなんらかの判断基準があるってことだろ
アホか
アホか
> 「ケースバイケース」はなんらかの判断基準がある
その判断基準を明文化できない時点で無能 という話なんだけどね
その判断基準を明文化できない時点で無能 という話なんだけどね
ケースバイケースでフォーマットできるのであれば、
それぞれのケースを自分がどのような理由でどうフォーマットするのかを
コードにしていけばいいだけ。
コードにできないということは、
「ケースバイケースで判断して」やっているのではなく、
「特段の理由もなく、なんとなくの気分で」フォーマットしているというだけ。
正直、そんな無能がプログラマを名乗ってほしくないね。
それぞれのケースを自分がどのような理由でどうフォーマットするのかを
コードにしていけばいいだけ。
コードにできないということは、
「ケースバイケースで判断して」やっているのではなく、
「特段の理由もなく、なんとなくの気分で」フォーマットしているというだけ。
正直、そんな無能がプログラマを名乗ってほしくないね。
>>895
いや、フォーマッターが定義できないって話じゃなくて
「どんな場合でも見やすいフォーマッターが定義できない」って話だから。
ケースバイケースの話は「見やすいコードの”書き方”はケースバイケース」という話。
見やすいコードの書き方がケースバイケースになるのに、
見やすいコードにしてくれる関数が定義できないのは自明のことだろ。
いや、フォーマッターが定義できないって話じゃなくて
「どんな場合でも見やすいフォーマッターが定義できない」って話だから。
ケースバイケースの話は「見やすいコードの”書き方”はケースバイケース」という話。
見やすいコードの書き方がケースバイケースになるのに、
見やすいコードにしてくれる関数が定義できないのは自明のことだろ。
「見やすいコードの書き方がケースバイケース」ならその要求仕様を提示しろよ
>>902
日本語的に意味不明ｗ
日本語的に意味不明ｗ
905 ：仕様書無しさん：2013/04/06(土) 18:24:38.38
>>865
実際に命名されたメソッド名一覧みたいなのないですか？
実際に命名されたメソッド名一覧みたいなのないですか？
>>900
> 「特段の理由もなく、なんとなくの気分で」フォーマットしているというだけ。
話がおかしくなっている。
「なんとなくの気分ではなく厳格なルールに則って」フォーマットした所で、
それが見やすくなるとは限らないってことだよ。
> 「特段の理由もなく、なんとなくの気分で」フォーマットしているというだけ。
話がおかしくなっている。
「なんとなくの気分ではなく厳格なルールに則って」フォーマットした所で、
それが見やすくなるとは限らないってことだよ。
言い訳にすらなってない
無能過ぎて話にならん
871さんのまとめでFA
> 871 ： 仕様書無しさん [sage] DATE:2013/04/06(土) 16:34:07.76
> ケースバイケースだからフォーマッタ実装できないというバカは
> (1) 自分の要求項目すら定式化できない糞エンジニア
> (2) 同じコードも気分次第でコロコロフォーマットが変わって周囲を惑わせていることに気付かないアホ
> のどちらかだカス
無能過ぎて話にならん
871さんのまとめでFA
> 871 ： 仕様書無しさん [sage] DATE:2013/04/06(土) 16:34:07.76
> ケースバイケースだからフォーマッタ実装できないというバカは
> (1) 自分の要求項目すら定式化できない糞エンジニア
> (2) 同じコードも気分次第でコロコロフォーマットが変わって周囲を惑わせていることに気付かないアホ
> のどちらかだカス
>>903
あんた、自分がケースバイケースで行うフォーマットの「理由」を無限に持っているのかい？
ケースに応じてちゃんと「理由」を持ってフォーマットしているのなら、
その「理由」の数は有限なはずだ。違うか？
あんた、自分がケースバイケースで行うフォーマットの「理由」を無限に持っているのかい？
ケースに応じてちゃんと「理由」を持ってフォーマットしているのなら、
その「理由」の数は有限なはずだ。違うか？
話をまとめると、フォーマッターのルールを決めた所で
それが見やすくなるとは限らないってことなんだよね。
フォーマッターのルールを超えた、もっと見やすい書き方はできる。
そのもっと見やすい書き方に、フォーマッターを適用すれば
逆に見にくくなる。
それが見やすくなるとは限らないってことなんだよね。
フォーマッターのルールを超えた、もっと見やすい書き方はできる。
そのもっと見やすい書き方に、フォーマッターを適用すれば
逆に見にくくなる。
911 ：仕様書無しさん：2013/04/06(土) 18:28:50.89
>>908
一度もまともな反論出せてないよ無能
一度もまともな反論出せてないよ無能
「見やすくなる」ようなフォーマッタを実装すれば
フォーマッタと適用したところで何も整形されないはずだが？
フォーマッタと適用したところで何も整形されないはずだが？
>>909
> あんた、自分がケースバイケースで行うフォーマットの「理由」を無限に持っているのかい？
はい。通常のルールの書き方をするならば、こうするべきだけど
この場合に限っては、こっちの書き方をしたほうが見やすいというのは
各コードで決まるので、無限に存在します。
新しいコードを書くたびに、それが「理由」になります。
> あんた、自分がケースバイケースで行うフォーマットの「理由」を無限に持っているのかい？
はい。通常のルールの書き方をするならば、こうするべきだけど
この場合に限っては、こっちの書き方をしたほうが見やすいというのは
各コードで決まるので、無限に存在します。
新しいコードを書くたびに、それが「理由」になります。
まとめ：
「できない理由」を後付けでグダグダいうバカとは仕事したくないものだ。
「できない理由」を後付けでグダグダいうバカとは仕事したくないものだ。
「どんなコードが見やすいか」を定義できるのならば、
見やすくなるフォーマッターは作成可能。
それが定義できないのなら、作成不可能
それだけの話。
「どんなコードが見やすいか」は確か
人それぞれ違うんじゃなかったっけ？（笑）
見やすくなるフォーマッターは作成可能。
それが定義できないのなら、作成不可能
それだけの話。
「どんなコードが見やすいか」は確か
人それぞれ違うんじゃなかったっけ？（笑）
>>915
これがFAだな。
これがFAだな。
> この場合に限っては、こっちの書き方をしたほうが見やすい
これを明文化できない時点で
> (1) 自分の要求項目すら定式化できない糞エンジニア
> (2) 同じコードも気分次第でコロコロフォーマットが変わって周囲を惑わせていることに気付かないアホ
> のどちらかだカス
に適合する無能ということになりますがよろしいか
これを明文化できない時点で
> (1) 自分の要求項目すら定式化できない糞エンジニア
> (2) 同じコードも気分次第でコロコロフォーマットが変わって周囲を惑わせていることに気付かないアホ
> のどちらかだカス
に適合する無能ということになりますがよろしいか
>>913
あんたの脳味噌には無限の個数の脳細胞が詰まってるのかい？
そうでなければ、あんたの脳味噌には有限のルールしか無いはずだよ。
現実には、
あんたは単に気分でフォーマットしていて、その理由を後付けしているから、
無限のルールがあるように感じているだけなんだよ。
あんたの脳味噌には無限の個数の脳細胞が詰まってるのかい？
そうでなければ、あんたの脳味噌には有限のルールしか無いはずだよ。
現実には、
あんたは単に気分でフォーマットしていて、その理由を後付けしているから、
無限のルールがあるように感じているだけなんだよ。
>>915
だからルールを決めて(誰かが妥協するとしても)チーム内で揺れがないようにするべきでは？
だからルールを決めて(誰かが妥協するとしても)チーム内で揺れがないようにするべきでは？
万人が見にくいと思うコードはあるのだから、
万人が見にくいと思わないコードもあり得るのだろう。
万人が見にくいと思わないコードもあり得るのだろう。
>>922
> >>873のルールを明文化できるのは>>873だけだろw
そのとおりだが、>>873は見やすいというルールを明文化するのは
不可能だと言ってるんだよ。
それに対して、見やすいというルールを明文化することは可能だと言ってる奴がいる。
そして彼は明文化できると言いながら
明文化をしませんでした。
> >>873のルールを明文化できるのは>>873だけだろw
そのとおりだが、>>873は見やすいというルールを明文化するのは
不可能だと言ってるんだよ。
それに対して、見やすいというルールを明文化することは可能だと言ってる奴がいる。
そして彼は明文化できると言いながら
明文化をしませんでした。
そもそも、1人当たりの「ケースバイケースのフォーマットルール」が無限にあるとしたら、
その「ケースバイケースのフォーマットルール」が読み手にとっての「無限にあるケースバーケースのフォーマットルール」に
適合している可能性はゼロに収束するんじゃね？
よかったな、>>873が小さな脳でがんばったフォーマットは全くの無駄だw
その「ケースバイケースのフォーマットルール」が読み手にとっての「無限にあるケースバーケースのフォーマットルール」に
適合している可能性はゼロに収束するんじゃね？
よかったな、>>873が小さな脳でがんばったフォーマットは全くの無駄だw
チームで揺れが無いようにするルールを明文化するのは可能だが、
見やすいコードのルールを明文化することは不可能。
見やすいコードのルールを明文化することは不可能。
>>926
お前、賢いふりした馬鹿だな。文章からにじみ出てるぞｗ
お前、賢いふりした馬鹿だな。文章からにじみ出てるぞｗ
>>925
君は根本的なところで間違っている。
>>873は見やすいというルールを明文化するのは不可能だと言っている。
それに対して、「>>873に見やすいルールを明文化できるのは>>873本人のみである」と言っていて、かつ、
「>>873が見やすいルールを明文化できないのであれば、>>873はエンジニア失格」と言っている。
わかったか？
君は根本的なところで間違っている。
>>873は見やすいというルールを明文化するのは不可能だと言っている。
それに対して、「>>873に見やすいルールを明文化できるのは>>873本人のみである」と言っていて、かつ、
「>>873が見やすいルールを明文化できないのであれば、>>873はエンジニア失格」と言っている。
わかったか？
他人にお前のポリシーをルール化させるためには、
俺はこういうのが見やすいという、要求を提示する必要があるだろ。
「ケースバイケース」という基準がありながら、その基準を提示しないお前は何なんだ。
俺はこういうのが見やすいという、要求を提示する必要があるだろ。
「ケースバイケース」という基準がありながら、その基準を提示しないお前は何なんだ。
>>928
そういうお前は、バカ丸出しのわかりやすいバカだなw
そういうお前は、バカ丸出しのわかりやすいバカだなw
> 「>>873が見やすいルールを明文化できないのであれば、>>873はエンジニア失格」と言っている。
それは別に>>873に限ったことじゃないじゃん。
お前にも当てはまるよ。
「お前が見やすいルールを明文化できないのであれば、お前はエンジニア失格」と言っている。
またこれにたどり着く。
そして彼は明文化できると言いながら
明文化をしませんでした。
それは別に>>873に限ったことじゃないじゃん。
お前にも当てはまるよ。
「お前が見やすいルールを明文化できないのであれば、お前はエンジニア失格」と言っている。
またこれにたどり着く。
そして彼は明文化できると言いながら
明文化をしませんでした。
どこにもいるよな、
客から出た要求は何てことのない単純なトランザクション処理なのに
それに必要なRDBの知識がないばっかりに、できない理由を一生懸命に作り続けるバカw
わかりやすい例が、>>873 w
客から出た要求は何てことのない単純なトランザクション処理なのに
それに必要なRDBの知識がないばっかりに、できない理由を一生懸命に作り続けるバカw
わかりやすい例が、>>873 w
>>932
おまえは本当にバカなんだな。しかも卑怯だ。
わざわざ直前の行の
> それに対して、「>>873に見やすいルールを明文化できるのは>>873本人のみである」と言っていて、かつ、
を削除した上で、
> 「>>873が見やすいルールを明文化できないのであれば、>>873はエンジニア失格」と言っている。
だけを引用して、>>873以外の人物にもルールを明文化する責任があるかのように言っているところ。
はっきり言って、人間として軽蔑する。
おまえは本当にバカなんだな。しかも卑怯だ。
わざわざ直前の行の
> それに対して、「>>873に見やすいルールを明文化できるのは>>873本人のみである」と言っていて、かつ、
を削除した上で、
> 「>>873が見やすいルールを明文化できないのであれば、>>873はエンジニア失格」と言っている。
だけを引用して、>>873以外の人物にもルールを明文化する責任があるかのように言っているところ。
はっきり言って、人間として軽蔑する。
ラーメンはどれくらい茹でるのが一番うまいかみたいな話してるなー。
んなもんケースバイケースだろ？
うまいいかどうかなんて人によっても違うし、火力、麺、ダシ、使う水、
その日の気温、湿度などによって適切なゆで方は変わってくる。
チェーン店でどの店でもそこそこの同じ味を出すのが目的ならルール決めりゃいいけど、
うまいラーメン屋でそんなルールに固執しなんかしてねーよ。
んなもんケースバイケースだろ？
うまいいかどうかなんて人によっても違うし、火力、麺、ダシ、使う水、
その日の気温、湿度などによって適切なゆで方は変わってくる。
チェーン店でどの店でもそこそこの同じ味を出すのが目的ならルール決めりゃいいけど、
うまいラーメン屋でそんなルールに固執しなんかしてねーよ。
873の人気に嫉妬
>>938
でもそれは、最高の味じゃないよね？
でもそれは、最高の味じゃないよね？
はいはい。俺が現状を一言で表してやるよ。
サラリーマン VS 職人
サラリーマン VS 職人
> 火力、麺、ダシ、使う水、その日の気温、湿度などによって
アウトプットが統一できる以上
この辺りは条件が違うだけだから閾値で定型化可能
> 人によっても
「俺が」の一人に絞れば定型化も不可能ではない
プログラムなんだからもっと定型化はもっと楽だろ無能
アウトプットが統一できる以上
この辺りは条件が違うだけだから閾値で定型化可能
> 人によっても
「俺が」の一人に絞れば定型化も不可能ではない
プログラムなんだからもっと定型化はもっと楽だろ無能
>>939
その最高の味ってのは誰が決めるんだい？
その最高の味ってのは誰が決めるんだい？
>>943
はあ？君、言ってることが全然論理的じゃないんだけど？
はあ？君、言ってることが全然論理的じゃないんだけど？
一番うまい を いつも に変えるのがフォーマッタのお仕事
>>946
君は「最高の味じゃない」と断言したのだから、
それが誰にとっての「最高の味」で、
何をもって「最高の味」としていて、
どのような理由で「最高の味」であるのか、
説明可能でなければならない。
できないとしたら、
君にとっての最高の味とは単に「なんとなくの気分」でしかないか、
出されたどんなラーメンにも「最高の味ではない」という後だしジャンケンで批判しているか
どちらかでしかない。
君は「最高の味じゃない」と断言したのだから、
それが誰にとっての「最高の味」で、
何をもって「最高の味」としていて、
どのような理由で「最高の味」であるのか、
説明可能でなければならない。
できないとしたら、
君にとっての最高の味とは単に「なんとなくの気分」でしかないか、
出されたどんなラーメンにも「最高の味ではない」という後だしジャンケンで批判しているか
どちらかでしかない。
>>945
「一番うまい」の前提はどこへ消えた？
「一番うまい」の前提はどこへ消えた？
やっぱりコレじゃん
> 871 ： 仕様書無しさん [sage] DATE:2013/04/06(土) 16:34:07.76
> ケースバイケースだからフォーマッタ実装できないというバカは
> (1) 自分の要求項目すら定式化できない糞エンジニア
> (2) 同じコードも気分次第でコロコロフォーマットが変わって周囲を惑わせていることに気付かないアホ
> のどちらかだカス
> 871 ： 仕様書無しさん [sage] DATE:2013/04/06(土) 16:34:07.76
> ケースバイケースだからフォーマッタ実装できないというバカは
> (1) 自分の要求項目すら定式化できない糞エンジニア
> (2) 同じコードも気分次第でコロコロフォーマットが変わって周囲を惑わせていることに気付かないアホ
> のどちらかだカス
>>949
> それが誰にとっての「最高の味」で、
と言われましても、プロジェクトには複数の人がいるので
いうなれば、関係者全員にとっての「最高の味」ですかね。
あと将来の関係者も含みます・・・。
>>950
「一番うまい」=「最高のラーメン」ってことでいいよ。
> それが誰にとっての「最高の味」で、
と言われましても、プロジェクトには複数の人がいるので
いうなれば、関係者全員にとっての「最高の味」ですかね。
あと将来の関係者も含みます・・・。
>>950
「一番うまい」=「最高のラーメン」ってことでいいよ。
別人だよ？
「俺が見やすい」が「プロジェクト関係者すべてが見やすい」にすり替わった件について
まともなラーメン屋はスープの取り方から麺の茹で時間まで、
気温、室温、天候、季節から決める「パラメータ化したレシピ」を持ってるよ。
それがあるラーメン屋は「最高の味」じゃなくて、「いつもの味」
それがないラーメン屋は「最高の味」じゃなくて、「その時の味」
いずれにせよ、「最高の味」なんて存在しない。
存在しない「最高の味」を言い訳に「パラメータ化したレシピ」を作らないのは単なる怠慢か能力不足。
気温、室温、天候、季節から決める「パラメータ化したレシピ」を持ってるよ。
それがあるラーメン屋は「最高の味」じゃなくて、「いつもの味」
それがないラーメン屋は「最高の味」じゃなくて、「その時の味」
いずれにせよ、「最高の味」なんて存在しない。
存在しない「最高の味」を言い訳に「パラメータ化したレシピ」を作らないのは単なる怠慢か能力不足。
>>932
世にあるフォーマッタは何らかの明文化可能なルールに基づいているので、敢えて挙げるまでもなく山ほど存在してるわけだが・・・
少なくとも「〜の方が良い」とか言いながら「〜とは未定義である」とかドヤ顔で言っちゃう奴はただの馬鹿だと思う。
世にあるフォーマッタは何らかの明文化可能なルールに基づいているので、敢えて挙げるまでもなく山ほど存在してるわけだが・・・
少なくとも「〜の方が良い」とか言いながら「〜とは未定義である」とかドヤ顔で言っちゃう奴はただの馬鹿だと思う。
フォーマッタ作れないとか言ってるやつは
これが客がいる仕事なら要求を聞き出して実装するだろ
自分の要求なんてさらに簡単なのに作れないはずがない
これが客がいる仕事なら要求を聞き出して実装するだろ
自分の要求なんてさらに簡単なのに作れないはずがない
>>959
きっと、要求聞き出せないし、実装もできないのさ。
きっと、要求聞き出せないし、実装もできないのさ。
コーダーなら仕方ない
962 ：仕様書無しさん：2013/04/06(土) 19:39:49.81
腹減った
ラーメンの味で決着？
プログラミングしてると腹が減らない。波紋でも出てるんか。
プログラマはコーヒーをソースコードに変換する機械らしいからな
966 ：仕様書無しさん：2013/04/06(土) 20:49:43.07
東証
「システム開発では、一度コーディングすればドキュメントは不要！」
http://hayabusa3.2ch.net/test/read.cgi/news/1365248433/
みずほ証券「おお、もう…」
「システム開発では、一度コーディングすればドキュメントは不要！」
http://hayabusa3.2ch.net/test/read.cgi/news/1365248433/
みずほ証券「おお、もう…」
967 ：おじゃばさま：2013/04/06(土) 21:29:38.84
オリジナルフォーマッター要不要論争か？
これからコード書く人に絶対やってほしいこと。
主に俺のコードは素晴らしいと思い込んでる系住人がこののスレで繰り広げてくる、
レベルの低い争いは、絶対にやって欲しくないな。
>>905
一覧化されてるものは持ってないな。
参考になりそうなのでよければ、適当に有名どころのフレームワークの実装とか見るのが手っ取り早い。
オープンソースの開発に関わってみるとかもいいと思うよ。
主に俺のコードは素晴らしいと思い込んでる系住人がこののスレで繰り広げてくる、
レベルの低い争いは、絶対にやって欲しくないな。
>>905
一覧化されてるものは持ってないな。
参考になりそうなのでよければ、適当に有名どころのフレームワークの実装とか見るのが手っ取り早い。
オープンソースの開発に関わってみるとかもいいと思うよ。
なにが悲しいって、こういうくだらない内容のほうがスレが伸びる板ってことだよな
まともなコード屋やってるの少なそう
まともなコード屋やってるの少なそう
んなやつおらんわ
973 ：おじゃばさま：2013/04/06(土) 23:12:16.11
>>971
それはまともな奴じゃない。
それはまともな奴じゃない。
次スレたててこい屑
これからコード書く人は「freeは不要」とか「フォーマッタは悪」とか叫びだすような闇プログラマには成らないで欲しい
>>974
次スレじゃなくて糞スレがたった
フォーマッターを使う人と使わない人の違い
http://toro.2ch.net/test/read.cgi/tech/1365304270/
>>974
次スレじゃなくて糞スレがたった
フォーマッターを使う人と使わない人の違い
http://toro.2ch.net/test/read.cgi/tech/1365304270/
976 ：おじゃばさま：2013/04/08(月) 19:30:54.83
つーか、オリジナルフォーマッタって、一人で使うのか？
ナシだろ、それは。
ナシだろ、それは。
>>975
止められてるじゃねーかｗｗｗ
止められてるじゃねーかｗｗｗ
978 ：仕様書無しさん：2013/04/09(火) 01:03:17.62
う
め
ぼ
う
め
て
う
めはら