2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

コメントコメントうるせぇ 2 [無断転載禁止]©2ch.net

1 :
2016/12/25(日) 22:54:30.82
だめなコメント例を書いていきましょう

// 初期化処理


前スレ
コメントコメントうるせぇ [無断転載禁止]©2ch.net
http://tamae.2ch.net/test/read.cgi/prog/1449700487/
2 :
2016/12/25(日) 22:57:08.78
// 顧客モデル
class Customer

こういうのもいらんよな。
3 :
仕様書無しさん
2016/12/25(日) 23:00:30.51
// コンストラクタ
とかトートロジーはいや
4 :
2016/12/25(日) 23:02:08.78
// 保存する
// data: 保存データ
function save(data) {}

とかね。
5 :
仕様書無しさん
2016/12/26(月) 00:12:37.72
>>2
それはクラス名の命名がおかしいわ。
6 :
2016/12/26(月) 00:55:03.14
>>5

// 顧客モデル
class CustomerModel

って話か? どちらにしろいらないだろw
7 :
2016/12/26(月) 00:57:24.47
https://docs.oracle.com/javase/jp/8/docs/api/ より

java.awt.color カラー・スペースのクラスを提供します。

こういうのもいらないコメントだよなw
(正確にはJavadocだろうけど)

某コーディングスタイルでクラスには必ずコメントを書けっていうのがあるんだけど
必ずしも必要とは思わないな。
8 :
2016/12/26(月) 05:01:36.06
♪コメント コメント うるせぇな〜
9 :
仕様書無しさん
2016/12/26(月) 08:02:03.06
中規模開発以上ならclass Customerにコメントつけるかもしれん
システムにおけるCustomerの日本語呼称(用語)を決定する目的で
さもないと、コードの他の場所で、Customerについて言及したい時に日本語で書けなくなる
必要ないかもしれないけどねー
10 :
2016/12/26(月) 08:03:22.58
この場合Customer=顧客が普通なんで、用語で迷うことはないと思うけどさ
11 :
2016/12/26(月) 08:04:27.92
でも、
// コンストラクタ
ctor()
は絶対要らないと思う
用語も糞もないし
12 :
仕様書無しさん
2016/12/26(月) 08:06:13.08
>>7
いやそれJavaDoc的には残念ながら必要なんだよ・・・
悲しいけど、これJavaDocなのね
JavaDocには要約のページとかがあって(以下略
13 :
2016/12/26(月) 08:06:52.09
失礼
JavaDocじゃなくてJavadocでしたね
14 :
2016/12/26(月) 09:32:43.34
>>7
javadocじゃない別システムだけど、(html上記載されている達成率?が)100%じゃないと文句くるから可能性あるから仕方なく買いてるけどな
15 :
仕様書無しさん
2016/12/27(火) 02:36:02.91
>>6
そもそも顧客モデルという日本語がなんのことやらわからない。
16 :
仕様書無しさん
2016/12/27(火) 02:39:37.18
>>15
たぶんモデルの意味がわかってないんだよ。
17 :
2016/12/27(火) 03:39:57.48
せやな
18 :
仕様書無しさん
2016/12/27(火) 08:25:27.83
class 顧客


でいいだろが
下手くそな英単語無理して使うな
日本語使える環境なら日本語にしろ
19 :
2016/12/27(火) 17:31:31.93
>>18
日本語で実装しようと思ったことあったけど、Xcodeだとコード補間ができないんで諦めたなぁ

他のIDEは知らねーけど
20 :
仕様書無しさん
2016/12/27(火) 18:04:39.76
日本語だと長い専門用語を扱わないといけないときに、結局、変な短縮名を付けることになるから、かえって分かりにくい。

英語圏のひとは頭文字を取って短縮するけどなんのことやら分からなくなる苦労がある。
21 :
仕様書無しさん
2016/12/27(火) 21:16:49.14
省略単語使うな
22 :
仕様書無しさん
2016/12/27(火) 21:16:55.96
少しぐらい長くても、分かりやすい変数名がオヌヌメ。
後で見てわかりやすいから。
23 :
2016/12/27(火) 21:29:04.85
業界的に使われる習慣がある有名な短縮単語も使っちゃダメ?
例えばcodeをcdに短縮するのは?
hoge_cdなんてよく見るけど
24 :
2016/12/27(火) 21:29:48.09
>>23
カレントディレクトリでも保存してんのか?
25 :
2016/12/27(火) 21:45:39.89
>>23
略していいのは "ソフトウェア" 業界で全世界的に慣習的に使われるものだけ
codeをcdに短縮する習慣はない。

略せと指示が来ているのであるなら仕方ないが
それ以外は略すべきではない。


またローカル変数に関しては別の話がある。
一行の間でしか使わないのなら一文字でもいいし、十分に短い(長くても20〜30行)関数の
ローカル変数であれば短い変数名でもいい。だけどこれは略ではなく別名と捉えるべき。
別名として短い名前の変数に入れ直して参照する分には良いが
これは略しているわけではないわけではない。
26 :
2016/12/27(火) 21:52:33.66
"ソフトウェア" 業界でって言ったのは、
要するにお前の会社とかグループで使われてる略は
使うんじゃねーってことだよ。

なぜかというと、人は入れ替わるから。
略を見せられて困るのは新しく入ってきた人だろ?
長くやってる人はどんなクソな略でも覚えてるだろうさ。

ソフトウェア業界が例外なのは、新しく入ってきた人であっても
プログラマなわけだから(もしくはプログラマとして育てる)
今までの経験で知っていることであり略で困ることはない。
27 :
2016/12/28(水) 07:03:40.92
>>23
Fと関わってた時期長かったけど、たしかにDB項目名で、
なんちゃら_cdってのはごく普通にあったな
コードはcdってのは分かる気がする
でも一般的かと言われると疑問だな
28 :
2016/12/28(水) 09:03:32.62
あくまでも例なのはわかるけど、4文字を2文字に短縮する理由がわからんし、codeなんかそうそう使わねーだろうと。
そんなに暗号使ってんのかよと
29 :
仕様書無しさん
2016/12/28(水) 15:07:37.78
data
って関数の引数によく使ってしまうw
でも2つ3つと引数があるときdataはひとつじゃないんよな・・・wっていつも後悔するw
30 :
仕様書無しさん
2016/12/28(水) 23:35:45.18
こ こ は コ メ ン ト の ス レ だ
変 数 名 の ス レ で は な い
31 :
2016/12/29(木) 02:03:54.56
1 or2 ==3 ; # 屁をこいているのかと
32 :
2016/12/29(木) 06:34:42.85
今時エディタがいい感じに補完してくれるんだから
わざわざ短くして混乱を招く必要あるのか?
っていつも思う
33 :
仕様書無しさん
2016/12/29(木) 06:59:49.79
>>22
ユーザーの業務によっては異様に長い言葉があるから、コメントを書かないと対応できない。
34 :
仕様書無しさん
2016/12/29(木) 07:03:21.27
>>25
世界的っておかしいだろ。

日本ではコードをCDと略語にするのはよくあるので、分からないひとの方が少ない。
35 :
仕様書無しさん
2016/12/29(木) 07:04:27.84
>>29
それは最悪。

引数がデータなのはあたりまえだろ。
36 :
仕様書無しさん
2016/12/29(木) 07:08:04.00
>>32
オブジェクト指向で実装、よいデータモデルなら名前は長くはならない。
37 :
2016/12/29(木) 08:41:36.35
3音節を越える変数名はさすがに長すぎるので、俺はコメントでごまかすわw

isThisHogeTooLong

じゃなくて

// ○○が長すぎるか否か (boolean)
longHoge

の方がずっといいと思ってる(個人的な意見)
38 :
2016/12/29(木) 08:43:14.76
Hogeを変な言葉にチカンするのはやめてね!
39 :
仕様書無しさん
2016/12/29(木) 08:44:14.87
Hogeが長すぎるか (boolean)

の日本語関数ほうがいいわ。
40 :
仕様書無しさん
2016/12/29(木) 08:45:29.43
>>39
正解
41 :
2016/12/29(木) 09:16:12.55
変数名のルールを突き詰めていくと意味をもたない連番名がいいんだよな
int NUM001 //商品CD
int NUM002 //支店CD
int NUM003 //顧客ID




新規のときは面倒だけど
保守するときに圧倒的に楽
42 :
仕様書無しさん
2016/12/29(木) 11:36:30.25
//
// うちの勤め先では、コンピューターウィルスよりも
// 風邪のウィルスが恐れられていて、場合によっては
// 風邪を治すまで出勤しないようにと言われる事もある。
//
43 :
仕様書無しさん
2016/12/29(木) 12:12:34.85
>>41
なん・・・だと・・・
44 :
2016/12/29(木) 13:59:12.41
どういう場面で保守が楽になるのかいまいち想像がつかん

ある程度以上の品質が必要な現場だと
物事の重要度が逆転して一見くそコードになるのがよくあるらしいが
45 :
2016/12/29(木) 14:08:48.72
http://nlab.itmedia.co.jp/nl/articles/1612/24/news032.html

> これに対し河野議員が「通常の並び順でないため、担当者がすぐに
> ファイルを取り出せず非効率ではないか」と質問したところ、

> 各職員の机にイロハニ順を書き出した紙を要しするなどとともに、
> ファイルの保管について、管轄地域ごとにイロハニ順とし、
> さらにファイルボックスにもインデックスを貼ることで、
> 保管場所がすぐに分かるような工夫を行っています」と、
> 今後もこの方針は変えずに取り組む予定だとの回答
46 :
仕様書無しさん
2016/12/29(木) 15:19:33.46
>>41
汎用機みたいな発想だな。
47 :
仕様書無しさん
2016/12/29(木) 16:46:26.47
>>41
明らかに現代で基本中の基本(でもできてる人がすくない)といわれる変数命名規則の逆を行くとは・・・。
そういう結論に至った理由を建設的に教えてくれ
もしかしたら目からウロコがあるかもしれん。
48 :
2016/12/29(木) 21:51:43.73
そのへんのドブ川で水葬とか流行らんかな
49 :
2016/12/29(木) 21:52:18.05
まちがえた
50 :
2016/12/30(金) 23:54:55.96
>>34
そんな文化あるの?
俺の周りにはないけど
まあ文化の違いはあるとして、codeくらい略さずに書いたらだめ?
51 :
2017/01/01(日) 15:27:57.14
あげぇ
52 :
仕様書無しさん
2017/01/01(日) 15:28:14.34
あげぇぇ
53 :
仕様書無しさん
2017/01/01(日) 15:33:26.69
前スレで最後で発狂した人間
54 :
2017/01/01(日) 15:41:27.74
>>53
ですか、こんにちは
55 :
仕様書無しさん
2017/01/01(日) 15:41:31.04
あげぇ
56 :
仕様書無しさん
2017/01/01(日) 15:42:01.11
ペヤングおいしい
57 :
2017/01/01(日) 15:46:17.89
でーぶ
58 :
仕様書無しさん
2017/01/01(日) 17:11:52.58
コメントは
記述者が書く
思いやり
59 :
2017/01/01(日) 17:27:05.02
あげええ
60 :
仕様書無しさん
2017/01/01(日) 17:40:02.64
コメントが多いプログラムがなぜよいか?
コメントを書く=次に読む誰かが読みやすいように一生懸命説明しようとしている。
そんな心配りをしているプログラマのプログラムは、当然にソースコードも読みやすいようにしている。

だから結局、よいコードになっている。
61 :
2017/01/01(日) 17:50:57.02
>>60
あー、現実を知らないね。

現実は意味がわからないめちゃくちゃなコードを書いて
自分でもコードが読めないから、コメント書いて逃げてるだけ。

コメントは読めてもコードが読めないってことがよくある。
良いコメントは、コードで書いてある内容と同じことを書かない
62 :
仕様書無しさん
2017/01/01(日) 19:08:53.65
適切なコメントが書けるのは、細かい設計がうまいから。

人間にわかりにくいコードだと、コメントが書けない。
63 :
仕様書無しさん
2017/01/01(日) 21:18:16.33
>>61
お前の環境ではそうだろう
使い捨てしかいないからなそこは
お前も使い捨てだがな
64 :
2017/01/01(日) 22:05:26.66
>>63
少なくとも俺の環境で、それが事実であると認めたわけだよね?

ということは、コメントが多いからと言って
良いコードになってない事例があるということなので

>>60への反論が正しいことが証明された。
65 :
仕様書無しさん
2017/01/01(日) 23:14:18.42
ああ、無駄コメントを律儀に書くのが気持ちイイのよ!
機械のように翻訳されたコメント、この快感!!
66 :
2017/01/02(月) 00:33:35.62
・言語仕様を知らない人向けのコメント
・変数名で推理できるけど、念押しで条件を日本語化しておくコメント
・VBで見られるような関数が長くなりすぎて読む気がしない箇所でのコメント

だいたいこの3つが人によって要不要が変わるコメントの典型だと思う
特に「言語仕様を知らない人向けのコメント」なんて論外だと思うが意外と需要は高い
67 :
2017/01/02(月) 01:59:55.74
いいえ言語仕様を知らない人向けのコメントは論外です
68 :
2017/01/02(月) 23:10:14.40
SEが言語を知らない人でも理解できるようにコメントを入れなければならないって指導してるんだけど
69 :
2017/01/02(月) 23:22:20.99
>>68
そういう馬鹿には設計書を読ませろ
70 :
2017/01/02(月) 23:33:00.74
>>69
ソースが仕様書/設計書だって言われる
迷惑だから書類を作ろうとしても無駄なことをするなと言われる
でもソースは読んでくれない(コメントを読む)
71 :
仕様書無しさん
2017/01/03(火) 00:12:54.17
>>70
仕様をコメントに書くとコメントだらけになるだろw
72 :
仕様書無しさん
2017/01/12(木) 06:40:05.44
日本語関数
日本語変数

さいつよー
73 :
仕様書無しさん
2017/01/12(木) 07:29:28.39
漢字関数最強だよね
74 :
2017/01/12(木) 08:20:39.79
IDEつかってないならさいつよだね
75 :
2017/01/12(木) 09:16:08.71
>>74
今時みんなSATAかM.2だからな
76 :
仕様書無しさん
2017/01/12(木) 23:20:04.66
関数って、仕様書を書く必要がある?
それとも、さらっとコメントしとけば良いのかな。
77 :
2017/01/12(木) 23:52:05.03
>>76
上司か客に聞けよ
78 :
2017/01/13(金) 01:11:36.03
そういうの仕様書として残せって言うとこなら
詳細設計の成果物にきっちり指定されてんじゃね
79 :
2017/01/13(金) 10:31:38.12
工程が進んでテストも十分に行われて
仕様が固まってきた頃にソースをもとに書き起こせばよい
80 :
2017/01/13(金) 23:42:50.47
コメントコメントって藻前らは大場久美子か!!

(´・ω・`)b
81 :
2017/01/14(土) 14:38:56.46
どうしよう、こめんと何にも書いてない。
82 :
仕様書無しさん
2017/01/15(日) 08:34:01.17
昔はコメント不要派だったけど
最近は、(重要な)仕様に関わる分岐処理にはコメントいれるようにしてる
83 :
2017/01/15(日) 15:23:49.24
俺は逆で重要な分岐であればあるほど
書き方を工夫することで、よりシンプルになるようにしているな。
すごく単純な処理に見えるんだよ。
だからコメントがなくてもわかる。
84 :
2017/01/15(日) 17:41:01.81
>>83
分岐にコメントを書くといっても、別にコードの説明をしてるわけじゃないんだな
コメントがなくてもコードの意味は分かるんだ
じゃあ、なにをコメントとして書くかって?
85 :
2017/01/16(月) 02:30:19.87
編集した日付と編集者の名前だよ
86 :
仕様書無しさん
2017/01/18(水) 07:42:44.32
日本語変数
日本語関数
最小パーツ化
メモリの寿命とアクセス範囲

これだけ教えれば大丈夫
87 :
2017/01/18(水) 11:20:54.71
>>34
cdはcurrent directoryの方が一般的じゃね
大文字のCDでcodeはどっかで見た記憶あるが
88 :
2017/01/18(水) 18:50:46.03
なんかこういう奴うざい
89 :
仕様書無しさん
2017/01/18(水) 18:56:03.51
コンパクトディスクだったらどうすんだ!
90 :
仕様書無しさん
2017/01/18(水) 19:47:07.95
>>88
は?遅レスだから?
だったら謝るが?あ?
91 :
2017/01/18(水) 20:10:12.80
>>71
数行ごとにコメントがある
全行コメント入れるのが理想

らしい
92 :
2017/01/18(水) 21:44:35.17
コメントを全く書かないくらいなら>>4でもええんで書いてもらった方がええと思うが
ま、この例に関しちゃあれだが
93 :
2017/01/18(水) 21:48:03.60
その例と同じようなコメントを山ほど見てきた
そして俺もそのようなコメントを量産している
コードのレビューはされないがコメントのレビューは厳しい
94 :
2017/01/18(水) 21:52:44.91
大事なのはコメントの内容と処理が一致してるかどうかじゃないのか
コメントだけレビューして意味あるのか?
95 :
2017/01/18(水) 22:36:32.76
>>じゃあ、なにをコメントとして書くかって?
俺は今日の気持ちを書くことにしてる。
96 :
2017/01/18(水) 22:40:49.99
おい、コンパイル通らねーぞ

すきです///
97 :
2017/01/18(水) 23:35:14.02
コメントで挨拶してくるやつってどうしたらいいの?
レビュー対策?
98 :
仕様書無しさん
2017/01/19(木) 07:54:57.79
>>87
コマンドでしか使わないよ。
コードの方が多い。
99 :
2017/01/19(木) 12:56:03.57
>>87 >>98
みたいな文化の違いもあるから略さないで書こうね
100 :
仕様書無しさん
2017/01/19(木) 13:39:32.78
コメント入れたらコンパイラが通らん。何で?
101 :
2017/01/19(木) 13:43:55.87
コンパイラのバグか、おまえがバグってる
102 :
2017/01/19(木) 19:42:34.65
コメントでバグるコード例を書こうと思ったら跳ねられた
この板ってコード禁止なのか?
103 :
仕様書無しさん
2017/01/19(木) 21:10:23.21
>>102
なんて書こうとしたの?
104 :
仕様書無しさん
2017/01/19(木) 21:34:32.00
>>100
コメント通らんことあるよ。
消すか、別の文字を使って書き直せばおk
105 :
2017/01/20(金) 21:04:58.64
コメントが間違ってる、嘘ついてる、とか何回か経験したから、完全に信用はしてない。
コードは保守するけど、コメントの修正はしなくて放置とかもあるからな
106 :
仕様書無しさん
2017/01/20(金) 21:22:23.49
まあ、コードが間違ってる、嘘ついてる経験の方が限りなく多いのですが。
107 :
2017/01/20(金) 23:43:56.15
>>106
バグだらけじゃないとそういうことにはならない。
お前の会社、バグだらけ?
108 :
2017/01/21(土) 01:19:54.70
やー、元気?
だめなメロン

とか、コメントするのは俺だけかな?
誰かがコメント必死で読む時には俺は居ない訳だし。
109 :
仕様書無しさん
2017/01/25(水) 22:16:29.34
日本語と英語以外の言語をコメントに入れたら、コンパイラが通して
くれなかったのだが、三ヶ国語も使うと、通らない仕様なのかな?
110 :
2017/01/25(水) 22:21:21.43
>>109
可能ならUTF-8へ移行
111 :
2017/01/26(木) 21:58:30.24
コメント行のないソースは美しいな。
112 :
仕様書無しさん
2017/01/28(土) 14:43:54.59
コメントに絵文字を入れても、コンパイラは作動するものなんだなw
初めて知った。
113 :
2017/01/28(土) 15:53:32.35
>>112
ほんとだw
理屈上当然といえば当然なんだが違和感すごいな
114 :
2017/01/29(日) 18:11:25.49
え?
115 :
2017/01/29(日) 20:48:03.93
>>114
触ったらダメ!
116 :
仕様書無しさん
2017/01/31(火) 00:15:53.76
コメント内に挿入された多くの修正履歴を、どのくらいいじって良いのか
わからんw
後々のためにとっておくか、あるいはバサッと切ってしまうか。
開発方針にもよるだろうが、悩ましいところだよな。
117 :
2017/01/31(火) 03:06:49.27
え?
118 :
仕様書無しさん
2017/01/31(火) 08:01:40.11
だから日本語関数
日本語変数
つかえっつってんだろ
119 :
2017/01/31(火) 08:48:29.99
え?
120 :
2017/01/31(火) 09:22:47.16
>>118
IDEが予測のサポートしてくれないからダメというか、めんどくせー
121 :
2017/01/31(火) 09:47:55.35
え?
122 :
2017/01/31(火) 09:47:56.43
え?
123 :
2017/01/31(火) 22:28:28.90
今まで自分がメチャクチャなこと書いてきたから
修正履歴もコメントも信じない

ソースの差分が一番あてになる
124 :
2017/01/31(火) 23:42:53.95
え?
125 :
仕様書無しさん
2017/02/03(金) 00:26:35.56
>>123みたいな奴を懲らしめるためにわざとコメントアウトしたコードにダミーの変更を入れる有能な僕
126 :
2017/02/04(土) 09:12:09.96
/**
* insertXxx method
*/
void insertXxx()

なんの情報にもならないコメントつける奴はしね
127 :
2017/02/04(土) 12:48:57.22
いや、生きろ
128 :
仕様書無しさん
2017/02/04(土) 13:20:21.83
/**
* insertSex method
*/
void insertSex()
129 :
仕様書無しさん
2017/02/04(土) 15:30:21.82
>>128
(誤) insertSex
(正) insertInSex

英語もできない下等生物はこれだから・・・
130 :
2017/02/04(土) 16:31:22.98
>>129
性別データを挿入するってことだろ
insertSexであってる
131 :
仕様書無しさん
2017/02/04(土) 21:26:42.32
めんどくせえやつw
132 :
2017/02/05(日) 03:43:37.42
コメントないソースにコメントいれるプログラムないかな?
133 :
2017/02/05(日) 03:46:44.17
>>コメントは余計なコストを生む
おー、これだ。書いてない理由になる。
134 :
仕様書無しさん
2017/02/05(日) 13:06:53.80
>>130
アメリカの英文のアンケートサイトだと、man、womanの選択肢の他に、
otherという項目のあるサイトが多いんだよな。
これはどう解釈すれば良いんだ?w
135 :
2017/02/05(日) 13:16:31.29
答えたくない人、その分類に入れてほしくない人だよ

ISO 5218を読みなさい
https://ja.wikipedia.org/wiki/ISO_5218

> ISO 5218で指定された4つのコードは以下のとおりである。
> 0 = not known(不明)
> 1 = male(男性)
> 2 = female(女性)
> 9 = not applicable(適用不能)
136 :
仕様書無しさん
2017/02/07(火) 18:28:07.67
>>134
英語って差別的だよな。
女性は人間のサブカテゴリって分類だし。
137 :
2017/02/09(木) 10:42:33.04
// ** 頭と性格、どっちが悪いのかはっきりしろクソバカ**
// if ("A".equals(inputStr1)) num = 0;
// else if ("B".equals(inputStr1)) num = 1;
// 〜略〜
// else if ("Z".equals....
if (c < 'A' || c > 'Z') throw new IllegalArgumentException("非対応:"+ c);
num = c - 'A';

辞めた派遣が書いたコードを死んだ先輩が直した時のもの、らしい。
傍から見てると楽しいが、当事者の怒りは相当だったのでしょう。
138 :
仕様書無しさん
2017/02/09(木) 10:47:39.10
>>137
そのコードそのものも変だか?
139 :
2017/02/09(木) 17:11:29.43
第1はコメントが無くても関数名、変数名などで理解できるように努力する。
第2は変数名などで十分理解できるようになっていればコメントはむしろ害悪となる。
第3は変数名などでは理解出来ない、しにくい部分にはコメントが絶対に必要。

ってのが基本じゃ無いの?
140 :
2017/02/11(土) 00:51:18.14
>>137
> // ** 頭と性格、どっちが悪いのかはっきりしろクソバカ**

派遣 ・・・ 頭が悪い
先輩 ・・・ 性格と身体が悪い

ということでOK
141 :
仕様書無しさん
2017/02/11(土) 09:04:41.66
// ** こんな流儀のコメントみたことないわ、キモすぎる!**
142 :
仕様書無しさん
2017/02/17(金) 00:31:46.83
//よく分からんがとりあえず動く
143 :
2017/02/17(金) 01:43:25.62
// 駄目だと言われた。詳細は〇〇さんに聞いて
144 :
2017/02/18(土) 01:10:26.89
// なんでこうやってるのに、うまくいかないの!?

// よくわかんないけど、とりあえずこれでいいかな?

// 後で時間があったら整理する

こういうコメント見るとイラっとくる
145 :
2017/02/18(土) 03:02:09.48
>>144

//TODO:実装すること

と書いていれば納得する人か?
146 :
2017/02/18(土) 08:38:21.56
>>145
うん、そうだね

前2つは、自身のイライラ感情を馴れ馴れしい口語調で語りかけてくるのが嫌い
事実だけを書いてほしい

最後のは、自分専用のコメント書いておいて、結局そのままコミットする怠惰な精神が嫌い
147 :
2017/02/18(土) 16:18:48.72
だとすると

//明日までに実装して
//今週中に結合テストを通さないといけない
//さもないとヤ〇ザに殺される

というコメントもダメかな?
148 :
2017/02/18(土) 22:38:41.49
todo fixme xxxのどれかとりあえず入れてれくれればいい
149 :
仕様書無しさん
2017/02/19(日) 20:10:34.90
>>147
// TODO 実装&結合テスト or ヤクザに殺られる
で十分
余計な事は要らないと思う
150 :
仕様書無しさん
2017/02/21(火) 12:37:14.17
100行を超えるコメントはマジで止めてくれ...と言おうとしたら、
修正前のコードが//のコメントとして、そのまま残っていた。
必要のなくなった修正前のコードは、ちゃんと消しておいて欲しい。
151 :
2017/02/21(火) 12:47:03.26
>>150
修正の際にdiffを確認する癖をつけさせろ
152 :
2017/02/21(火) 13:32:19.96
コメント部消すには監査対応のため部門責任者の承認と顧客の承認が必要です
承認手続き実施費用見積もって再提案お願いします
153 :
2017/02/21(火) 18:40:37.88
>>150
VCSちゃんと使えてないところはそんな感じだと聞いた
154 :
2017/02/21(火) 19:23:18.30
>>150
delstart〜delendとかで囲うとこあるある
ソース管理めちゃくちゃだからよくデグレる
155 :
2017/02/21(火) 20:03:48.44
>>150
コメントで残すのが規約になってる現場もあるしな
スクリプトでコメント除外してから作業するとか工夫で補うしかない
156 :
2017/02/23(木) 12:54:09.02
よし
#if false
〜〜
#endif
で囲む俺セーフ
157 :
2017/02/25(土) 22:37:34.33
>>155
コメントで残すのが規約になってるのを、
気づくと片っ端から消してまわってたという人も見た
158 :
2017/02/25(土) 22:52:41.91
>>157
消さないと差分もとれないし、検索もできないからな。。。
まずは消してから作業するのは正しい
159 :
2017/02/26(日) 09:40:31.48
コメントリファクタリングだな
メソッド丸ごとコメント化してクラスの最下部に移動
コメントを取り除いたメソッドを元の場所に書いて作業開始
規約には違反してない
160 :
2017/02/26(日) 23:20:36.37
どう考えても SCM 使わないのはおかしいよ。正気の沙汰じゃない。
161 :
2017/02/26(日) 23:56:37.27
なんでSCMの話が?
162 :
仕様書無しさん
2017/03/06(月) 23:34:00.30
//  ここからコメント
//  
//
//
//  コメント終了

   ↑

こういう奴には、何かかける言葉があるのか?
163 :
2017/03/06(月) 23:43:19.17
あぶり出し
164 :
仕様書無しさん
2017/03/06(月) 23:59:41.93
一行毎に意味が有るコードなので、解りやすく
//で 何してるか書いてるんじゃないの?
165 :
2017/03/07(火) 00:13:51.75
>>164
ぉお?
貴方にはコードが見えるのですか
166 :
2017/03/07(火) 00:56:55.52
#if XXX // {
...
#else // }{
...
#endif // }
ってやりたくなることがあるが(特に他人が書いた中身が長大なifdefとか)
エディタのオートインデントがずれるのでやらない。
167 :
仕様書無しさん
2017/03/07(火) 03:01:20.90
>>165
通常のコード規約だと、そうなるのでは?

複数行に渡る説明をする時なら、纏めて使うのが基本
コメントの開始地点や終了地点は極力、揃える

/* とか
  */

//
// とか
// 禁止されてない?
168 :
仕様書無しさん
2017/03/07(火) 03:02:48.20
>>165
お前って、実務経験ないんじゃねぇ?
169 :
2017/03/07(火) 03:44:50.87
SSHのプロトコル使ったので手元にネタがあるんだが

# テレタイプ端末になってるからここでは改行もいる
ch_out.send_data reaction + "\n"

というクソみたいなコメントを書いてしまい後悔して公開した。
170 :
2017/03/07(火) 09:24:52.01
>>167
それってわざわざ規約で縛るほどの合理的な理由ってあんの?
171 :
2017/03/07(火) 10:34:54.25
>>170
たとえばJAVADOC?
172 :
2017/03/07(火) 10:45:06.98
>>164
いや、そういう意味じゃ無いだろ。
その言語の基本的なことが分かっていれば
//のブロックがコメントなのは当たり前の話で、「ここからコメント」、「コメント終了」の文言は全く不必要だろ。

逆にこの文言を必要とする人はコード扱っちゃダメだろ。
173 :
2017/03/07(火) 14:37:36.61
>>171
JavaDOCは知らんが、AppleDocなら無問題

というか、今回の話ってJavaDocのルールとかそういう話では無い気がするんだが・・・
174 :
2017/03/07(火) 19:13:25.79
//ここからコメント開始
//ここまでコメント

しばらく後

//ここからコメント開始 (1)
//ここからコメント開始 (2)
//ここまでコメント (1)
//ここまでコメント (2)

わりとよくある
175 :
2017/03/07(火) 21:42:04.72
>>174
一体なにをしたいんだよ
176 :
2017/03/07(火) 21:56:05.43
>>175
わからないけどよくあるんだ
177 :
2017/03/08(水) 07:48:57.67
/* */ は辞めた方がいい。
エディタでのコメント検索しにくいから
178 :
仕様書無しさん
2017/03/08(水) 22:54:40.20
個人的に、複数行コメントなんて殆ど使わないな

複数行コメントの何が嫌いって
grep結果が有効行なのか無効行なのか見た目で分からんこと
コメントのネストできないこと

だから、コメントしたい行が100行あっても、エディタの機能を使って、普通にコメントしちゃうわ
179 :
2017/03/09(木) 02:05:21.05
へー、そうなんですか
180 :
2017/03/09(木) 05:20:04.81
見たらわかるだろ、読んだらわかるだろ、ってのは、ちょっと規模の大きなシステムでも作った事があれば、
絶対に言わない寢ごと。

多人数だと、どうしても技量に差が出るし、ましてや複数ベンダを取りまとめる、なんて立場だと、
のちのちのメンテまで考えなきゃならないから、コメントの統一と徹底はPMにとって必須の考慮点でしょう。

実行コードは数行でも、コメントがどっさりなんて、まともなソフトなら当たり前。
ケツの青いできそこないPGMRならいざしらず、何年か経験してる奴がコメントを軽視してるなら、そいつは役立たず。
あと、ベンダが大好きな文書化も重要な仕事ですぞ(笑 あれの更新がきっちりできるベンダはPMとしては高評価。

コメントつきとコメントぬいたソースの提供もできるようにしといてね。
ヘッダで入れたコメントと、行単位のコメントもぬくんやで、ええな。

それから、各ソースの末尾に、*とか@で、パッチエリアも確保しといてや。こいつはコメントにしたらあかんよ。
181 :
2017/03/09(木) 06:03:29.49
要らんコメント長々と書くタイプだな間違いない
182 :
2017/03/09(木) 06:05:43.36
>>180
コメントに(笑)とか入れてそう
183 :
仕様書無しさん
2017/03/09(木) 07:37:41.17
>>174
二十年近く他人のプログラムを見てきているけど、そんなの見たことないわ。
184 :
2017/03/09(木) 07:52:31.45
>>181
これが、小さいプログラムしか書いたことのないやつのせりふ(笑

>>182
こういうバカにはしっかり言っておかないとアカンので、一応マジレスすると、
納品するコードに対して、コメントはきっちりレビュー作業があるのが丁寧な納品ってもの。
特にメンテも担当するなら、それは自社のためでもある。
一般に市販するもんだと、コピーライトも同じようなタイミングで入れているかをレビュー。

まあ、弱小コーダーには縁がないかもしれないけど、
間違って大きなプロジェクトに放り込まれたら恥かかないようにしろよ。特に、>181とか>182(笑
185 :
2017/03/09(木) 07:57:39.76
う〜んこの香ばしい加齢臭
186 :
2017/03/09(木) 10:56:45.94
>>185
う〜んこの香ばしい小物感
187 :
2017/03/09(木) 12:55:18.45
ウンコ流行ってるねw
188 :
2017/03/09(木) 13:48:10.37
>>184
キモキモー
189 :
2017/03/09(木) 15:13:57.22
>>184
めっちゃ早口で説教してそう
190 :
2017/03/09(木) 17:43:39.76
まあ、やっぱり書いてよかったな。
そんなの当然だろ、って反応じゃ無意味だし(笑
191 :
2017/03/09(木) 19:08:27.82
内容はともかく生理的に受け付けない文章だな
192 :
2017/03/09(木) 19:34:20.18
良いコメントってコードと同じで必要な所に必要なだけ書かれるんだよね
何でもかんでも義務感のような気持ちでコメントを書くと>>184のように中身のない薄い邪魔なだけの文章でコードが瞬く間に汚染される
193 :
仕様書無しさん
2017/03/09(木) 19:37:51.26
>>184のように中身のない薄い邪魔なだけの文章で汚染されるようなコードって弱すぎだろw
194 :
2017/03/09(木) 19:38:51.55
// ログ出力
Console.WriteLine("start");
195 :
2017/03/09(木) 20:16:04.48
>>193
バカのひとつ覚えというか真面目な無能のやる事をなめちゃいけない
油断すると気が付いた時にとんでもない量の汚物コメントをコードに仕込んでくるぞ
196 :
仕様書無しさん
2017/03/09(木) 20:36:06.39
リファクタリングせねば(使命感)
197 :
仕様書無しさん
2017/03/09(木) 21:03:25.01
>>184
なにこれwww
198 :
2017/03/09(木) 21:56:24.47
ここには大規模システムを構築したことのないプログラマしかいないようだな。

まあ、それもいいけど、迷惑はかけんなよ(笑
199 :
2017/03/09(木) 22:14:50.35
>>198
大規模システムは素晴らしいよな
200 :
2017/03/09(木) 22:18:37.90
>>198
お前もクソコメントでリポジトリ埋め尽くして迷惑かけるなよ
コメントアートで遊んでないでコードを書け
201 :
2017/03/09(木) 23:07:31.71
>>198
歯車のひとつって気楽だもんな
202 :
2017/03/09(木) 23:43:30.95
>>198
お前が無能だと言うことだけはよくわかった
203 :
2017/03/10(金) 07:11:55.67
みずぽとかIBMの大規模システムがコケた理由の一端を垣間見た気がした
204 :
2017/03/10(金) 07:58:12.23
コメントは/**/で囲むと検索しにくいから
//にしてよ。
あと、障害票ナンバーとかバグ管理票ナンバーと
その内容とか、いつ直したとか、
あんまり要らない気がする。
リポジトリに書けばよくね?
あと、その対応で消してるコードは
消してるんじゃなくてコメントアウトしてるだけとか
そんなのが、全体的に一行置きにマバラにあったりして
読みにくい。
205 :
2017/03/10(金) 10:26:41.09
>>204
リポジトリとイシュー管理ツールにでも書いておけばいいよな
コードは見やすくしてなんぼだよな

ただ、普通なら単純にこう書くのにって場合に、変態的な書き方や回りくどい書き方するなら、なんで敢えてそうしているのかの理由くらいは書くべきだと思う
206 :
2017/03/10(金) 12:55:04.38
>>204
/* */でもいいけど、複数の時は*書くべき

/*
 *
 * コメント
 *
 *
 */
207 :
2017/03/10(金) 12:59:57.89
>>206
/* やめろって話で、なんでそういうツッコミになる
208 :
2017/03/10(金) 14:37:38.11
>>207
お前はC言語使ったことないの?
209 :
2017/03/10(金) 15:00:16.39
>>208
何が言いたいのかわからん

APIマニュアルの自動生成などを除けば、基本的に全部 // でいいだろうって話をしている流れと思ってるんだけど
普通のIDE使ってりゃ複数コメントアウトなんぞショートカットでできるし

/* ← 未だにこれを//の代わりに使うメリットを教えてくれよ
210 :
2017/03/10(金) 16:14:50.01
>>209
お前はC言語の仕様も理解できないの?
211 :
2017/03/10(金) 16:35:57.13
>>210
お前はまともなレスもできないほどのコミュニケーション障害なのか?
言いたいことはきちんと書けよ
エスパーさせるな

今時のC言語は、// を使えるだろ
212 :
2017/03/10(金) 16:40:51.05
>>211
「今どきの」な
213 :
2017/03/10(金) 16:44:38.43
>>212
C99(1999年)の仕様だぞ
大丈夫か?ちゃんと仕事しているか?
214 :
2017/03/10(金) 16:45:32.33
こんなコミュ障と仕事しなきゃいけない人はかわいそうだな…
215 :
2017/03/10(金) 16:47:15.31
C99とか特定の仕様が全員使えるとか勘違いしてる馬鹿って居るよね
216 :
2017/03/10(金) 16:48:34.96
>>214
環境の違いすら考慮できないコミュ障って恐いですね
217 :
2017/03/10(金) 16:50:41.69
>>215, >>216
そもそもそれしか使えないって状況と、それもできるけどメリットないからやめてほしいって話を混同している時点でお前らが糞
218 :
2017/03/10(金) 16:54:37.43
>>217
なにいってだ
219 :
2017/03/10(金) 17:01:36.23
>>218
ジョナサンかよ
220 :
2017/03/10(金) 18:39:37.30
>>212
おじいちゃんこんばんは
221 :
2017/03/10(金) 19:13:48.65
現行ソースに従うしかない
222 :
2017/03/11(土) 10:47:50.00
docコメントだけは/** */だな
後は全部//派
223 :
仕様書無しさん
2017/03/11(土) 14:11:00.91
大きなシステムになるとコメントは適切であれば多いほど良い。

不適切なコメントならまったくコメントがない方がいい。

だいたい変なコメントを書くプログラマはコードそのものが変なことが多い。
224 :
2017/03/11(土) 14:21:06.24
で、何が不適切なコメントかというと

コードと二重管理になってしまってるようなコメントが不適切
例えば、引数の型を変えた時に、コメントにも型が書いてあって
同じように書き換えるとか

コードとコメントに言語の違いはあれど、内容的に
同じものを書いているようなものが不適切なコメント
225 :
2017/03/11(土) 14:24:30.69
>>223
多いほどいいってのはバカの発想だよ
簡潔で短いほうがコメントを読むのもメンテも楽
そもそもそんな長いコメントを書かざるを得ないほど低品質なコードを書くのが間違い
コメントに払うコストをリファクタリングに使え
226 :
仕様書無しさん
2017/03/11(土) 14:50:48.65
>>225
それ「適切であれば多いほどよい」って書いてあるじゃん
「多いほどいい」だけ切り出しても説得力ねーなw
227 :
2017/03/11(土) 14:56:22.01
結構人入れ替わるからコメントあったほうがいいな
228 :
2017/03/11(土) 15:40:53.65
>>226
適切なら多くならないよ?
229 :
2017/03/11(土) 15:58:29.31
適切であると多いほど良いが相入れないんだよ
もう適切だったらそれ以上増やしたら適切でなくなるだろ
コメントバカには難しいのかねぇ
230 :
仕様書無しさん
2017/03/11(土) 18:08:43.85
>>229
小さい会社、小さいシステム、小さいプロジェクト、人の入れ替わりが少ないところしか知らないからそんふうに思うんだよ。

一度、他人が作って、ドキュメントがほとんど残っない、誰に聞いてもよくわからないというひどいものを解析、メンテナンスする経験を積んだ方がいいよ。

そういう経験があれば、ただコメントは少ない方がいいなんてなんでもかんでも言うのは恥ずかしくなるから。
231 :
2017/03/11(土) 18:15:27.90
>>230
もしかしてコード読めない人の話をしてる?
そんな人にシステムは作れないからありえない話だけど
232 :
2017/03/11(土) 18:17:36.08
>>230
そういう経験もあるけど
だからと言ってコメントは多いほどいいという結論に飛躍するのはバカの証明だよ
だってそうだろう?
0はダメだったから無限に多ければいいに決まってる!なんてバカじゃないと言えないセリフだ
233 :
仕様書無しさん
2017/03/11(土) 18:21:45.44
>>230
いや経験がないのはお前だよw
未知のソースコードの解析時にコメントなんか一切あてにせんわwww

コメントが有用なのはそのソースコード全体像を把握している時なんだよなこれが
234 :
2017/03/11(土) 18:25:01.59
巨大なシステムでコードよりコメントが遥かに多くて人の出入りが激しいとか
そんなもんコメント読んでるうちに居なくなるわ
コメントマンはもう少し人間と人間のコミュニケーションを勉強したほうがいいぞ
長すぎる情報はコミュニケーション不全の主要な要因だ
235 :
2017/03/11(土) 18:26:11.00
エア大企業エンジニアだったかwww
なんか可哀想になってきたな
236 :
仕様書無しさん
2017/03/11(土) 18:26:40.52
>>232
あなたはプログラムを見るひとのレベルを配慮してないでしょ?

いくら言ってもあなたのような経験不足には分からないだろうが、いろんな立場、経歴、考え方が異なる人が見るわけだよ。

期間的には少なくとも10年後に見てもわかるようにしておかないといけない。

自分が作ったプログラムでも大量の仕事を猛スピードでやっていたら、自分が作ったのに、これなんだっけ?ということになるんだよ。

そのときに自分自身のコメントがかなり役立つ。プログラムは日本語ではないために、どううまく設計していても人間にはわかりづらい。
237 :
仕様書無しさん
2017/03/11(土) 18:29:49.30
>>233
だから巨大なクソコードからこう作った意図を読み取るのは相当難しいんだぞ?

例えばメガバンクのシステムなんて誰もなんでこうなっているのかわからない。

こんなのコードをいちいち追いかけていたらいくら時間があっても足らない。
238 :
仕様書無しさん
2017/03/11(土) 18:35:57.68
>>237
いやそれは全部読めよwそれがお前の仕事なんだけどw
なに開きなおって職務放棄してんだよカス
239 :
2017/03/11(土) 18:55:45.88
>>236
> あなたはプログラムを見るひとのレベルを配慮してないでしょ?

え?あんた配慮してるの?

配慮するっていうのは、無頓着っていう意味じゃないよ。


配慮しているというのなら、
あんたの所がやとう技術者は、それくらいのレベルかって
ちゃんと考慮してるはず。

で、どんくらいのレベルなのさ?
コメントがないとコードが読めないレベルの人を雇ってるの?
240 :
2017/03/11(土) 18:56:54.08
コード読めないのでコメントで解説してください(>_<)
241 :
2017/03/11(土) 18:58:39.89
いろんな立場、経歴、考え方が異なる人が見るわけだよ。
例えば半年前まで土木作業をやっていて
ハロワで勉強しただけの人もいる
そういう人にでもわかるように日本語で書いて
時間がいくらかかっても怒らず
丁寧に教えてあげないといけない

こちとら即戦力を集めてるわけじゃないんだ。
素人を最前線に投入して成果を挙げないといけないんだ
242 :
2017/03/11(土) 18:59:59.27
>>238
> こんなのコードをいちいち追いかけていたらいくら時間があっても足らない。

え? コード追いかける必要なんてなくね?
243 :
2017/03/11(土) 19:01:19.03
例えばOSのような複雑なものであっても
ドライバのコードを修正しようと思ったら
ドライバが入ってるディレクトリの、
該当のドライバのファイルを修正すれば良いわけで

たいていディレクトリ構造は想定できる形になってるでしょ。
244 :
2017/03/11(土) 19:04:45.99
>>241
マジレスすると、コード読めない奴にコメントで理解させたら逆効果
245 :
2017/03/11(土) 19:10:05.11
>>244
逆効果でも何でも関係ないだよ。
こちとら「仕事をして」「その成果」を報告する義務がある

コードをずっと読んでいました、どこを修正すればわかりません
では、何の仕事もしていないし、成果も何もない。

それよりも、まず仕事をすることが大事
何かする。何かしたという証拠。それを出さないといけないんだよ。

そうした結果、バグが出たのであれば、それはバグ発生率として計算し
最終的にそれが予測範囲内に収まっていれば何の問題もない。
最初に見積もって、そのとおりであれば何の問題もない

大事なのは、仕事をして予想の範囲内にコントロールすること
246 :
2017/03/11(土) 19:18:06.36
>>245
は?
247 :
2017/03/11(土) 19:20:37.47
>>246
わからんだろうなw

大企業っていうのは、これぐらいの金で
これぐらいのものっていうのが出来上がってるんだよ。

その範囲外になるのは良くても悪くてもダメ

そしてな、こちとらいろんな立場、経歴、考え方が異なる人をやとってる
そして人は入れ替わりやすい。

だから、最低のレベルの人を基準に、計画を立ててる。
その計画の範囲内であれば、どんなに悪かろうが
最初から言っていたことであり、契約でOKとなったことなんだよ
248 :
2017/03/11(土) 19:25:14.86
>>247
は?
249 :
2017/03/11(土) 19:53:18.34
大企業はこんなアホを飼う余裕あって羨ましいわ
いったい何十年前から進歩止まってるんだこいつ
250 :
2017/03/11(土) 20:02:05.73
>>245, >>247
それ大量のコメントじゃなくて、ドキュメント書いた方がいいんじゃねーの
251 :
2017/03/11(土) 20:07:51.44
>>184
こいつまだ暴れてんのか
252 :
2017/03/11(土) 20:08:49.38
>>250
うちぐらい大きいシステムを扱ってるとドキュメントなんて存在しないよ
チームメンバーはコードも読めないし読む気もない
でも大量のプレーンテキストのコメントがあるから安心さ
253 :
2017/03/11(土) 20:50:35.96
>>252
大きいシステムほどドキュメント必須だろ、バカか?
ネタなんだろうけど、面白くないよ
254 :
2017/03/11(土) 20:56:42.84
>>249
は?
いつの時代もこんな馬鹿な意見が支持された事は無いだろ
255 :
2017/03/11(土) 21:20:18.30
>>254
小さい仕事しかしたことない人にはわからないよ
コメントがあれば綺麗なコードもドキュメントもいらない
256 :
2017/03/11(土) 21:34:53.84
>>255
おじいちゃん、薬飲みました?
早く寝ましょうね
257 :
2017/03/11(土) 21:57:09.28
途中から発言がネタキャラに乗っ取られとるw
258 :
2017/03/12(日) 02:58:57.39
>例えば半年前まで土木作業をやっていて
>ハロワで勉強しただけの人もいる
>そういう人にでもわかるように日本語で書いて

「それで理解できるようなコメントが書ける」という幻想に溺れるから
毎回デスマになるんだよ。
259 :
仕様書無しさん
2017/03/12(日) 06:41:26.95
コメントがなくていいと言ってるやつは、結局、まともなコードしか見たことがないみたいなのでいくら言っても無駄だな。ガキの相手はみんなしない方がいいよ。
260 :
2017/03/12(日) 07:35:25.71
コメントがあればソース読まないとか
言い出す馬鹿がいるのはいつものこと
261 :
仕様書無しさん
2017/03/12(日) 08:02:53.09
コードは読むけどソースは読まんな
どこのおじいちゃん?
262 :
2017/03/12(日) 08:17:08.03
>>261
読めないならここに来なくていいよ?
263 :
2017/03/12(日) 09:04:39.49
このスレは小さい仕事しか経験のない人はお断りです
日に1000ステップのコメントを書ける上級者だけ書き込んでください
264 :
2017/03/12(日) 09:05:25.71
>>263
じゃあお前が書き込みできないな
265 :
仕様書無しさん
2017/03/12(日) 09:06:27.56
煽りのつもりが自分もコボラーだから煽りになってないっていうwww
266 :
仕様書無しさん
2017/03/12(日) 09:17:35.25
最近のマ板は初心者とコボラーばかりだなw
267 :
仕様書無しさん
2017/03/12(日) 09:25:35.49
大きなシステムやってると自尊心まででかくなる傾向があるよな
大きければ大きいほどいい!
268 :
2017/03/12(日) 09:44:21.04
>>267
シメジ (゚д゚)
269 :
仕様書無しさん
2017/03/12(日) 11:52:32.62
>>260
おまえさ、自分がわかるものはわかる、自分がわからないものは思考停止、無視、悪口を言って終わりにするタイプだろ?
270 :
仕様書無しさん
2017/03/12(日) 11:54:52.02
>>267
大きいというのは簡単に説明するためにそう言ってるだけであって、過去のシステムのしがらみやら、なんやら考慮しないといけない場合は、コードを読んでも細かい部分まではわからない。
271 :
仕様書無しさん
2017/03/12(日) 11:55:13.24
能力の低い人、無知に気づいてない人ほど根拠のない自信に満ちあふれている。「ダニング=クルーガー効果」とは?

http://karapaia.com/archives/52191924.html
272 :
仕様書無しさん
2017/03/12(日) 11:56:22.48
毎日、新しい数万行の他人が作ったコードを読んでいてコメントがなくていいなんて思えるのかどうか。
273 :
2017/03/12(日) 12:21:50.03
毎日数万行も人のコードを読むやつがあるものか

仕様書を見るんだ
コード読んでたら日が暮れる
274 :
2017/03/12(日) 12:29:58.46
>>272
あたま大丈夫?
275 :
仕様書無しさん
2017/03/12(日) 12:30:54.26
>>274
だってコードを見ろとしつこいやつがいるからそう書いただけなんだが。
276 :
仕様書無しさん
2017/03/12(日) 12:31:48.87
>>273
仕様書がある、まともなドキュメントがある前提の話をされてもなあ。
277 :
仕様書無しさん
2017/03/12(日) 12:32:34.90
オープンソースの有名な製品ですらまともにドキュメントがないのにw
278 :
2017/03/12(日) 12:32:57.54
ドキュメントが碌にないようなプロジェクトで
ソースのコメントが当てになるもんか
279 :
2017/03/12(日) 12:33:24.22
>>275
あたま大丈夫?
280 :
仕様書無しさん
2017/03/12(日) 12:38:36.01
初心者ばかりだな。ドキュメントなし、コードが滅茶苦茶でも現実には誰もが知っている企業の重要なシステムが動いているんだよ。
281 :
2017/03/12(日) 12:41:54.30
>>280
は?
コメントだけはまともだと思ってんの?
282 :
仕様書無しさん
2017/03/12(日) 12:52:50.49
>>281
もはや頭がおかしいとしか思えない。

ドキュメントもコードもコメントもデータも間違っていても世の中、それでなんとかなってることは多い。
283 :
2017/03/12(日) 12:57:08.93
>>282
で、お前は何を主張したいんだ?
284 :
仕様書無しさん
2017/03/12(日) 13:20:07.04
>>283
とりあえずコードかコメントがあればなんとかなる
285 :
2017/03/12(日) 13:27:43.62
>>284
は?
コメントだけがあればいいの?
286 :
2017/03/12(日) 13:40:42.30
>>284
コードがなくていいのかよwww
287 :
2017/03/12(日) 13:42:37.41
コードもコメントも要らない
面倒なことは全部下請けにやらせる
288 :
2017/03/12(日) 13:49:57.67
納品物は得体の知れないバイナリのみwww
289 :
仕様書無しさん
2017/03/12(日) 14:52:13.90
だいたいコメントを書くのが億劫なプログラマは、ダメプログラマに決まってる。
290 :
2017/03/12(日) 15:12:27.88
個人的にはトリッキーなコード以外コメントなどいらん
今見てるシステムは、ほぼ毎行のようにコメントがあって
読みづらくてイライラする
コメント行全部消してコミットしたいくらい
291 :
2017/03/12(日) 15:18:43.03
コメントに頼るのは駄目なプログラマー
292 :
2017/03/12(日) 15:53:33.50
コード毎行コメントがあるってことは、それは言語や文法の説明に過ぎないんだよね
コードは毎行毎行独立してシステム観点での意味合いがあるわけじゃない

複数行のコードの固まりではじめて出てくるシステムの中の機能的な意味合い
それを書くのがコメントだと思う
それがないとひとつのコードを見るためにシステムのコード全部辿らないといけなくなる
293 :
2017/03/12(日) 16:09:12.21
そしてな、こちとらいろんな立場、経歴、考え方が異なる人をやとってる
言語や文法が理解できない人でもコメントなら理解できる
そういう人がシステムを作ってるんだよ
294 :
2017/03/12(日) 16:22:46.03
複数行のコードの塊にコメント付けるのはマヌケ
適切な名前でメソッド化するのが良識あるプログラマ
295 :
2017/03/12(日) 16:43:56.95
>>294
メソッド化するならそれ自体が単体で何かの機能を持っていないといけない。
しかし一つの関数の中には、それ自体をメソッド化する意味がなく他の関数から呼ぶ意味もない
関数の一部としてのみ意味のある2行から10行ぐらいの処理の固まりがいくつかあるんよ

汎用性もない曖昧な意味の関数の山だらけなど作られたらそれこそ見てられんわ
296 :
2017/03/12(日) 16:51:30.64
>>295
それは設計が下手なだけ
297 :
2017/03/12(日) 17:06:42.21
>>295
関数にする目的は、処理の塊に名前をつけるためだよ。
それだけだけじゃなくて明確にスコープを分けるとか
塊同士のインターフェース、つまりどんな値を使って
どんな値を返すかを明確にするとかの意味もある
298 :
2017/03/12(日) 17:11:15.89
>>296
それってどれだ?
設計の上手い人ならどうなるとおもってる?

単体で何の機能も持たない単位でメソッド化する?
それとも、すべての関数が10行未満で、かつ意味のある機能名をつけてメソッド化ができる?
それとも、関数の中に2行から10行ぐらいの意味のある固まりはできない?
299 :
2017/03/12(日) 17:18:11.04
>>298
複数行のコードの塊にコメント付けるのはマヌケ
300 :
2017/03/12(日) 17:18:36.07
>>298
コメントつけなきゃ判らない
しかも、関数化できるほど処理がまとまってない

どう考えても設計が下手なだけ
301 :
2017/03/12(日) 17:21:19.05
例えばエラー処理なんて典型的な例

チェックコードと、エラーになった時の出力などで
2行ぐらいになる。

その程度でわざわざ関数にするの?

// ここからエラー処理

って書けば十分だろ
302 :
2017/03/12(日) 17:21:56.04
>>301
そんなコメントいらんだろ
303 :
2017/03/12(日) 17:22:41.44
>>299-300
いや質問に答えてくれ
設計の上手い人が書いたコードはどうなる?

単体で何の機能も持たない単位でも関数化している?
それとも、すべての関数が10行未満で、かつ意味のある機能名をつけてメソッド化している?
それとも、どの関数の中にも2行から10行ぐらいの意味のある固まりはできない?
304 :
2017/03/12(日) 17:23:37.87
>>303
話が理解できないのか?

答は「コメントは書かない」だ
305 :
2017/03/12(日) 17:24:59.56
> それとも、どの関数の中にも2行から10行ぐらいの意味のある固まりはできない?

できない
306 :
2017/03/12(日) 17:25:34.37
>>303
コメントが必要なら関数化しろと言ってる
307 :
2017/03/12(日) 17:28:08.17
関数の中に2行から10行ぐらいの意味のある固まりができたら
// ここからエラー処理
みたいなコメント書くだろ
308 :
2017/03/12(日) 17:30:27.67
>>307
少なくともそんな設計にはしない。
309 :
2017/03/12(日) 17:31:35.86
長い関数があった時

function foo() {
 長い処理A
 長い処理A
 長い処理A

 長い処理B
 長い処理B
 長い処理B
 長い処理B
}


長い処理Bで、長い処理Aの変数を使ってはいけない理由はなんですか?
310 :
2017/03/12(日) 17:32:03.15
>>304-306
つまり設計の上手い人が書いたコードは、一切のコメントが皆無だというお話ですか
勉強になりますわ
311 :
2017/03/12(日) 17:32:46.56
> つまり設計の上手い人が書いたコードは、一切のコメントが皆無だというお話ですか

どこをみてそう思った?
ちょっと引用してみてよ
負け犬さんw
312 :
2017/03/12(日) 17:33:55.80
>>309
理由?
コード書いた奴が馬鹿だから
313 :
2017/03/12(日) 17:34:17.51
// 変数宣言
// 初期化処理
// メイン処理
// 終了処理
// エラー処理


どの関数にもこれぐらいあるだろ

場合によっては
// メイン処理1
// メイン処理2
// メイン処理3
とかになる
314 :
2017/03/12(日) 17:35:31.88
>>311
明確に書いてあるじゃねーか

> 答は「コメントは書かない」だ
> コメントが必要なら関数化しろと言ってる
315 :
2017/03/12(日) 17:37:35.81
>>314
「複数行の塊に」が消えてしまってますぜwww
316 :
2017/03/12(日) 17:39:07.51
http://aspesyn.com/tokutyou1/

アスペルガー症候群の人は、たくさん発言するわりには、
話のテーマや狙いを理解しておらず、会話ができているようでできていないことが多いです。

コミュニケーション面で問題になるのは、理解力です。

アスペルガー症候群の人は、言いたいことを言うのは得意ですが、話を聞いて理解するのは苦手です。
特に、長時間の話や複雑な説明を聞き取ることができません。
317 :
2017/03/12(日) 17:39:22.61
>>313
で、それが関数化できない理由は?
318 :
2017/03/12(日) 17:40:25.37
アスペルガー症候群の人のコミュニケーションの特性は次の通りです。

一人で一方的に話を続け、人の意見を聞こうとしません。
話の流れや文脈が理解できず、会話についていけません。
慣用表現がわからず、大げさな表現を真に受けます。
独特の言葉づかいをして、自分だけに通じる言葉を使います。
話し方がぎこちなく、学者のような難しい言い回しで話します。
会話がパターン化し、型通りのセリフで返答します。
319 :
2017/03/12(日) 17:44:16.49
>>315
複数行の固まりに書かないなら
各行に書くてことじゃねーかw

一行一行の説明コメントはいらんわw
320 :
2017/03/12(日) 17:46:38.13
>>319
論理的思考力も無いのな
321 :
2017/03/12(日) 17:47:17.65
>>319
> 複数行の固まりに書かないなら
> 各行に書くてことじゃねーかw

???

明確に書いてあるじゃねーか

> 答は「コメントは書かない」だ
322 :
2017/03/12(日) 17:49:04.28
複数行の固まりコメント書かない?
各行にも書かない?

じゃあどこにコメント書くんだよ
323 :
2017/03/12(日) 17:49:57.38
複数行の固まりコメント書かなくて、
各行にも書かないということは
一切のコメントが皆無だという話だ
アスペはお前だ
324 :
2017/03/12(日) 17:51:14.54
>>323
コメントの書き方も知らないのな
325 :
2017/03/12(日) 17:52:28.49
>>317
初期化処理の中身が1行2行ならわざわざ関数化しないね
アスペは何が何でも形式どおり関数化するみたいだが

またメソッドの呼び出しと呼び出しに必要なパラメータの初期化、そのエラーチェック
まとめて一つの固まりとすることはあるね。
設計上その関数からしか呼び出さず特に関数化するメリットがない場合
326 :
2017/03/12(日) 17:53:04.04
>>325
お前は日本語すら理解できないのか
327 :
2017/03/12(日) 17:53:18.99
k・o・m・m・e・n・n・t・o

コメントの書きたぐらい知ってますが何か?ぷ
328 :
2017/03/12(日) 17:54:30.14
>>325
> 初期化処理の中身が1行2行ならわざわざ関数化しないね

だろーだろー

だから言ってるんだよ。

そういう場合に //初期化処理というコメントをつけるべきだって
329 :
2017/03/12(日) 17:55:02.44
>>328
明確に書いてあるじゃねーか

> 答は「コメントは書かない」だ
330 :
2017/03/12(日) 17:56:20.02
>>327
コッメント?
331 :
2017/03/12(日) 17:56:21.51
関数の中に2行ぐらいの塊があると認めてるくせに
コメントを書かないとか矛盾してるw
332 :
仕様書無しさん
2017/03/12(日) 17:56:30.62
変なじいさんがコメントコメントうるさいせいでコメントを書けない真の馬鹿が調子づいてしまったじゃないかw
333 :
2017/03/12(日) 17:56:56.41
>>330
英語だよばーかw
334 :
2017/03/12(日) 17:57:00.73
>>324>>326
煽るだけで意味のあるコメントが皆無だな
コードもそうなんだろ、きみは確かにコメントは書かない方が正解だ
335 :
2017/03/12(日) 17:57:44.84
>>324>>326
煽るだけで意味のあるコメントが皆無だな

>>それ以外のレス
何も良い返す言葉はありません
336 :
2017/03/12(日) 17:58:28.41
俺のふりすんなバーカ
337 :
2017/03/12(日) 17:59:34.15
>>335
334だが、だれだおまえ
気持ちの悪い奴だ
338 :
2017/03/12(日) 18:00:59.60
>>301
エラー処理なんてアスペクトぶち込んで真っ先に共通化する部分だろ
339 :
2017/03/12(日) 18:02:43.55
アスペクトは使わん。
フレームワークなどの共通部分で
処理するだけでいい
340 :
2017/03/12(日) 18:02:48.06
>>328
メソッド化しろよ
コメントは注釈であって処理のブロック化のための構文じゃないぞ
341 :
2017/03/12(日) 18:05:33.39
>>333
え?
342 :
2017/03/12(日) 18:06:26.69
長い関数があった時

function foo() {
 長い初期化処理A
 長い初期化処理A
 長い初期化処理A

 長い処理B
 長い処理B
 長い処理B
 長い処理B
}


長い処理Bで、長い初期化処理Aの変数を使うのにどうしろと?
343 :
2017/03/12(日) 18:07:54.68
>>309はそれを見越したレスだったのかw
いきなり何を言い出すのかと思えば
先読み能力すげーなw
344 :
2017/03/12(日) 18:10:09.49
>>340
処理のブロック化のためにコメント使っていけない理由は?
後にメンテするやつが見落とさないためのコメントでもあるんだぜ
345 :
2017/03/12(日) 18:10:49.61
> 処理のブロック化のためにコメント使っていけない理由は?

もっといい方法があるから
346 :
2017/03/12(日) 18:11:23.01
じゃあそのもっといい方法を使えばいいだけだろw
347 :
2017/03/12(日) 18:13:33.60
関数化した方がいい場合は関数化すればよい
関数化のメリットがない場合はコメントでブロック化すればよい
348 :
2017/03/12(日) 18:18:39.44
>>342
ローカル変数にするのが間違い
349 :
2017/03/12(日) 18:21:43.77
>>344
コメント事実を示している保証が全くない
メソッドであるべき処理をインライン展開すると無駄なローカル変数などが生じる
処理の順番を組み替えにくい
コンパイラや解析ツールのサポート得られない
テストしにくい
もう最悪だお前は死ね
350 :
2017/03/12(日) 18:27:24.54
経験したこと
・コメントが間違ってる
・コードは修正されているがコメントは修正されていない
・全ての仕様書が正しい状態で存在するわけではない

コメントが不要というわけではない。
コメントに過剰な期待はできない。

要はコードを要領よく読んで理解するしかない。
351 :
2017/03/12(日) 18:45:21.56
>>349
ローカル変数が必要になるような、メソッドであるべき処理ならメソッド化したらいい
意味のない単位で関数化をすべきじゃないというだけ
関数内での処理の組み替えはブロックコメントがあれば便利だ
ブロック単位で移動させればよいのでな
コンパイラや解析ツールのサポート得られないってどういうことやねん
意味のない関数化については1関数当たりのテスト項目は減るが、
関数の数と組み合わせが増えるのでトータルでは同じだ

もちろん意味のある関数化は絶対すべきで、テストも大幅に削減できる
352 :
2017/03/12(日) 18:53:23.31
>> 350
コードで理解できるのはコードに書かれているロジックだけだ
まともなコードでは、設計の意図を推察するのに多少間違っててもコメントが非常に助かる

もちろんクソ設計のクソコードだとコメントだけまともに書くのは不可能だし、
形式的に書かされたもので、何の役には立たんどころか振り回されて足枷にしかならないのはわかる
353 :
2017/03/12(日) 18:58:10.88
>>351
意味のある単位だからメソッド化するんだよ死ね
ほんのちょっとだけだからなんて猿以下の理由でメソッド化をサボってコメントにするな死ね
コメントで管理したブロック単位で移動したらローカル変数などの影響をじっくり考えなければならないので保守性最悪なんだよ死ね
コンパイラや解析ツールも知らないドッ素人が生意気に口聞いてんじゃねえよ死ね
テストしにくいのは数の問題じゃねえよ依存性独立性諸々考えろ死ね
死ね死ね死ね老害禿げ死ね
354 :
2017/03/12(日) 19:01:25.64
まるで関数とコメントが可換であるかのようなこの流れ
やはり>>284は正しかったのか?w
355 :
2017/03/12(日) 19:07:35.39
>>354
今はまとまりのあるコードブロックをコメントで管理する場合の話をしているから流れは問題ない
356 :
2017/03/12(日) 19:10:43.41
>>353
意味のある単位でならぜひメソッド化してくれ
意味のある単位なら2行でも関数化することもあるし、分割の意味がないなら100行でも1関数にしたらよい
それ以上になると意味のある単位で分割できないこと自体があまりない

> コメントで管理したブロック単位で移動したらローカル変数などの影響をじっくり考えなければならないので保守性最悪なんだよ死ね
そういうところは本来メソッド化した方がいい処理だ
メソッド化しろ
依存性独立性強度結合度考えた結果、関数化すべき部分はして、すべきでない部分はするな
ただ長いと可読性落ちるからブロック化はしておけ
357 :
2017/03/12(日) 19:14:20.23
>>355
つまり関数化したらコメントは不要、関数化しなければコメントが要る
と言ってるわけだろお前らは?
やっぱり可換じゃないかw
>>284の言う通りだろこれw
358 :
2017/03/12(日) 19:23:07.24
>>357
お前は話に全然付いてこれてないぞ
メソッドであるべきところでメソッドをインライン展開してコメントを付けるのはやめろという話をしてんの
コメントと関数が可換なんて誰も話してないだろよく読めよ
359 :
2017/03/12(日) 19:26:31.03
>>357
お前は日本語理解できない無能だな
360 :
2017/03/12(日) 19:27:12.85
>>357
そこまで極端じゃない多少は可換な部分もある
ただ関数毎にヘッダコメントは書くから、結局関数化した方がたくさん書くんだけどね
361 :
仕様書無しさん
2017/03/12(日) 19:33:05.63
>>360はマトモ
>>358,359はバカw
362 :
2017/03/12(日) 19:36:18.14
>>361
お前はダニ
日本語勉強してから出直してこい
363 :
2017/03/12(日) 19:40:03.41
>>360
タイプ量の問題じゃないぞ
コメントブロックアンチパターンはな
変数のスコープが無駄に延長されたり本来分離されているはずの複数の処理の関係性がわからなくなったり
そもそもその処理がどこに書いてあるかわからなくなったり
本来その処理と関係ない別の理由なのにその処理を修正しなければならなかったり
といったように保守性の低下が最大の問題だ
364 :
2017/03/12(日) 19:42:04.66
なんか必死のやつがいるようだな。

書かない方がいい「無駄なコメント」というのがある。
これは、書かなくてもコード読めばわかる内容のもので
書いてる意味がなく、保守コストを考えると「消すべき」ものとされる。

当然「書くべきコメント」というのも存在する。

この「無駄なコメント」しか書けない奴は、
往々にして「書くべきコメント」を理解していない。
なので、無駄なコメントを書くなと言われると
 書くコメントが無くなるだろ!
と大騒ぎする。

まともなコメントを理解できていないやつに
正しいコメントを理解させるというのは困難だという事。
365 :
仕様書無しさん
2017/03/12(日) 19:53:16.38
バカの真打登場で一気に沈静化w
366 :
2017/03/12(日) 19:53:49.36
コメントには知力がもろに出る
頭が悪い奴は無駄なコメントが多い
賢い奴はまずコメントが要らなくなるように書けないか書き方を模索する
最後にコードやツール、他の文書からは判断し得ない意思決定の根拠や残課題、良くまとまったサマリー、参照すべき文献名などをコメントに残す
ここからここまでナントカの処理などといった無様で厚顔無恥なコメントは決して書かない
367 :
仕様書無しさん
2017/03/12(日) 19:55:07.61
なんか必死のやつがいるようだなw
368 :
2017/03/12(日) 20:04:48.09
>>363
それはコメントブロックアンチパターンではなく、
本来関数化するべきものが関数化されていないというアンチパターンだろ

ほとんどどんな関数の中にも、それだけでは独立して意味を成さない小さな単位がある
それをコメントでブロック化するのは、文章に句読点を付けるようなものだ。
369 :
2017/03/12(日) 20:10:26.57
>>301
エラー処理とか見りゃわかることにわざわざコメントつけんなよ
370 :
2017/03/12(日) 20:10:35.19
>>368
関数にできない意味のない小さなブロックにはコメントも付かないんだよ
良く考えろ
意味のない処理にいったいどんなコメントを書くというのだ

// ここから意味のないブロック

// 意味のないブロックおしまい

まさかこんなコメントは誰も書かないだろう
コメントでブロックをくくる以上は何か意味があるはずだ

// ナントカ処理開始

// ナントカ処理おしまい

こうなっているはずだ
だったらコメントなどにせずそのまま"ナントカ処理()"というメソッドにくくり出せばよろしい
371 :
2017/03/12(日) 20:11:49.49
>>365 >>367
反論できないんだったらおとなしくしてろよw
372 :
2017/03/12(日) 20:12:54.20
具体的なコードなしによくここまで騒げるな
373 :
仕様書無しさん
2017/03/12(日) 20:16:19.95
>>327 k・o・m・m・e・n・n・t・o

こっめんとwww

>>333 英語だよ

 英語wwwwwwwww

あほが騒ぐとすごいなぁ
374 :
2017/03/12(日) 20:17:13.97
>>372
こういう議論は完全な一般化は無理でも多くの場合に当てはまるというところまではいける
おろそかにするべきではない
375 :
仕様書無しさん
2017/03/12(日) 20:20:26.55
A: コメント書けよ
B: やだ!書きたくない

議論なんかこれw
バカって面白いなw
376 :
2017/03/12(日) 20:24:13.25
>>375
そろそろコテハンつけてくれ
377 :
2017/03/12(日) 20:25:35.64
>>375
k・o・m・m・e・n・n・t・o 英語だよ(キリッ

とか言ってるお前には難しい議論で内容が理解できないんだなwwww
378 :
2017/03/12(日) 20:35:05.94
>>370
関数内の文脈としてはどのコードにも意味があるが、
そのまま関数として切り出しても意味がないものがある。

たとえば
if(x>THRESHOLD){
x=THRESHOLD
}
これ単体では「xがなんかの値より大きかったらxをなんかの値にする」以外の何の意味もないだろ
これだけ関数化しても何の意味もないよね。
(まあこれは意味も明確だし関数化してもよいかもしれないが一つの例として聞いてくれ)

ところが特定の関数の中では「〇〇の上限を△△の規定値に切り捨てる」という意味付けができ
この3行で文脈上一つの意味があるブロックだ。
コメントもそう書けばよい。
379 :
2017/03/12(日) 20:39:30.58
>>378
そんなコメントが必要な理由は?
380 :
2017/03/12(日) 20:46:18.70
>>379
関数の仕様書を元に決められた処理を書いたり、関数単体のテストをするだけなら要らんさ。
処理のロジックも見りゃわかる。

じゃあコメントでは何を知りたいの?っていったら
システム内でのその処理の意味や設計を知る必要があるからだ。
381 :
2017/03/12(日) 20:48:46.02
>>379
そういう聞き方では「理解できない」だろうな。
コメントは何でもいいから書くものと理解しているので
コメントに必要性を感じたことなんてないだろうから。

具体的に書いてやるといい
たとえば、

switch(x){
case 0:
  y = x ;
  // no break
case 1:
  x ++ ;
  break;

といったコメントの場合、
「コメントがない場合、break忘れかどうかの判断がつき辛いから」
という、コメントが必要な理由は明確に示される。

ということを踏まえて、
>>378の例では
「コメントがない場合、どのような不都合が発生するのか」
を答えてもらうようにすると話は早く終わるだろう。
382 :
2017/03/12(日) 20:49:11.97
>>378
https://msdn.microsoft.com/ja-jp/library/hh308289.aspx
if文も変数の書き換えもコメントも不要だ
君が無知なだけ
383 :
2017/03/12(日) 20:52:14.68
>>382
話を発散させるな
384 :
2017/03/12(日) 20:56:19.78
>>381
そこはどういうコメントを書けばわかりやすいかなと悩む場面ではなく
まずは最低限こう書き換えればいい
switch(x) {
case 0:
y = x++;
break;
case 1:
x++;
break;
}
そのあとでさらにコードを明快に洗練できないか考えたあとで意味があるまとまりならメソッドにすればよろしい
コメントも不要である
385 :
2017/03/12(日) 20:57:57.35
>>382
話をすすめる上で、
相手の出した前提条件を無視するのはやってはいけないこと
386 :
2017/03/12(日) 21:02:49.16
>>384
コードを可読的に単純化したことすら理解できないのか。

結局、>>384の出してきた提案ってのは
case 0: 処理A + 処理B break;
case 1: 処理B ; break;
に変換して、処理A + 処理Bを編集したって回答だよな。

保守のこと考えると、
やってはいけないことだってことくらい理解できない?

処理は一本化すべきところは分けて記述すべきではない
387 :
2017/03/12(日) 21:03:21.43
>>385
前提って?
明確にしてくれ
388 :
2017/03/12(日) 21:05:19.19
>>384
話を発散させるな
>>387
お前も理解できないなら黙ってろ
389 :
2017/03/12(日) 21:11:20.56
>>387
日本語くらい理解しろよ・・・
390 :
2017/03/12(日) 21:11:53.88
>>386
フローの単純化は真っ先に検討するべき事案だ
これはたかだか2つのswitchだから気にならないかもしれんが
システムの拡張でこの分岐は増える
増えてくるとswitchでは手に負えなくなるのでメソッド化する
ここでcaseからcaseへのフローがなければ作業は容易い
しかしフローが存在すると作業は一筋縄ではいかなくなる
フローの単純化は可読性の高いコードを書く上で基本中の基本だからぜひ今日のうちに覚えておいてくれ
391 :
2017/03/12(日) 21:12:17.62
>>389
前提って何?って日本語理解できなかった?
392 :
2017/03/12(日) 21:17:52.13
switchでbreakしないのは完全にバッドプラクティスだ
言語によってはコンパイルエラーにする程に悪しきものと判断されている
例えコメントで補助しようが許される行為ではない
393 :
2017/03/12(日) 21:18:16.13
>>390
あぁ、例が理解できなかったんだな。
まさかそこまで理解力がないとは思わなかったよ。すまんね。
switch(x){
case 0:
  処理A ;
  // no break;
case 1:
  処理B ;
  break;

だと理解できる?
394 :
2017/03/12(日) 21:19:18.58
>>393
名前忘れた・・・
専ブラ使えないのは面倒だねぇ orz
395 :
2017/03/12(日) 21:20:07.29
>>392
んなわきゃない
396 :
2017/03/12(日) 21:21:14.65
>>381
no breakはみりゃわかるだろw
break忘れかどうかの判断のためには、コメントに「no break」と書くことじゃなく、
なんで「no break」にしたかを書くことが重要なんだ。

コメントにはロジックの説明じゃなく「何をしたいか」が重要だ
一つのコードは書かれたあと幾度となく見られるが、みんな詳細なロジックを見たいんじゃない
システムの中でその処理がどんな役割を果たしてるかが知りたくてコードを追うことの方が多い


>>391
話を進める上での「一つの例として聞いてくれ」と明記してあるんだ
処理自体をどう実装すべきかとかライブラリを使えばできるとか
そういう話がしたいんじゃないことがわからんか
397 :
2017/03/12(日) 21:23:28.61
>>393
同じ事だろ

case 0:
A();
B();
break;
case 1:
B();
break;

うん明快だな
398 :
2017/03/12(日) 21:25:00.97
>>392
そんなこと言い始めたら、
continueや関数途中のreturnも使えない。

「避けるべき理由」と「使うべき理由」を正しく比べて
必要なところではちゃんと使うというのが正しいコーディング。

極端なことを言えば、
「そもそもコメントは書くべきではない」
んだから。
特殊なところにコメントを書くのはごく当たり前のこと。
399 :
2017/03/12(日) 21:27:17.96
>>397
同じ処理が複数ヶ所に存在してしまうのは初歩的な失敗だな。
本当にそっちのほうが正しいと考えているのなら、経験不足すぎる。
400 :
仕様書無しさん
2017/03/12(日) 21:29:45.10
このスレに書き込んでいるプログラマのレベル異常に低い。ありえないほど低い。経験がなさすぎるか、経験がないのにものを言っている。
401 :
2017/03/12(日) 21:30:20.65
>>396
この流れで俺が例を認めたらダメだろ
疑似的にコメントでブロック化して意味付ける価値はあるがメソッドにする意味はないコードが存在する
っていう主張を否定してそんなものはないって言ってるんだよ俺は
例を出すなら半端な嘘の例じゃなくてまさにその通りコメントでブロック化する価値はあるがメソッドにする価値は全くないまとまりを例示してよ
402 :
2017/03/12(日) 21:36:12.26
>>398
returnはむしろそこでフロー終端でそのあとを考えなくて良いというマークになるから可読性は上がる
例えば深いネストの分岐で変数の値を書き換えて最後にreturnするコードってあるだろ?
ああいうのはreturnを使って書き換えるとネストが平坦化など分岐単純化が誘発されて可読性が上がる
continueもそこでこのループ1回に関してはキッカリここで終わりっていうマークだから同じように考えられるだろうね
だろうねと言ったのは俺はcontinueを使わざるを得ないほど長いループは一回も書いた事ないからね(マジだよ)
403 :
2017/03/12(日) 21:40:05.24
>>399
理解が足りてない
同じ処理が複数ってのは例えばこういうコードな

case 0:
A();
x = x * 2;
y = x + 5;
print x, y;
break;
case 1:
A();
x = x * 2;
y = x + 5;
print x, y;
break;

さっきのはわかりやすいようにわざわざB();って書いてあげたでしょ
404 :
2017/03/12(日) 21:41:00.62
>>401-402
ちょっとなにいってるかわかんない
話を引っ掻き回したいだけなら黙ってたら?
405 :
2017/03/12(日) 21:43:04.31
>>403
バカがいる・・・
406 :
2017/03/12(日) 21:45:24.83
>>401
本題なら、そもそもライブラリを使おうが使うまいがコメントは必要だ。

ライブラリを使おうが使うまいが「意味付け」されたコメントが必要ってことが>>384の主張でしょう。
MSのライブラリ使うとかまったく関係ない話だ。
407 :
2017/03/12(日) 21:47:05.09
すまん、アンカー間違い

>>401
本題なら、そもそもライブラリを使おうが使うまいがコメントは必要だ。

ライブラリを使おうが使うまいが「意味付け」されたコメントが必要ってことが>>378の主張でしょう。
MSのライブラリ使うとかまったく関係ない話だ。
408 :
2017/03/12(日) 21:53:02.32
>>406
ああそういう理解なのね
こっちはライブラリ使えって言ってるんじゃないよ(一回も言ってないよな?)
clamp(他にふさわしい名前があるならそれでもいい)っていうメソッドがないなら作ってそっち使えって言ってんの
メソッド化できるしする価値があるところでなんでわざわざ意味がわかりにくいif文や不要なローカル変数の書き換えみたいな遠回りなコードを書いておいてそれをご丁寧にコメントで補足するのよ?
409 :
2017/03/12(日) 22:00:06.05
>>407
コメント必須じゃないだろどう考えても

// 上限を固定する
if (x > max)
x = max;



上限を固定する(x);

これでいいだろ
それとも

// 上限を固定する
上限を固定する(x);

こんなバカなコメントを書くのか?
コメント書くにしてもメソッドのドキュメントコメントで十分だ
ドキュメントコメントは有用だから否定しないよ
410 :
2017/03/12(日) 22:03:04.96
>>408-409
だからclamp一行で書いたら
「〇〇の上限を△△の規定値に切り捨てる」というコメントも要らんくなるの?
ロジックの説明を残したいわけちゃうんやで、
何の上限を何の目的で切り捨てて何がしたいかを残したいんやで

めんどくさいやっちゃな
411 :
2017/03/12(日) 22:17:20.91
>>408-409
ちょっとなにいってるかわかんない
話を引っ掻き回したいだけなら黙ってたら?
412 :
2017/03/12(日) 22:26:17.34
もうめんどくさいから仕様書の文章そのままコピペのコメントにしようぜ
413 :
2017/03/12(日) 22:32:55.59
仕様書は修正に時間かかるから、コードから仕様書にコピペの方がめんどくさくない
414 :
2017/03/12(日) 22:51:36.94
>>410
clampで通じないなら意味のわかるメソッド名を付ければ良い
コメントは不要
415 :
2017/03/12(日) 23:03:42.08
>>414
ちょっとなにいってるかわかんない
話を引っ掻き回したいだけなら黙ってたら?
416 :
2017/03/12(日) 23:04:05.48
物分かり悪い子ばかりで疲れたよ
適切なモデリングを行ない不要なコメントを削除せよってだけの話なんだけどな
417 :
仕様書無しさん
2017/03/12(日) 23:08:55.44
コメント関連のスレのはずなのに、いつの間に「初心者のためのC講座」
になってしまったんだ?w

「コメントは必ず書け。ただし、必要最小限に」

これで十分では?
418 :
2017/03/12(日) 23:25:30.15
そりゃ初心者でもできる話題がそれだけだからですよ
419 :
2017/03/13(月) 00:05:30.55
>>416
疲れるのはお前の頭が悪いからだよw
420 :
2017/03/13(月) 00:34:15.36
結局さ、コメントで書くよりも
コードで書いたほうが良いわけだよね
421 :
2017/03/13(月) 01:08:32.36
>>420
結局はそう。
コメントってのはあくまでも「注釈」だから
必要の無い場面では完全に不要なもの。

コードに意図が表せない場合や、
コードを読む際に疑問に思うだろうところに
コメントを入れるというのが正しいスタイル。

第三者の視点でコードを読んで、
「あれ、これってどういうこと?」
ってコーディングした奴に聴きたいところが出てくれば、
まずはコードで意図を伝えることを試みて、
それでも直さない理由が他にあるのなら、
その質問に対して回答をするような情報をコメントに書いておく。

というのが、正しいコメントの書き方。

コードは保守で更新されるけど、
コメントは正しく更新されないから無駄に書くと大変なことに・・・
422 :
2017/03/13(月) 01:38:22.95
いやコードもコメントもどっちも書いてメンテしろよw
423 :
2017/03/13(月) 01:45:14.60
>>422
コードは試験で品質保証するけど
コメントは品質保証する手だてが無いからな
424 :
2017/03/13(月) 02:16:38.37
int foo(int a, int b) {}

こういうのってコメント書くのが面倒なんだよな
何故かと言うと、だいたいこんな感じのコメントを書くことになるから

// なんとかを行う関数
// 引数
// a: ○○の値
// b: ○○の値
// 戻り値
// なんとかの値
int foo(int a, int b) {}

「引数」とか「戻り値」なんて情報はいらないし、
aとかbとか引数に書いているわけでdryじゃない。
そもそもaやbという変数名で説明十分な場合もある。

もう少し効率的な関数や引数に対するコメントが書けるような文法が必要だと思う。
例えばこんな感じ

int foo()  // なんとかを行って、なんとかの値を返す関数
 int a // 必要ならばaのコメントを書く
 int b // 必要ならばbのコメントを書く
{
}

ANSI C標準以前の関数宣言に似てるけどfoo()の中身が省略できるところが違う
コメントは全てオプションで、必要なければ書かなくても良い。
コメントを書く場所を決めることで、何に対するコメントかがはっきりする
425 :
2017/03/13(月) 02:20:24.43
少し改良、() いらないし、// よりも # の方が見やすいかなと思って

int foo  # なんとかを行って、なんとかの値を返す関数
 int a # 必要ならばaのコメントを書く
 int b # 必要ならばbのコメントを書く
{
}
注意 引数の場所のインデントは必須


複数行コメントの場合

# なんとかを行って
# なんとかの値を返す関数
int foo
 # 必要ならばaの
 # コメントを書く
 int a
 # 必要ならばbの
 # コメントを書く
 int b
{
}
426 :
2017/03/13(月) 02:26:06.74
そうか、YAMLのブロックスタイルとフロースタイルの
両方の書き方ができると考えれば良いのか

これをフロースタイルとして考えて
int foo(int a, int b) {}

コメントを入れやすい、ブロックスタイルの書き方がこんな感じと

int foo
 - int a
 - int b
{
}
427 :
2017/03/13(月) 02:34:00.89
まあやってる人見たことないけど、こういう書き方が普及すれば、
今の文法でも不可能ではないけどねw

// 関数のコメント
int foo(
 int a, // 引数のコメント
 int b // 引数のコメント
) {
}
428 :
2017/03/13(月) 03:00:19.60
>>427
実際にそういうコーディング規約のところはある
厳密には
// 関数のコメント
int foo(
  int a // 引数のコメント
 ,int b // 引数のコメント
) {
}
と、引数区切りの「,」の位置が違うけど。
こうしてないと、引数追加の時に差分が二行に渡ってしまう。
429 :
2017/03/13(月) 03:22:55.50
コメントは必要だけど
int a; //最大値
は邪悪だな。
int max;
とすべきだろう。
430 :
2017/03/13(月) 04:16:45.90
>>429
それな

ドキュメントを生成するためか、コーディングスタイルで
コメントを書くことを強要するのがよくあるけど、
関数名、もしくは引数名で内容がわかるから意味が無いってことが多々ある。
ああいうのはダサいコメントだともう
431 :
2017/03/13(月) 04:22:07.10
コードの中に書くコメントは別だけど、
関数名とか引数名に関するコメントというのは
アノテーション相当だと思う

同様に変数のコメントもアノテーションだし
コードの中に書くコメントのうち、
塊に関するコメントも、ブロックを作ることで
アノテーションとして定義することはできるだろう。

と考えると、自由にかけるコメントっていらなくないか?

何が言いたいかというと、コメントは無視される物ではなくて
言語仕様としてきっちり文法の中に組み込んだほうが良いのではないかということ
432 :
2017/03/13(月) 04:35:16.08
>>431
とりあえず
「アノテーション」って言葉を覚えて
嬉しがって使っていることだけは伝わってきたよ

よかったねー
433 :
2017/03/13(月) 04:43:00.48
>>432
え?なに?アノテーションって言われて
なにか劣等感でも感じたの?

アノテーションコメントとか
ドキュメンテーションコメントとか
言い換えてあげてもいいけど、

もっと劣等感感じるかな?
そんなもの俺は知らない!ってw
434 :
2017/03/13(月) 04:47:46.44
Railsのアノテーションコメントは TODO: や FIXME: と
書くことで、アノテーションコメントになるけれども
各場所を決めることですべてのコメントが自然な形で
アノテーションコメントとなるような言語仕様を作るといいだろうね
435 :
2017/03/13(月) 11:33:51.77
コピペプログラマと会話すると
アノテーション?何それ
みたいなやつが居るからそこから説明が必要なんだよな
436 :
2017/03/13(月) 12:55:14.13
>>432
アノテーションくらいは知っとこうぜ
437 :
仕様書無しさん
2017/03/13(月) 18:24:08.31
コピペで済むような仕事で変に独自性出そうとすんなよ
438 :
2017/03/13(月) 18:37:19.07
// ループ
439 :
仕様書無しさん
2017/03/13(月) 22:11:41.24
>>404
よく読んではいないが、いろんなところでプログラムが終わるコードは悪いプログラムだよ。
440 :
2017/03/13(月) 22:13:26.25
>>429
わかるけど
いろんな最大値がでてきて結局コメントも書いちゃうこと結構ある
441 :
仕様書無しさん
2017/03/13(月) 22:15:22.81
>>409
そもそもコード上の名前と作った本人が思っているものが違うことがあるから、コメントは必要。

その例だとmaxという名前でも英語のmaxの意味で使ってない可能性もあるし、maxではなく正反対のminのつもりで命名していることもある。
442 :
2017/03/13(月) 22:29:40.48
>>441
は?
443 :
2017/03/13(月) 22:46:27.24
理屈がバグってる
444 :
2017/03/13(月) 23:55:48.42
>>441
コード上の名前と
作った本人が思っているものと
コメントが違うことがある

コメントがあれば、これがどう解決するの?
445 :
2017/03/13(月) 23:57:55.93
>>441
> その例だとmaxという名前でも英語のmaxの意味で使ってない可能性もあるし、maxではなく正反対のminのつもりで命名していることもある。

そして、コメントには中間値を求めるって書いてあるわけだよなw
446 :
2017/03/14(火) 00:33:13.04
/* 444げっち(´・ω・`)b */
447 :
2017/03/14(火) 02:27:06.38
/* 444げっち(´・ω・`)b */
448 :
2017/03/14(火) 02:31:14.82
449 :
2017/03/14(火) 02:52:20.71
450 :
2017/03/14(火) 13:33:47.48
451 :
仕様書無しさん
2017/03/14(火) 15:27:24.62
>>445
そうだよ。人によっては物の命名がおかしくてまったく違う意味で使ってたり、途中で中身を変えてそのままだったりする。

そこで下手なコメント、変なコメントであってもそれを手がかりにバグなのか仕様なのか推測できる。
452 :
2017/03/14(火) 16:25:19.54
>>451
そのコメントがバグってたらどうしていいものか
453 :
仕様書無しさん
2017/03/14(火) 19:03:33.27
コメントがしっかりしてるとこはソースコードレビューがしっかりしてるからコードと違うコメントが残ることはない
逆にダメなチームのソースコードにはそもそもコメントが入ってない、彼等はコメントを無駄な物だと考えているからな

つまりだ
基本的にコードと違うコメントが入ったソースコードという物はこの世に存在しない
お前らはよくあるように言うが、実際にそのような代物を見たことがある訳がない
存在しないのだからな

問題なのは、どうしてお前らがネットで仕入れた根も葉もない噂を
さも実際に経験したかのようにつまらんウソをつきたがるのか?という事だ
454 :
2017/03/14(火) 19:21:57.76
達人はコメントを無駄なものとは考えていないよ
彼らは単に無駄なコメントを書かないだけ
そんでコードを洗練させれば自明と無駄なコメントは減っていくだろ?
コード見ればすんなりと理解できるのにコメントにも書くのは無駄だものね
だから達人のコードはコメントが少ないんだね
過剰にコメントを書く人は残念だけど下手くそなんだな
455 :
仕様書無しさん
2017/03/14(火) 19:30:38.15
>>454
達人はコードを読まないよ
ビジュアルで認識する
そのビジュアルを特徴づける為に非常に有用なのがコメントなんだな
だから達人のコードにはコメントが不必要な程に多い

残念だけどコードを頭から読み下してるうちはまだまだ下手くそなんだよ
456 :
2017/03/14(火) 19:38:00.99
>>455
う〜ん
他業界のコメンテーターさんには難しいかもしれないけど
ビジュアル化された情報って要するにモデルなんだよね
達人はモデルとコードをほぼ1:1に結びつけてコード書くんだよ
モデルがあるのに無意味にコメント書いても仕方がないからね
もちろんコメントするのが仕事のコメンテーターさんならそれでいいのかもしれないけどここはIT業界だからそちらの常識は通じないんだゴメンね
457 :
2017/03/14(火) 19:40:25.88
みなさん正規表現にはコメントをつけますか?
458 :
仕様書無しさん
2017/03/14(火) 19:41:09.82
>>456
またモデラー君かw
最近モデリングって言葉覚えたみたいだけど
モデルってコーディングプランの事じゃないからねw
459 :
2017/03/14(火) 19:42:54.67
>>458
ははは
コメンテーターで流行りのジョークか何かですか?
460 :
仕様書無しさん
2017/03/14(火) 20:27:34.11
>>455
そんなの日本人のうち日本語の文章を読むのが速い人は、日本語を見た目で理解しているのと同じで優秀な人ならみんなそうだよ。
461 :
仕様書無しさん
2017/03/14(火) 20:28:13.22
>>456
キミっていつも設計のことをモデルと言うから分かりやすいよな。
462 :
2017/03/14(火) 20:33:12.65
>>457
つけるぞ。こんな感じで

char *p = "\\\d{1,3}(,\d{3})*\b"  // 正規表現
463 :
仕様書無しさん
2017/03/14(火) 20:34:37.04
>>462
性器表現の間違いじゃないのか?
464 :
仕様書無しさん
2017/03/14(火) 20:35:29.18
>>462
そういうのに「変数宣言」というコメントをつけるのはよくいるけどなw
465 :
仕様書無しさん
2017/03/14(火) 20:38:17.57
>>462
エスケープのやり方知らないのにどうしてその例を選んだw

こうしてまた着々と己の黒歴史を刻む>>462であった
466 :
2017/03/14(火) 20:53:50.07
>>461
モデルってこの業界では一般的な用語だぞ
コメンテーターの仕事は知らんけど
467 :
2017/03/14(火) 20:55:11.57
>>465
黙れ
コメントが正しければコードはどうでもいいんだよ
468 :
仕様書無しさん
2017/03/14(火) 21:01:13.67
>>467
言われなくても哀れすぎて二の句が継げんわw
恥ずかしいねwあぁ恥ずかしいねw
469 :
2017/03/14(火) 21:02:04.95
コメンテーターわろたw
470 :
仕様書無しさん
2017/03/14(火) 21:03:39.43
>>465が何を言いたいのかよくわからない件
471 :
2017/03/14(火) 21:08:58.54
>>467
それだけは無いわー
472 :
2017/03/14(火) 21:10:31.74
人に難癖をつけるが自分では価値のあるものを一切創造しない
コメンテーターとは言い得て妙なりw
473 :
2017/03/14(火) 21:14:18.10
>>470
マジレスすると、Cしか知らない無能なんだと思われ
474 :
2017/03/14(火) 21:16:53.55
//全部大文字にする
とかそういうやつつけて欲しい。正規表現
475 :
2017/03/14(火) 21:18:08.86
いちいち内容考えるの面倒だろ

// コメント

これで統一すればいいんじゃね?
476 :
2017/03/14(火) 21:21:49.55
ソースファイルをリソースとしてコンパイルする
実行時にコメントをパースしてインタプリタとして動作させる
ほらみろコードは不要だったろ?
477 :
2017/03/14(火) 21:58:55.62
コメンテーターw
茶噴いた
478 :
2017/03/14(火) 22:24:52.04
>>476
なにいってるのか分からん
479 :
仕様書無しさん
2017/03/14(火) 22:26:21.55
悔しいんだろ。もう少しそっとしといてやれよw
480 :
2017/03/14(火) 23:46:10.99
場合にもよるけど、関数に対しての入力と出力の意味ぐらいしか書かないんだけど関数の内部も説明いるかね
説明いるぐらい長いんだったら関数分けるべきな気もするが
481 :
仕様書無しさん
2017/03/15(水) 00:42:05.43
>>466
おまえいつもそう反論するけど、一般的にはモデルと言わない。IPAも設計をモデルと呼んでいない。設計をモデルリングと呼んでしまうと、狭い意味で使っているモデル、モデルリングと用語がかぶってしまうためにさけている。
482 :
仕様書無しさん
2017/03/15(水) 00:50:03.43
>>466 は英語風に言いたがるね。日本人ならコメンテーターなんて言わずに評論家、評論家気取りと言って馬鹿にしていることが多々ある。

帰国子女で日本語が苦手なら仕方ないが日本で仕事をしているならできるだけ日本語でまずは言った方がいいよ。

アルファベット圏の英語は、細かいニュアンスを単語ひとつで表現できないため、どうしても意味が広く曖昧になる。漢字圏の国では少ない文字数で細かく言い分けられるから日本語の方が優位。
483 :
2017/03/15(水) 01:01:32.78
>>482
は?
スレの「コメント」にかけてるって事すら判らないの?
484 :
2017/03/15(水) 02:53:40.29
またコメンテーターが無駄な長文書いてる
485 :
2017/03/15(水) 03:05:46.61
俺のクソみたいなコメントを紹介してやんよ

# 一発で全出力が貰えるわけじゃない、2回に分けて(このイベントが2周して)くることもあるぞ
channel.on_data do |channel, stdout_data|
 buffer += stdout_data
end
486 :
2017/03/15(水) 03:27:37.49
見どころは、じつはchannelが全部同一だってことには触れてないことだ……!
今のNet::SSHの実装だと全部同一のチャンネル返してきやがるんだよクソッタレ
487 :
2017/03/15(水) 06:01:26.13
>>481
設計をモデルと言っているのは今の所>>461だけだから>>461と話し合ってくれ
488 :
2017/03/15(水) 09:02:44.39
またコメントが間違ってた
やっぱりコメント不要だ
489 :
仕様書無しさん
2017/03/15(水) 12:06:27.79
>>483
コメントを書くひとを英語でコメンテーターとは言わないよ。
490 :
仕様書無しさん
2017/03/15(水) 12:08:07.65
コメンテーターを勝手にコメントを書く人なんて言うなど、英語がわからないにもほどがあるわ。
491 :
2017/03/15(水) 12:12:24.41
>>489-490
お前、阿呆だろ?
492 :
2017/03/15(水) 12:33:32.79
>>491
お前以外全員アホだよ
493 :
2017/03/15(水) 12:39:27.40
>>492がアホなのは確定
494 :
2017/03/15(水) 12:59:29.06
コメンターだな?
もしくは
コメントライター
495 :
2017/03/15(水) 13:06:34.17
>>493
いよっ、天才!
天才のど偉い一言期待したまっせ!
496 :
仕様書無しさん
2017/03/15(水) 14:15:58.65
コメント一つでこれだけ荒れる連中が
集まったら、プロジェクト以前の問題だろ。
ここの連中が日本のソフト産業を支えて
いると思うと、空恐ろしいわw
497 :
2017/03/15(水) 14:22:42.74
コメント無しでグローバル変数を使ったスパゲッティーコードを書く前任者に辟易した
どこから入って何が出ていくのか分からない

そのくせ何の参考にもならない見たまんま系コメントは沢山ある
498 :
2017/03/15(水) 14:53:03.53
説明できないんだろうな。
499 :
2017/03/15(水) 17:33:49.63
コメンテーターw
言い得て妙だな
500 :
仕様書無しさん
2017/03/15(水) 23:26:40.32
>>499
それをいうならコンメンティストだろw
501 :
仕様書無しさん
2017/03/15(水) 23:27:16.87
>>497
グローバル変数くらいでかわりにくいとか初心者だな。
502 :
2017/03/15(水) 23:29:52.82
>>501
ダメなものはダメって言えるようにならないとだめだよ
503 :
仕様書無しさん
2017/03/15(水) 23:53:12.88
>>502
ものによってはグローバル変数の方がいいものがある。ログファイル関連とか。
504 :
2017/03/15(水) 23:56:03.09
>>503
ログファイルにもいらん
505 :
仕様書無しさん
2017/03/16(木) 00:08:52.59
>>504
その機能、その処理のメインのロジックにログファイル出力のコードがごちゃごちゃ割り込むのは、よくないから普通はそうしないんだけどな。

例外処理と同じ。いちいちエラーハンドリングの処理をその場で書いていると重要な部分が目立たなくなる。だから例外はジャンプさせて別のところに処理を書く。
506 :
2017/03/16(木) 00:14:31.70
そうしないってなんだ?

メインのロジックにログファイル出力のコードがごちゃごちゃ割り込むのは、
よくないからこそ、グローバル変数を使わないんだろ
507 :
2017/03/16(木) 02:39:22.29
>>500
最上級にするな
厚かましい
508 :
2017/03/16(木) 08:24:54.95
comment
commenter
commentest
509 :
2017/03/16(木) 09:41:34.62
ログなんか、唯一出力関数だけ公開されてりゃ事足りるだろうに。
ログレベルだってそれに引数で与えりゃ済む話だ。
510 :
2017/03/16(木) 11:41:07.62
>>509
出力関数を公開して引数でログレベル与えるって、昭和プログラミング・・・
loggerオブジェクトを公開して、ログレベルに応じたメソッドが平成プログラミングだよ!
511 :
2017/03/16(木) 12:31:27.38
言ってる事は同じなのにな。
512 :
2017/03/16(木) 14:53:24.15
こりゃ世界から戦争がなくならないはずだわ
513 :
仕様書無しさん
2017/03/16(木) 14:56:51.66
もともとコメントがなくてもわかるように作りましょうと昔から言われてるのを、コメントがいらないと解釈している勢力がいるからおかしくなる。

コメントがなくてもわかる作りでも、コメントを書いてもいいのに、コメントがいらないと主張する人間は頭が固いからゆずらない。
514 :
2017/03/16(木) 14:58:25.59
>>513
コメントが要らないと主張する奴なんて居ないのに、勝手に誤解してる馬鹿が話をややこしくしてるだけ
515 :
仕様書無しさん
2017/03/16(木) 14:59:48.67
>>514
スレタイ読め
516 :
仕様書無しさん
2017/03/16(木) 15:02:39.72
>>514
ここでは知らないがアメリカ人や日本人の有名プログラマの一部はコメントに否定的なんだよ。オライリーの本で有名プログラマの考え方の本があってコメントいらない派がかなりいる。
517 :
2017/03/16(木) 15:03:18.07
>>515
うるせぇ
518 :
2017/03/16(木) 15:04:03.80
>>516
じゃあそいつと話しろよ。。。
519 :
仕様書無しさん
2017/03/16(木) 15:04:12.37
ただその本に出てくるプログラマは他人の書いたコードで苦しんだ経験がないような人ばかりだけどな。
520 :
仕様書無しさん
2017/03/16(木) 15:07:10.19
>>518
また2ch初心者か。自分に言われている、自分のスレッドと勘違いするのはなかなかなくならないのはどうしてなのかな?

SNSでもこういう現象がある。他人の投稿にコメントして、そのうち自分の投稿と勘違いするのか、執拗に投稿者の考え方を批判してくる。
521 :
2017/03/16(木) 15:10:15.17
>>520
日本語読めないの?
522 :
2017/03/16(木) 15:21:55.68
>>520
無理矢理レッテル貼って精神的優位に立ちたい年頃なんだな
523 :
2017/03/16(木) 17:00:59.18
コメンテーターうるせーよ
524 :
仕様書無しさん
2017/03/16(木) 18:54:28.55
>>516
彼らはコメントいらないなんて嘘ぶいてるけどその実態はコメント書けない勢だよ
525 :
2017/03/16(木) 19:06:57.46
>>524
阿呆だろ?
526 :
2017/03/16(木) 19:12:46.97
ソースコードに全て書いてあるだろうに。
527 :
2017/03/16(木) 19:19:46.30
ソースを読める奴が優秀なのではない。
お前らでも、分かるように書けるPGが優秀なのだ。
だからソースを読めるからと言って天狗にならない方がいい。
528 :
2017/03/16(木) 19:23:17.53
>>527
は?
529 :
2017/03/16(木) 19:32:39.17
どんなにコメントに書こうが、プログラムはコードに書かれた通りにしか動かないんだよ?
530 :
仕様書無しさん
2017/03/16(木) 19:35:16.12
>>529
お前いつも「コンパイラのバグだ!」って騒いでるじゃんかw
531 :
2017/03/16(木) 19:38:52.82
>>530
は?
532 :
仕様書無しさん
2017/03/16(木) 20:22:03.22
これは普通にショックだな。。
本当なの?
https://goo.gl/QQaXQC
533 :
2017/03/16(木) 20:24:05.91
ぐろ
534 :
2017/03/16(木) 23:34:05.88
達人のコメントスキルだと、興味を引かないプログラムからエキサイティングな物語を生み出すことができる。
おまえらコードの枝葉末節な書き方でどうでもいい宗教戦争するより
詩のような見惚れるコメントスキルを磨くほうがはるかに生産的だぞ。
535 :
2017/03/16(木) 23:41:17.18
>>534
プログラマーに求められるのは「ビジネス文書」を書く能力であり、
物語を書き上げる能力ではないよ。
簡潔に丁寧に情報を伝えるってのがソースの役目。
536 :
2017/03/17(金) 00:52:17.88
どんなに素晴らしいコメントを書いても、コードがバグだらけじゃ捨てられるだけ。
…修正するより作り直した方が早いってなw
537 :
2017/03/17(金) 01:20:16.07
しかしコメントは汚くても捨てられない。
どちらが資産になるかは言うまでもないな
538 :
2017/03/17(金) 02:25:52.73
コメントとコードのどちらかを捨てなければならないという究極の選択・・・
って、迷うやつすらいないだろw
539 :
2017/03/17(金) 02:51:40.44
>>537は迷わずコードを捨てそうだがな
540 :
2017/03/17(金) 03:57:12.13
>>453
アホか?
命名がおかしいことがあるならコメントがおかしいこともありうる。
きちんとしてたら命名がおかしいのだって有り得ない。
命名がおかしかったらその時点で邪悪なんだよ。

コメント以前に命名に気を使うべきなんだ。
その上でコメントも必要なわけだが、無駄なコメントは可読性を低下させる。

一方、必要無いと思ってたコメントが後から必要だった(そのコードの意味がわからなくなってた)ということもありうる。
その場合は己の不出来を呪うのさ。
541 :
2017/03/17(金) 13:56:06.83
>>537
これがコメンテーターの思考回路か
542 :
2017/03/17(金) 23:50:56.72
実際コメント綺麗な奴はだいたいコードも綺麗なんよね
機能的にぼやけたコードや絡み合ったコードに明確なコメントなんて付けれないからな
543 :
2017/03/18(土) 00:05:15.78
コード綺麗な奴はコメントほとんど書かないけどな
544 :
2017/03/18(土) 00:21:39.70
べたべたに書かれた詳細設計との対応とるために
いちいち処理にコメント書くことはある
545 :
2017/03/18(土) 00:23:57.93
それは不幸な職場だな
546 :
2017/03/18(土) 00:27:42.83
コード綺麗な奴はコメントほとんど書かないけどな

自分でそう言ってコメント書かない奴はたまに見かけるが、
全体的に触りたくもないコードが書かれている
547 :
仕様書無しさん
2017/03/18(土) 10:18:39.88
>>546
自分ではまともなコードだと思い込んでいるんだろうな。
548 :
2017/03/18(土) 16:52:19.15
>>547
それはコメントの有無関係ないから
549 :
仕様書無しさん
2017/03/18(土) 21:38:29.73
>>548
はあ?関係してるぞ。コメントを書けないようなコードはコードに問題がある。
550 :
2017/03/18(土) 22:14:33.96
コメントを書けないようなコードって例えば?
551 :
2017/03/18(土) 22:53:24.72
>>550
俗にいうスパゲッティコード

スパゲティーは、絡み合ったもの全部合わせてペペロンチーノだのナポリタンだの説明ができるが
部分部分はスパゲッティーの一部としか説明しようがない。
552 :
2017/03/18(土) 22:54:50.16
>>551
コメント書けるだろ
553 :
2017/03/18(土) 23:36:26.92
>>552
そりゃ意味のないコメントなら書けるわ
数行おきに自分の名前とその日の日記でも書いとけ
554 :
2017/03/18(土) 23:55:45.06
コメントを書けないようなコードって例えば?
555 :
2017/03/19(日) 00:07:32.94
2chて異様にアスペ多いよね
リアルじゃ見かけたことないけど、彼らはいったいどこに生息してるんだろ
556 :
2017/03/19(日) 00:19:10.57
>>555
鏡見れば解決するよ
557 :
2017/03/19(日) 00:41:56.87
そんな定型どおりのレスならしなくていいんじゃね?
おまえも楽しんでるとも思えないし
558 :
仕様書無しさん
2017/03/19(日) 01:01:40.42
ムキになることなくね?
559 :
2017/03/19(日) 01:04:37.46
ムキになる電波がスカイツリーから放送されてるから無理
560 :
仕様書無しさん
2017/03/19(日) 03:48:40.60
https://goo.gl/NrL6ir
これ、本当だったら相当ショックだね。。
561 :
2017/03/19(日) 05:27:26.42
ぶっちゃけ、アホが書いたコメント読んでるよりは
アホが書いたこのスレのレス読んでる方が楽しい
562 :
2017/03/19(日) 07:57:17.91
スパゲッティ食べたい
563 :
仕様書無しさん
2017/03/19(日) 10:40:09.25
>>554
日本語で説明できないようなもの
564 :
2017/03/19(日) 13:23:38.25
例えば?
565 :
2017/03/19(日) 13:40:05.46
普段コメント書かない奴の平均的コメントレベルが>>564
566 :
仕様書無しさん
2017/03/19(日) 14:11:04.15
>>564
最近見たものだとweek_checkという関数があったな。曜日の確認は前処理で実際は曜日によって他のプログラムを実行するというものであったが、この関数につけられたコメントが曜日判定。

初めは誰もが誤解する名前になっているw
567 :
2017/03/19(日) 14:43:24.67
適切な関数名はRunWeeklyJob(s)かRunWeeklyTask(s)
だろう
常識人の感覚だと

なんでもチェックとか判定ってコメントを付けるやつ
うちにも以前居たようだが何故そんなコメントを書きたくなるのか
さっぱり分からん
単なる時間の無駄だと思うが
568 :
2017/03/19(日) 15:39:38.56
おまいらんとこ、コードレビューとか無いの?
569 :
2017/03/19(日) 16:15:19.60
コードレビューっていうほど効果ないのよな。
どんぐりの背比べの奴らが集まって、
立場が上の奴が自分の趣味を押し付けるか、近い立場の奴らが宗教戦争繰り広げるだけ。
その時点で立ち戻った修正が無理なことは皆わかってるので、枝葉末節な書き方とかの指摘でお茶濁し。

レビューは書類揃えるための形式でやってるだけで、
本当にコードの質上げたかったら、レビュー以外の時間に適宜チーム内で確認し合ってないと無理。
570 :
2017/03/19(日) 16:34:23.50
いや、普通コードレビューってコーディング規約に沿ってやるから、関数や変数の命名規則とかコメントの付け方とか、会社として一様なコードかどうかを基準にするもんだろ?
宗教戦争にゃならんよな?
571 :
2017/03/19(日) 16:55:48.84
ああ、そういうコードレビューね。
あくまで社内ルールに沿ってるかどうかチェックするだけの。

いまどきはコーディング規約なんてあるにはあるが、
ごくごく基本的な取り決めしか書かないけど。
572 :
2017/03/19(日) 17:07:32.35
>>569
いくら何でもコードレビューがわかっていなさすぎだろ。
コードレビューの目的の一つで大きなものは、
 参加者の誰もがそのコードを引き継げる状態にすること。
だよ。
チーム開発なんだから、そのくらいは当たり前のこと。
レビューが終わったソースは個人のものではなく、
チームが責任者となってメンテナンスするもんだ。

なので、レビューの最中には
疑問点があれば質問するし、おかしな点があれば指摘する。

宗教論争なんてしてるやつはなんのためにレビューするのか考え直すべき。
コーディング規約に不備があるのなら別途改定すればいい。

意図が読みづらいコードがあれば、コメント付けるなどの対応すればいい。
573 :
2017/03/19(日) 17:20:58.02
>>572
だれもしたいと思って宗教戦争してるわけじゃない。
「疑問点」「おかしな点」の感じ方が人それぞれ異なる。

技術者同士じっくり時間をかければお互いなるほどと思うことが多いのだが、
レビューの場だけでは無理がある。
574 :
2017/03/19(日) 18:52:57.54
>>569
なんだこれ
レビューの悪い例の見本みたいな感じ
575 :
2017/03/19(日) 18:59:31.19
>>566に似てるけど
「target」ってのも悪のキーワード
引数になんでもtargetって付ける馬鹿
いったい何が由来なんだろね
perl?cobol?C?
576 :
2017/03/19(日) 19:00:35.42
スレチスマソ
ここ変数名じゃなくてコメントのスレだったな・・・
577 :
2017/03/19(日) 19:23:51.35
>>572
いや、レビューでコメントをどうするとか無駄な相談するくらいなら最初からコメント削っとくべきだろう。
この場合は。

俺はコメントは必要と思ってるけど、この場合は不必要どころか害悪になってる。
578 :
2017/03/19(日) 20:54:03.72
>>569
こんなことするチームから出てきたソースは
品質や保守性の低いゴミなんだよな
後でそのツケが回ってきて炎上する
579 :
仕様書無しさん
2017/03/19(日) 21:09:31.98
詳細設計とコーディングが同じ人間なら、コードのコメントに詳細設計の言葉書かれる。
580 :
2017/03/19(日) 21:40:58.51
>>574>>578
もちろんそうだ。悪い見本として書いてるのがわからんか?
ただ彼らも悪いレビューをわざとしてやろうと思ってしてるわけじゃない。
581 :
2017/03/19(日) 21:47:11.54
まあ、おまいが嫌いなだけだしな。
582 :
2017/03/19(日) 22:06:14.61
仲間はずれ…会社や職場のコードレビューで自分だけ誘われない時の対処法5選
1.思い当たる理由を探ってみる
2.誘ってくれない理由を尋ねる
3.自分も誘ってほしいと意思表示する
4.仲間はずれにされているならば気にしないように!
5.自分でコードレビューを主催してみる
583 :
2017/03/19(日) 22:24:50.77
飲み会とかならわかるが
コードレビューに誘われたい奴とかいるの?
584 :
仕様書無しさん
2017/03/19(日) 23:26:38.02
そもそも、ここにいる連中で何人かは、ANSI Cすらきちんと理解していないのでは...
と思えるほどの書き込みも見受けられるのだが。C++以前の問題で、Cも理解していない感じ。
マジでヤバい奴とかいなくね?
585 :
2017/03/19(日) 23:42:44.55
Cを理解していなくても別にヤバくはないが、
それ以前に人としてヤバい率が異常。
586 :
2017/03/19(日) 23:54:37.66
宗教戦争が嫌ならレビューのやり取りはメールとか文書ですればいい
修正させるにはいちいち根拠になる仕様や規約が必要だし、書くのめんどいから
ふつうはみんな最低限の作業で済まそうとする

顔つき合わせて漠然とした議論するのはほんとに飲み会のノリぐらいじゃないと
587 :
2017/03/20(月) 00:15:28.56
コードレビューとかみんな真面目にやってんの?
588 :
2017/03/20(月) 00:55:27.16
やらないの?
589 :
仕様書無しさん
2017/03/20(月) 01:16:26.47
>>584「Cを理解していると兎に角凄いのだ!最高峰の言語なのだ!」
590 :
仕様書無しさん
2017/03/20(月) 05:18:49.04
>>589
そういう意味ではないとわからないのか?
591 :
仕様書無しさん
2017/03/20(月) 05:22:48.97
そういう意味だろ
592 :
仕様書無しさん
2017/03/20(月) 05:36:46.80
>>591
意味がわかってないな
593 :
仕様書無しさん
2017/03/20(月) 05:38:14.42
>>591
C言語がすごいと言ってるのではなく、構造化プログラミングを知っているのかという意味だよ、たぶん。
594 :
2017/03/20(月) 07:07:08.16
コメントなんか普段気にしないのに
大嘘書いてたのには苦しめられたな
595 :
2017/03/20(月) 09:04:22.03
>>584
コメントを議論するスレで、なんで言語の規格が出てくるのかわからないし、
最後の一文も意味不明。
自分が発達なのを自覚できてないとしか。
596 :
仕様書無しさん
2017/03/20(月) 09:58:49.40
コメントを議論するはずのスレなのに、出てくる話はC系統の話ばかりだろ。
597 :
仕様書無しさん
2017/03/20(月) 11:24:59.57
偽装請負多重派遣業界SE結婚相手の犠牲対策

巨額搾取させて結婚妨害するな!
無能残業して共働き妨害するな!

・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時以下の契約は辞めろ
・100万円/月以下のプログラム作成は止めろ
・プログラムの料金以上に製作するな
・プログラムの利益を搾取させるな
・プログラムの報酬を搾取させるな
・多重契約は止めろ
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・客先指示に従うな
・契約外作業期日に従うな
・時間外労働違反は止めろ
・残業見積りは止めろ
・残業しないで学習しろ
・残業しないで副業しろ
・残業しないで家事やれ
・偽装請負多重派遣は通報しろ
・損害賠償訴訟を怠るな

【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf
598 :
仕様書無しさん
2017/03/20(月) 13:16:15.17
>>596
CじゃなくてJava系だろうが。
599 :
2017/03/20(月) 15:08:59.74
Javaの文法はC系統でしょうな
600 :
仕様書無しさん
2017/03/20(月) 15:24:46.00
>>599
駄目こりゃ。オブジェクト指向言語とそうでないものではコメントの書き方がまったく異なる
601 :
仕様書無しさん
2017/03/20(月) 15:45:33.74
はいうそ
602 :
2017/03/20(月) 17:32:51.24
>>600
603 :
仕様書無しさん
2017/03/20(月) 17:40:09.07
関数とメソッドの違いもわからないのか
604 :
仕様書無しさん
2017/03/20(月) 17:48:20.28
コメントは変わらない
605 :
仕様書無しさん
2017/03/20(月) 18:28:47.56
>>604
同じになる場合もあるが、あなたのコードがオブジェクト指向でない可能性がある。
606 :
2017/03/20(月) 18:30:24.94
>>600
え?
コメント形式同じですけど
607 :
仕様書無しさん
2017/03/20(月) 20:00:11.08
>>606
コメントの内容のスレだろw
608 :
仕様書無しさん
2017/03/20(月) 20:04:12.51
>>606
ちなみにかなりあとになって言語仕様に追加されたけど、C言語に行コメントはなかったからな。

CとC++はコンパイラが一緒なのが普通だから、CとC++を混ぜて書くプログラマはいまでもそれなりにいるとは思う。
609 :
2017/03/20(月) 20:58:29.95
今時、関数とか言ってる珍獣は死ねよ
いつの時代だよw
610 :
2017/03/20(月) 21:05:14.81
>>609
は?
なんでも横文字にすればいいってんもんじゃないんだよ
611 :
2017/03/20(月) 21:14:01.92
getUserId() toYearOfDate() とか他に何をコメントせいって言うんだろうな。
612 :
2017/03/20(月) 21:14:19.18
関数すら理解できないバカが沸き始めたな
613 :
2017/03/20(月) 21:15:59.45
toYearOfDate() // といやあおぶだて
getUserId()  // げつざぁいど
614 :
2017/03/20(月) 21:19:30.04
>>607
内容も同じでしょ
615 :
2017/03/20(月) 21:24:11.46
>>611
getUserId() /* この処理は、ユーザーごとに割り振られた識別子、
いわゆるユーザーIDと呼ばれるものを取得するための関数であり、
引数は無く、返値にそのユーザーIDが格納されてきます。
ユーザーIDの範囲は unsigned int(符号なし整数)で表せる範囲であり、
16bitコンパイラの場合であれば 0〜65535、
32bitコンパイラの場合であれば 0〜4294967295、
64bitコンパイラの場合であれば、実装依存の値となりますが
もし64bitのint値とするコンパイラであれば (以下略)

こんな感じの丁寧なコメントがつくんじゃね?
616 :
2017/03/20(月) 21:58:33.90
文章が下手なやつって、箇条書きが出来ないんだよなw
そして文章を長ったらしく書くのが丁寧だと勘違いしているふしがあるね
617 :
2017/03/20(月) 22:09:44.85
長文かけないやつは根本的に想像力が足りてなくて、どうしょうもないことがおおい

必要なポイントをまとめて箇条書きにする技術は教えりゃ身につくが
想像力を働かせて必要な情報を盛り込む技術はなかなか教えられん
618 :
2017/03/20(月) 22:33:21.84
>>616
え?
619 :
2017/03/20(月) 23:44:28.64
>>617
長文ウゼー
620 :
2017/03/21(火) 00:00:10.82
>>619
長くないよ!お前が短すぎるんだ!
621 :
仕様書無しさん
2017/03/21(火) 00:11:33.78
>>616
ここはドキュメントを書くところではありません。
622 :
仕様書無しさん
2017/03/21(火) 00:14:07.30
>>619
頭の悪い人間の会話を聞いていればわかるが、単語のぶつけ合いしかしてない。
623 :
2017/03/21(火) 07:25:03.32
直接反論するのも別の見解を持ち出すのも議論のうちだ
624 :
2017/03/21(火) 14:22:41.97
コメントやドキュメントはオープンソースのライブラリに書かれている物を参考にすれば良いんじゃない?

人気のライブラリのは
シンプルながらも要点をおさえたコメントになっているぞ
625 :
2017/03/21(火) 18:24:14.25
>>624
ひとくちにオープンソースといってもなあ…具体的に
626 :
仕様書無しさん
2017/03/21(火) 19:21:10.00
chromium
627 :
2017/03/21(火) 20:25:43.06
オープンソースという表現はすでに陳腐化してます
これからはバックリソースと表現するようにビルゲイツを脅迫してきます

(´・ω・`)b
628 :
2017/03/21(火) 20:47:19.16
朴りソース?
629 :
仕様書無しさん
2017/03/21(火) 23:43:06.50
>>624
オープンソースはコメントが少ないのが多いよ。
630 :
仕様書無しさん
2017/03/21(火) 23:44:10.34
>>627
バックレソースなら昔よくあったな。
ひどいものを作って逃げるやつ。
631 :
2017/03/22(水) 01:20:10.07
>>630
今でもよくあるのよ、モルダー
632 :
仕様書無しさん
2017/03/22(水) 08:04:29.91
OSSに無いのは必要のないコメントで
ライブラリのドキュメントとかFIXMEみたいなのはOSSにも良くあるじゃん?
633 :
2017/03/22(水) 08:21:08.77
>>632
そんなもんプロジェクトによるわな
634 :
仕様書無しさん
2017/03/23(木) 21:49:06.15
オープンソースは英語のコメントのせいでコメントそのものが曖昧に書いてあることが多い。世界の標準言語を表現力のとぼしい英語にするから意志疎通がうまくいかない。
635 :
2017/03/23(木) 21:57:01.60
>>634
は?
636 :
仕様書無しさん
2017/03/23(木) 22:03:41.80
>>635
日本人だって漢語だけの組み合わせで説明するやつだっているだろ。

あんな何通りか解釈できる言葉を日本語ネイティブでも書くのに、英語ネイティブでもない世界中の人間が書いていたら、コメントそのものも解釈が別れる。

そもそも英語圏ですら方言も強くて意志の疎通がうまく取れていない。
637 :
2017/03/23(木) 22:09:16.86
>>636
は?
638 :
仕様書無しさん
2017/03/23(木) 22:22:10.36
What the hell are you talking about!?
639 :
仕様書無しさん
2017/03/23(木) 22:26:46.77
Oh, shit... I like the Unko.
640 :
2017/03/23(木) 23:31:21.45
漢字だとダメな例
NG: 押下
OK: Click (Tap)
641 :
2017/03/23(木) 23:38:48.72
OK: おす
642 :
仕様書無しさん
2017/03/23(木) 23:49:06.06
>>640
ボタンを押すことを押下と言い出した昔の日本人が悪い。

たぶんキーボードを押すから来ている言葉だな。

初期のGUIはマウス操作を想定していてもマウスがなく、キーボード選択してボタンを押したり、マウスカーソルをキーボードで移動させてボタンの上でキーを押していた。
643 :
2017/03/23(木) 23:56:24.33
日本語がなかなか思い浮かばない例
insert : 挿入
eject : ?
644 :
仕様書無しさん
2017/03/23(木) 23:57:13.79
>>643
あんた外国人?
645 :
仕様書無しさん
2017/03/24(金) 00:00:26.85
>>643
ejectは意味が広い典型的な英語の動詞。

日本語に翻訳する場合は文脈で判断してかなり別の言葉をあてる。
646 :
2017/03/24(金) 08:44:08.72
なんで?
「取り出し」じゃないの?
647 :
2017/03/24(金) 08:59:17.16
>>646
ダサいから
648 :
2017/03/24(金) 11:57:46.95
「射出」の方がかっこいいよな
649 :
2017/03/24(金) 12:14:11.39
message -> 電文
はなんかかっこいいな
650 :
仕様書無しさん
2017/03/24(金) 13:06:39.90
>>646
漢語に統一したいんじゃないの?
651 :
2017/03/24(金) 13:15:24.74
挿入と来れば次は射精だろjk
652 :
2017/03/24(金) 13:32:40.18
まぁ挿入の対義語は抜去みたいだしな
音読みの反対が訓読みとかはちょっとな
653 :
2017/03/24(金) 16:16:50.88
insert <-> delete
add <-> remove

ejectなんて使わない
654 :
2017/03/24(金) 16:18:27.76
>>653
は・・・?
655 :
2017/03/24(金) 17:12:05.59
英語の対義語じゃなくて、日本語の対義語だとそうなるって話
英語の対義語での訳なら、除去か削除だな
めんどくせ
656 :
仕様書無しさん
2017/03/24(金) 17:18:01.72
ejectは英語のなかではダメ単語で文脈からしか意味がわからない単語。
657 :
仕様書無しさん
2017/03/24(金) 18:32:40.61
摂る取る撮る摂る捕る執る盗る獲る穫る
みたいな?
658 :
仕様書無しさん
2017/03/24(金) 19:58:26.69
ダブルスラッシュを考えた奴は、マジで頭良いと思う。
/*   */
よりも見やすいからな。
659 :
仕様書無しさん
2017/03/24(金) 20:09:34.48
>>658
//はかなり古い言語のパクりなんだが。
660 :
2017/03/24(金) 20:54:38.80
日本語の特定漢字が末尾だとコンパイルエラーが出るコメント式なんてクソだろ。
661 :
仕様書無しさん
2017/03/24(金) 21:18:50.49
>>660
日本語が入ってるとおかしくなるのはコメントに限ったことではない。シングルバイト圏のやつらが悪い。
662 :
仕様書無しさん
2017/03/24(金) 21:35:24.13
最近はみんなUTF-8だから問題ない
663 :
2017/03/24(金) 21:36:21.98
645 : 仕様書無しさん2017/03/24(金) 00:00:26.85
>>643
ejectは意味が広い典型的な英語の動詞。

日本語に翻訳する場合は文脈で判断してかなり別の言葉をあてる。
646 : 仕様書無しさん2017/03/24(金) 08:44:08.72
なんで?
「取り出し」じゃないの?
647 : 仕様書無しさん2017/03/24(金) 08:59:17.16
>>646
ダサいから
648 : 仕様書無しさん2017/03/24(金) 11:57:46.95
「射出」の方がかっこいいよな


            ∩_ 
           〈〈〈 ヽ
          〈⊃  }
   ∩___∩  |   |
   | ノ      ヽ !   !
  /  ●   ● |  /
  |    ( _●_)  ミ/ 「排出!」
 彡、   |∪|  /
/ __  ヽノ /
(___)   /
664 :
2017/03/24(金) 21:41:47.40
658 : 仕様書無しさん2017/03/24(金) 19:58:26.69
ダブルスラッシュを考えた奴は、マジで頭良いと思う。
/*   */
よりも見やすいからな。


            ∩_ 
           〈〈〈 ヽ
          〈⊃  }
   ∩___∩  |   |
   | ノ      ヽ !   !
  /  ●   ● |  /
  |    ( _●_)  ミ/ アホ!
 彡、   |∪|  /
/ __  ヽノ /
(___)   /


便利だと思うポイントがずれてる

/* */ を含むコードを/* */でラップすることは出来ない
// を含むコードは/* */でラップできる
665 :
仕様書無しさん
2017/03/24(金) 21:52:43.09
ラップってなんだよ
ネストか
666 :
2017/03/24(金) 21:57:00.70
>>665
なんだよってなんだよ、おまえ、英語しらねーのか?
667 :
2017/03/24(金) 21:57:50.40
てか、コメントするのをnest(入れ子構造)だと思ってるのか? クソボケだな
668 :
2017/03/24(金) 21:58:43.98
2ちゃんって、自分から殴られに来る馬鹿いてたのしーな
669 :
2017/03/24(金) 22:00:48.05
ネストされたコメント、たのしーなー

commentA.commentB.commentC とかでアクセスできんのかなー

たのしーなー
670 :
2017/03/24(金) 22:02:31.10
> ネストされたコメント、たのしーなー
何が楽しいのかわからない。

言語によっては普通に対応してある
671 :
2017/03/24(金) 22:02:58.27
どの言語よ?
672 :
2017/03/24(金) 22:06:46.12
どの言語よ?

言語レベルでネストされたコメントに対してのアクセスをサポートしてる言語って、どの言語よ?
673 :
2017/03/24(金) 22:08:07.64
Cでも対応してるコンパイラもあるぞ?
674 :
2017/03/24(金) 22:11:26.76
プログラマならもっと具体的に言え
つまりコンパイラ名(製品名)とコードを書け
675 :
2017/03/24(金) 22:12:02.27
> “言語レベル”でネストされたコメントに対してのアクセスをサポートしてる言語って、“どの言語よ”?

> Cでも対応してる“コンパイラ”もあるぞ?

日本語できねーなら喋るな、ゴミカス
676 :
2017/03/24(金) 22:12:52.86
んで、よくわかんねーんだけど、コンパイラがコメント解釈してなんか良いのか?
わけわかんねーな、Cは
677 :
2017/03/24(金) 22:17:00.03
もし、コンパイラが解釈する必要があるなら、それはコメントじゃなくてアノテーションだろ
それをコメント形式でしか書けない言語がクソなだけじゃねーか

>言語によっては“普通”に対応してある

どこが普通なんだよ、マヌケども
678 :
2017/03/24(金) 22:20:22.84
んで、もう一回だけ聞いておくけど

>>664

これは Wrap だったのか? Nest だったのか? 答えろよ、マヌケども
679 :
2017/03/24(金) 22:21:49.65
>>675
つ 鏡
680 :
2017/03/24(金) 22:22:28.55
>>678
馬鹿としか。。。
681 :
2017/03/24(金) 22:22:40.73
>>676
阿呆だろ?
682 :
2017/03/24(金) 22:25:41.95
679 名前:仕様書無しさん 2017/03/24(金) 22:21:49.65
>>675
つ 鏡


680 名前:仕様書無しさん 2017/03/24(金) 22:22:28.55
>>678
馬鹿としか。。。


681 名前:仕様書無しさん 2017/03/24(金) 22:22:40.73
>>676
阿呆だろ?


            ∩_ 
           〈〈〈 ヽ
          〈⊃  }
   ∩___∩  |   |
   | ノ      ヽ !   !
  /  ●   ● |  /
  |    ( _●_)  ミ/ アホ三連星 降臨!
 彡、   |∪|  /
/ __  ヽノ /
(___)   /
683 :
2017/03/24(金) 22:26:39.52
ゴミカスって、本当に論拠を示さねーで一行レスばっかだよなw
684 :
2017/03/24(金) 22:27:19.95
ゴミカス三連星は、実は一人なのです!
685 :
仕様書無しさん
2017/03/24(金) 22:27:29.15
>>683
論拠を示せよゴミカスwww
686 :
2017/03/24(金) 22:28:10.94
679 名前:仕様書無しさん 2017/03/24(金) 22:21:49.65
>>675
つ 鏡


680 名前:仕様書無しさん 2017/03/24(金) 22:22:28.55
>>678
馬鹿としか。。。


681 名前:仕様書無しさん 2017/03/24(金) 22:22:40.73
>>676
阿呆だろ?


            ∩_ 
           〈〈〈 ヽ
          〈⊃  }
   ∩___∩  |   |
   | ノ      ヽ !   !
  /  ●   ● |  /
  |    ( _●_)  ミ/ 死ねばいいのに!
 彡、   |∪|  /
/ __  ヽノ /
(___)   /
687 :
2017/03/24(金) 22:29:49.52
>>685
>論拠を示せよゴミカスwww


「ゴミカスって、本当に“論拠を示さねーで一行レス”ばっかだよなw」

論拠を示してね―ことがゴミカスだと判断する理由だって書いてあんじゃん

にほんごりかいできないのかなー???wwwwwwwwwwwww
688 :
2017/03/24(金) 22:30:29.93
685 : 仕様書無しさん2017/03/24(金) 22:27:29.15
>>683
論拠を示せよゴミカスwww


            ∩_ 
           〈〈〈 ヽ
          〈⊃  }
   ∩___∩  |   |
   | ノ      ヽ !   !
  /  ●   ● |  /
  |    ( _●_)  ミ/ 死ねばいいのに!
 彡、   |∪|  /
/ __  ヽノ /
(___)   /
689 :
2017/03/24(金) 22:33:17.19
>>685 みたいな糞マヌケが母親の子宮頸を通ってこの世に出てきてしまったことこそがこの世の害悪の全ての根源なのです。
690 :
2017/03/24(金) 22:34:47.59
679 名前:仕様書無しさん 2017/03/24(金) 22:21:49.65
680 名前:仕様書無しさん 2017/03/24(金) 22:22:28.55
681 名前:仕様書無しさん 2017/03/24(金) 22:22:40.73

顔真っ赤にしてクソ一行レス三連投!
691 :
仕様書無しさん
2017/03/24(金) 22:36:20.57
>>687
A⇒B と B⇒A は違うのだよぉw
知らなかったでしょwおバカさんwww
692 :
2017/03/24(金) 22:38:01.00
>>691
コレだけ時間かけてその答えなの? くっそ遅w
それがメインディッシュだと思っちゃったの??????wwwww

そんな御託はどうでもいいから

> んで、もう一回だけ聞いておくけど
> >>664
> これは Wrap だったのか? Nest だったのか? 答えろよ、マヌケども

これ、答えろよwwwwwww
693 :
2017/03/24(金) 22:38:48.99
なんだ?まだコメントがネストできる
言語わからないのか?w
694 :
2017/03/24(金) 22:39:00.81
やっべ、まじこいつ、頭やっべwww

>>691 : 仕様書無しさん2017/03/24(金) 22:36:20.57

なんでこんな馬鹿が生まれてきちゃったんだよ…
695 :
仕様書無しさん
2017/03/24(金) 22:39:31.43
>>692
Neetが何質問なんかしちゃってんのぉwww
ねぇ?「権利」って知ってるぅ〜〜wwww
696 :
2017/03/24(金) 22:40:15.40
>>693

でました、「まだわからないのか?」

んな出し惜しみしてね〜でとっとと言えばいいのに
それでそれが

>言語によっては“普通”に対応してある

普通なのか考えてみればいいのに

ノータリンって本当におもろいな
697 :
仕様書無しさん
2017/03/24(金) 22:41:15.67
発狂しとるw簡単やなコイツw
698 :
2017/03/24(金) 22:41:33.82
>>695

>Neetが何質問なんかしちゃってんのぉwww

ごめんなさい、日本語話してくださいw

>ねぇ?「権利」って知ってるぅ〜〜wwww

話がどう繋がってるのかわかりません、なにじんですかw
699 :
2017/03/24(金) 22:41:53.68
>>697
おまえだよw
700 :
仕様書無しさん
2017/03/24(金) 22:42:54.38
>>698
つまり「ゴメンナサイ」なのだな理解してあげる(ハ〜ト
701 :
2017/03/24(金) 22:43:01.99
>>693
>>695
>>697

こいつ、マジ最強だなw
本当にてめーの論理が破綻してること、全く分かってないで「発狂しとるw簡単やなコイツw」だもんな
702 :
2017/03/24(金) 22:45:01.93
       / \  /\ キリッ
.     / (ー)  (ー)\    <「(ハ〜ト」
    /   ⌒(__人__)⌒ \
    |      |r┬-|    |
     \     `ー’´   /
    ノ            \
  /´               ヽ
 |    l              \
 ヽ    -一””””~~``’ー&#8211;、   -一”””’ー-、.
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

          ____
        /_ノ  ヽ、_\
 ミ ミ ミ  o゚((●)) ((●))゚o      ミ ミ ミ   <だっておwww
/⌒)⌒)⌒. ::::::⌒(__人__)⌒:::\   /⌒)⌒)⌒)   
| / / /     |r┬-|    | (⌒)/ / / //       
| :::::::::::(⌒)    | |  |   /  ゝ  :::::::::::/      
|     ノ     | |  |   \  /  )  /
ヽ    /     `ー’´      ヽ /    /
 |    |   l||l 从人 l||l      l||l 从人 l||l  バンバン
 ヽ    -一””””~~``’ー&#8211;、   -一”””’ー-、
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))
703 :
仕様書無しさん
2017/03/24(金) 22:45:15.70
以上、墓穴を掘って発狂しちゃうバカをお送りしました
704 :
仕様書無しさん
2017/03/24(金) 22:45:29.85
何重にも入れ子にする時は普通ネストって言う
705 :
2017/03/24(金) 22:45:59.09
       / \  /\ キリッ
.     / (ー)  (ー)\    <「NestをNeetでかけてやった、オレ、天才」
    /   ⌒(__人__)⌒ \
    |      |r┬-|    |
     \     `ー’´   /
    ノ            \
  /´               ヽ
 |    l              \
 ヽ    -一””””~~``’ー&#8211;、   -一”””’ー-、.
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))
706 :
2017/03/24(金) 22:46:51.65
>>704 : 仕様書無しさん2017/03/24(金) 22:45:29.85
>何重にも入れ子にする時は普通ネストって言う

そうだよ? そんなことはお前以外全員わかってるよ?

論点、そこだと思ってたの? 脳みそあるの?
707 :
2017/03/24(金) 22:47:40.35
やべぇ、マジやべぇ >>704wwww
まだ論点わかってねぇwwwww
708 :
2017/03/24(金) 22:48:50.88
神よ、何故>>704のような白痴をこの世に送りたもうた?
709 :
2017/03/24(金) 22:50:11.35
>>703

んで、誰の墓穴だったっけ?wwwwww
710 :
2017/03/24(金) 22:51:17.12
馬鹿がわいてるな
711 :
2017/03/24(金) 22:51:36.90
あー、もしかして>>704って

> >>658 : 仕様書無しさん2017/03/24(金) 19:58:26.69
> ダブルスラッシュを考えた奴は、マジで頭良いと思う。
> /*   */
> よりも見やすいからな。

このクソ馬鹿本人なのか?
712 :
2017/03/24(金) 22:51:53.93
>>710
おまえのことなw
713 :
2017/03/24(金) 22:52:39.09
やっべ、

>ダブルスラッシュを考えた奴は、マジで頭良いと思う。 /*   */ よりも見やすいからな。

君が自己紹介し始めたwwwww >>710
714 :
2017/03/24(金) 22:55:06.59
>>704
あのな、お前が「権利」とか持ち出したから言うけどな、
マトモな議論できね―バカに発言権なんか、ねーよ

死ね、ゴミカス
715 :
2017/03/24(金) 22:55:12.78
馬鹿がわいてるな
716 :
2017/03/24(金) 22:58:20.48
>>715

>>712

おまえ、本当にダメだな。一生ゴミクズのまま終わるだろう。
一生底辺でやってなよ。オレには知ったこっちゃないけどな。
717 :
仕様書無しさん
2017/03/24(金) 22:59:14.13
>>662
そうでもない。英語だとUTF-8でも1文字が1バイトだから、英語圏の人間は1文字が1バイトとして実装していたりする。
718 :
仕様書無しさん
2017/03/24(金) 22:59:17.63
自覚を持ったバカwwww
719 :
2017/03/24(金) 23:01:36.56
>>718

       ____
     /_ノ  ヽ、_\
   o゚((●)) ((●))゚o   ,. -- 、
  /::::::⌒(__人__)⌒:::::: /    __,>─ 、
  |     |r┬-|    /          ヽ
  |     | |  |   {            |__
  |     | |  |    }  \       ,丿 ヽ
  |     | |  |   /   、 `┬----‐1    }
  |     | |  |  /   `¬|      l   ノヽ    >>717に阻止されてやがるwwwwwwwwwwwww
  \      `ー'ォ /    、 !_/l    l    /  }
           {       \     l   /  ,'
           \      ´`ヽ.__,ノ  /   ノ
             \     ヽ、\ __,ノ /
               ̄ ヽ、_  〉 ,!、__/
                    ̄
720 :
2017/03/24(金) 23:02:19.02
やっべ、マジ>>704、おもしれーwwwww
721 :
2017/03/24(金) 23:06:37.19
コメントがネストできる言語あった
722 :
2017/03/24(金) 23:09:28.85
結局

> んで、もう一回だけ聞いておくけど
> >>664
> これは Wrap だったのか? Nest だったのか? 答えろよ、マヌケども

これには答えねーしな

バカはさ、テメーのくだらねープライドとかどうでもいいから質問にだけ答えろよ、ホント

それが一番てめーのためになるのに、それをしねーからいつまでたってもマヌケなんだよ
723 :
2017/03/24(金) 23:09:53.41
>>721

なんで過去形になってんだよwwwww
724 :
2017/03/24(金) 23:11:10.36
やべぇ、まじ、腹筋やべぇwwww
725 :
仕様書無しさん
2017/03/24(金) 23:11:51.29
>>721
コメントがネストできるのではなく、コメント構文がネストできるの間違いでは?
726 :
2017/03/24(金) 23:12:38.02
>>725
なんだかよくわからんけど、それ本当にネストなの?
727 :
2017/03/24(金) 23:13:12.12
コメントをネストする意義って、何よ?
728 :
2017/03/24(金) 23:14:59.14
> んで、もう一回だけ聞いておくけど
> >>664
> これは Wrap だったのか? Nest だったのか? 答えろよ、マヌケども
729 :
仕様書無しさん
2017/03/24(金) 23:16:33.25
バカ、どうしても質問に答えて欲しいの巻wwww
730 :
2017/03/24(金) 23:19:47.57
>>729
>バカ、どうしても質問には答えられないの巻wwww
731 :
仕様書無しさん
2017/03/24(金) 23:21:07.06
>>727
コメントアウトした部分を含めてコメントアウトできる。
732 :
2017/03/24(金) 23:21:09.47
658 : 仕様書無しさん2017/03/24(金) 19:58:26.69
ダブルスラッシュを考えた奴は、マジで頭良いと思う。
/*   */
よりも見やすいからな。


   ∩___∩
   | ノ      ヽ/⌒) あばばばばばば
  /⌒) (゚)   (゚) | .|
 / /   ( _●_)  ミ/    ∩―−、
.(  ヽ  |∪|  /    / (゚) 、_ `ヽ
 \    ヽノ /      /  ( ●  (゚) |つ
  /      /      | /(入__ノ   ミ   あばばっあびゃばびゃばば
 |       /       、 (_/    ノ
 |  /\ \       \___ ノ゙ ─ー
 | /    )  )       \       _
 ∪    (  \        \     \
733 :
2017/03/24(金) 23:21:55.77
>>731

おまえ、アホ君だろ?

コメントアウトした中のコメントアウトになんの意味があんの?
アクセスしたいの?
734 :
2017/03/24(金) 23:22:21.97
進撃のアホ君
735 :
2017/03/24(金) 23:23:35.22
まだ論点がわかってない進撃のアホ君

> んで、もう一回だけ聞いておくけど
> >>664
> これは Wrap だったのか? Nest だったのか? 答えろよ、マヌケども

これに答えろって言ってるのに全く答えず、頓珍漢なレスをし続けるアホ君
736 :
2017/03/24(金) 23:25:02.03
やべぇよ、>>704って知能指数測ったらマイナス行くんじゃね?
737 :
仕様書無しさん
2017/03/24(金) 23:33:35.94
ラップ()
738 :
2017/03/24(金) 23:35:45.01
>>731

こいつ、マジ発達障害かなんかだろ

マトモな会話ができん
739 :
2017/03/24(金) 23:36:18.97
>>737

うん、おまえは黙ってていいよ、日本語読めないみたいだから
740 :
仕様書無しさん
2017/03/24(金) 23:40:54.64
/**/の中に/**/のコメントを含むコード片を入れる事だってできる
741 :
仕様書無しさん
2017/03/24(金) 23:43:14.29
バカ、次第に飽きられる…
742 :
2017/03/25(土) 02:13:27.30
>>740
どの言語でも?
743 :
2017/03/25(土) 02:16:28.47
しっかし、

> んで、もう一回だけ聞いておくけど
> >>664
> これは Wrap だったのか? Nest だったのか? 答えろよ、マヌケども

コレに答えろっつってんのに、なんで誰も答えね―んだろうな?

本当にゴミクズしかいねーのかな?
744 :
2017/03/25(土) 05:57:00.13
WrapとNestの違いで揉める低能御用達スレw
745 :
2017/03/25(土) 07:51:14.30
ワラップとネストって何
746 :
2017/03/25(土) 19:08:59.73
ワラップ・・・・?
747 :
2017/03/25(土) 19:52:56.13
やっと突っ込んでくれたか!
748 :
2017/03/25(土) 20:07:14.34
>>744
の、主が、お ま え ♪
749 :
2017/03/25(土) 20:09:39.53
658 : 仕様書無しさん2017/03/24(金) 19:58:26.69
ダブルスラッシュを考えた奴は、マジで頭良いと思う。
/*   */
よりも見やすいからな。


   ∩___∩
   | ノ      ヽ/⌒) あばばばばばば
  /⌒) (゚)   (゚) | .|
 / /   ( _●_)  ミ/    ∩―−、
.(  ヽ  |∪|  /    / (゚) 、_ `ヽ
 \    ヽノ /      /  ( ●  (゚) |つ
  /      /      | /(入__ノ   ミ   あばばっあびゃばびゃばば
 |       /       、 (_/    ノ
 |  /\ \       \___ ノ゙ ─ー
 | /    )  )       \       _
 ∪    (  \        \     \
750 :
2017/03/25(土) 20:17:39.75
さて俺の出題した問題の答はわかったかな?
コメントをネストできる言語がなにかわかったか?
751 :
仕様書無しさん
2017/03/25(土) 20:26:02.64
>>750
わかりません
教えてください
この通りです
752 :
2017/03/25(土) 21:45:07.45
Swift
753 :
2017/03/25(土) 21:54:09.59
で? それがどうかしたの?
754 :
2017/03/25(土) 21:55:29.69
これのこと?

http://blog.morizotter.com/2014/06/17/swift-comment-nest/

これ、ただのwrapじゃん。
755 :
2017/03/25(土) 21:56:23.94
>>750 : 仕様書無しさん2017/03/25(土) 20:17:39.75
> さて俺の出題した問題の答はわかったかな?
> コメントをネストできる言語がなにかわかったか?

た だ の ら っ ぷ じ ゃ ん wwwww
756 :
2017/03/25(土) 21:57:42.67
Nest(ネスト)って、入れ子構造のことなよの? モルダー
757 :
2017/03/25(土) 21:58:18.70
Nest(ネスト)って、入れ子構造のことなのよ? モルダー
あなた、疲れてるわ >>750
758 :
2017/03/25(土) 21:59:17.25
>>750
そのSwiftの“ネストされた”コメント、
中間の構造を破綻させたらコンパイルエラーでも起きるのかしら? モルダーwwww
759 :
2017/03/25(土) 21:59:52.96
モルダー、あなた、憑かれてるわwwwwwww >>750
760 :
2017/03/25(土) 22:02:10.80
コメンテーターはどうでもいいことに拘るよな
761 :
2017/03/25(土) 22:39:53.93
>>754
> これ、ただのwrapじゃん。
それをwrapだというのなら、
お前が言うnestとはなんだ?
言ってみろ
762 :
2017/03/25(土) 22:42:18.23
>>760
> 中間の構造を破綻させたらコンパイルエラーでも起きるのかしら? モルダーwwww

起きるだろうな。

ネストできない言語であればコメントの開始と終わりの対応が取れていなくてもエラーにならないが
コメントのネストができる言語では、ネストの対応を壊せば当然コンパイルエラーになる。
763 :
2017/03/25(土) 22:44:26.52
https://swift.sandbox.bluemix.net/#/repl

中間の構造を破綻させたらコンパイルエラーになったな。

/* /* */

というコメントが見事エラーになった
764 :
2017/03/25(土) 22:44:49.81
もちろん
/* /* */ */
であればエラーにならない
765 :
2017/03/26(日) 03:12:07.48
そうなんだ
/* /**/はできて
/* /**/ */は/* /**//**/って書かなきゃなのかと思ってた
grepした時わかりやすいから//の方が好きだけど
766 :
2017/03/26(日) 09:00:58.48
へー、そうなんだ。ならそれはネストだね
で、そうするとやっと本題に戻れるんだけど、

1.他にコメント出来る言語は?
2.それは普通のことなの??


>>670 : 仕様書無しさん2017/03/24(金) 22:02:31.10
> > ネストされたコメント、たのしーなー
> 何が楽しいのかわからない。
>
> 言語によっては“普通に”対応してある


たのしーなー♪
767 :
2017/03/26(日) 09:03:52.85
>>761 : 仕様書無しさん2017/03/25(土) 22:39:53.93
> それをwrapだというのなら、
> お前が言うnestとはなんだ?
> 言ってみろ

言ったよ? で?

しらねーよ、Swiftとかローカル言語w
もっとメジャーになって広く活用されるようになってから外に出てこいよ、クソ言語w
768 :
2017/03/26(日) 21:27:46.40
>>766
必死だなw

言語(Swift)によっては“普通に”対応してある

事実だっただろw


はっはっは。答えを知っていながら
おちょくるのは、たのしーなー♪
769 :
仕様書無しさん
2017/03/26(日) 22:40:24.25
痛いな
770 :
2017/03/27(月) 09:04:28.08
痛いな(もっとやれwww)
771 :
2017/03/27(月) 12:48:51.20
>>768
おちょくられてるのは、お ま え♪

1.他にコメント出来る言語は?
2.それは普通のことなの??

答えてみろよ、日本語知らねーバカw
772 :
2017/03/27(月) 12:53:06.18
いるよねー、何でもかんでも“普通に”って言うバカ♪

「それおいしい?」
「普通においしい」

いーーーーーーーーひゃっひゃっひゃっひゃ!

バカ満載wwwwwww
773 :
2017/03/27(月) 12:54:59.05
>言語(Swift)によっては“普通に”対応してある

どうせそういうこと言うだろうと思って
>>671から泳がせてんのに
さんざん勿体つけて引っ張った挙句、
想像してた通りのこと言って喜んでるんだからバカも底抜けすぎんだろwww

> はっはっは。答えを知っていながら
> おちょくるのは、たのしーなー♪

やてw バカもここまでくると尊敬するわ  ゆ と り ガ イ ジ くん
774 :
仕様書無しさん
2017/03/27(月) 12:55:39.28
普通のバカ発見
775 :
2017/03/27(月) 12:56:11.39
>>768
ほれ、コレに答えろよ、早くwwwww

1.他にコメント出来る言語は?
2.それは普通のことなの??

答えてみろよ、日本語知らねーゆとりガイジくん♪
776 :
2017/03/27(月) 13:00:35.65
おまえらクソグラマはさ、プログラム言語の前に日本語覚えろよ、な?w
777 :
2017/03/28(火) 00:43:54.85
コメントアウト。って言葉あるよね。
うーむ、動かんな。ってんで
ごっそりコメントにして、新しく書き直すとか。
俺のプログラムはそういいうのが多いよ。

あとから読む人・メンテする人、ばっさり消して下さいね。
俺は消せないです。動かなくなるから。
778 :
仕様書無しさん
2017/03/28(火) 11:28:58.01
>>777
779 :
2017/03/28(火) 11:57:44.62
デバッグを勘と経験だけでやってる素人だから触れるなw
780 :
仕様書無しさん
2017/03/28(火) 12:05:45.33
>>776

//おまえらクソグラマはさ、プログラム言語の前に日本語覚えろ

このコメントを、新規開発ソフトに挿入してみんながどんな反応を示すか
見てみたい。
781 :
仕様書無しさん
2017/03/28(火) 12:34:38.10
なんつうか…不自然な日本語だな…
782 :
2017/03/28(火) 16:38:42.24
>>777
そのままコミットしたら鼻にグーで俺の手を打ち込むからな?
783 :
2017/03/28(火) 19:31:57.99
この業界空気読まないから
そんな理由で優しくするわけがない。
229KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: