1: デフォルトの名無しさん 2018/04/17(火) 10:57:52.15 ID:/iau8dFJ
さすがに1つの関数内でごちゃまぜになってると気持ち悪いけど
別に関数違えばバラバラでも良くない?
統一することでなにかメリットあった?
良い書き方と悪い書き方があって、良い書き方に統一するという話ではなくて
どちらでも良い書き方のうち、どちらかに統一するのは
意味があるのか?って話ね
6: デフォルトの名無しさん 2018/04/17(火) 14:54:58.06 ID:ixI7lVkv
>>1
1人でやるならそれでいいんじゃね?
7: デフォルトの名無しさん 2018/04/17(火) 16:03:42.08 ID:/iau8dFJ
>>6
スタイルがバラバラで、なにか困るんですか?
8: デフォルトの名無しさん 2018/04/17(火) 20:11:43.68 ID:/+eZ0JZT
>>1
>良い書き方と悪い書き方があって、良い書き方に統一するという話ではなくて
それは、悪い書き方を制限するってとらえた方がいい
>どちらでも良い書き方のうち、どちらかに統一するのは
>意味があるのか?って話ね
どちらでも良い(構わない)なら、統一することが良い(望ましい)書き方だ
統一は制限の一種といえるし、そうすることで誰にとっても理解しやすくなる
17: デフォルトの名無しさん 2018/04/17(火) 22:04:23.99 ID:/iau8dFJ
>>8
> どちらでも良い(構わない)なら、統一することが良い(望ましい)書き方だ
なんで?
> 統一は制限の一種といえるし、そうすることで誰にとっても理解しやすくなる
どちらでも良いってことは、人によっては自分のスタイルじゃないものを
強制されるってことですよ? 誰にとってもっていうのは違いますよね?
2: デフォルトの名無しさん 2018/04/17(火) 12:36:46.88 ID:1GolraXE
func_20180417_103423とかいう文化圏で育った奴
3: デフォルトの名無しさん 2018/04/17(火) 13:26:47.13 ID:oudQnCi3
たしかに重箱の隅をつつくような規約は効率が良くなるかどうか疑問だな
多少の表記のゆれよりきちんとモジュール化、カプセル化されてる方が大事
4: デフォルトの名無しさん 2018/04/17(火) 14:29:08.12 ID:KPrnwj2Y
整形機能のあるIDEで1発終了だから気にしない。
5: デフォルトの名無しさん 2018/04/17(火) 14:52:38.93 ID:mpFiPQ3t
WBAWBC統一王者
9: デフォルトの名無しさん 2018/04/17(火) 20:18:18.96 ID:f7PKSmCj
そう言われてみればコーディングスタイル決めてないけど
こまったことないわ
10: デフォルトの名無しさん 2018/04/17(火) 20:23:05.26 ID:Z/PMm1Zv
いや一関数の行数制限だけはマジでかけてほしい
11: デフォルトの名無しさん 2018/04/17(火) 20:41:30.11 ID:f7PKSmCj
>>10
なんでや?
12: デフォルトの名無しさん 2018/04/17(火) 20:56:08.59 ID:Z/PMm1Zv
>>11
だってほっとくと1000行超えてるのに関数に分けようとしねーし
15: デフォルトの名無しさん 2018/04/17(火) 21:15:26.81 ID:KPrnwj2Y
>>12
そんな分け方で良いはず無いだろw
機能単位で最少単位に分割しても1000行超えちまうなら諦めろ
14: デフォルトの名無しさん 2018/04/17(火) 21:04:24.62 ID:f7PKSmCj
ステップ数で成果を測るのが嫌いなのに
ステップ数で関数を評価しようとするみなさん
21: デフォルトの名無しさん 2018/04/18(水) 00:30:32.66 ID:CIIgyV33
コーディングスタイルを決めておかないと馬鹿が好き勝手に変なことやりだして、
説明したり、質問したりのコミュニケーションコストがかかるじゃん
そういう糞みたいな無駄な時間をすごしたくないじゃん
一人で開発してるなら好き勝手やればいい
22: デフォルトの名無しさん 2018/04/18(水) 00:49:52.00 ID:52qEUHSf
>>21
馬鹿と開発しなきゃいいのに
28: デフォルトの名無しさん 2018/04/18(水) 18:19:59.90 ID:H7I9iyKC
>>21
これ。
1人じゃなくても、お互いに信用できる程度の小規模チームならぶっちゃけいらない。
ただいつスポットで愚か者が手を出すことになるか分からんから、ある程度は決めておいた方が後々楽になるっていう経験則を多くのチームが持っているから規約を定めるんだと思う。
24: デフォルトの名無しさん 2018/04/18(水) 01:16:59.78 ID:CIIgyV33
働いたことないのかな
29: デフォルトの名無しさん 2018/04/18(水) 19:32:04.33 ID:BsJyLYoy
>>24
馬鹿とは働いたことない
25: デフォルトの名無しさん 2018/04/18(水) 03:30:06.22 ID:7zOfv67J
一行のif分でも{}をつけろとか、こういうのはたしかにいらんよな
27: デフォルトの名無しさん 2018/04/18(水) 12:48:57.42 ID:/eO0kjhF
>>25
なぜ?
30: デフォルトの名無しさん 2018/04/18(水) 19:33:45.48 ID:BsJyLYoy
>>25
Appleがそれで盛大にミスってたんだよなあ
コーディングスタイルとかそういうの関係なくif文に{はつけるべき
26: デフォルトの名無しさん 2018/04/18(水) 07:47:15.76 ID:9pUXkCln
同じスタイルになっていれば、似たような処理の中の違いを拾いやすい。
関数分割・統合など既存コードを切り貼りする際にスタイルをどうするか考える必要が無い。
32: デフォルトの名無しさん 2018/04/18(水) 22:28:21.42 ID:yZY50SSw
一行のifなら
if(・・・) return 0;
みたいにすればOK
33: デフォルトの名無しさん 2018/04/18(水) 22:55:19.15 ID:FLvVXkO/
>>32
そういうの見ると死ねって思う
36: デフォルトの名無しさん 2018/04/18(水) 23:14:07.92 ID:ITlW1RMQ
>>33
なんで?(殺意)
37: デフォルトの名無しさん 2018/04/18(水) 23:27:00.47 ID:FLvVXkO/
>>36
バグの温床だから
41: デフォルトの名無しさん 2018/04/19(木) 12:06:43.81 ID:K/LVkPLf
>>37
なんで?(殺意)
45: デフォルトの名無しさん 2018/04/19(木) 19:19:03.44 ID:r6J+JAu5
>>41
アップルが実際にやらかしたバグ
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
38: デフォルトの名無しさん 2018/04/19(木) 00:11:07.89
#define ERROR_CHECK(cond) if (cond) return 0
ERROR_CHECK(ret);
こうすべきだよね!
39: デフォルトの名無しさん 2018/04/19(木) 00:45:59.80 ID:LT7XffwA
コーディングスタイルとは関係ない話ばっかり
40: デフォルトの名無しさん 2018/04/19(木) 07:25:36.99 ID:kIK3R/E/
俺はコーディングする時は左足を上にして足を組むスタイルだけど、昔の同僚には椅子の上にあぐらかく奴もいたわ
ここらへんのスタイルも統一した方が良いのか
50: デフォルトの名無しさん 2018/04/19(木) 21:55:26.47 ID:agF5d9pF
2010年代に作られた言語はだいたい
ifの後に単体の文はかけない
必ずブロックがいる
59: デフォルトの名無しさん 2018/04/23(月) 08:13:43.28 ID:BjvECnGu
Rubyで配列作るときに%()を使うかどうかですごい揉めてたことがあったな
これと[]リテラルが混在するとマジでバグの元になるからそういうところは統一した方がいいと思った
75: デフォルトの名無しさん 2018/04/23(月) 21:52:24.00 ID:FGTQYpja
>>59
> Rubyで配列作るときに%()を使うかどうかですごい揉めてたことがあったな
根本的な原因は記号の数が足りないのがいけない
使わない制御コードなくして文字に変更しようぜ!
60: デフォルトの名無しさん 2018/04/23(月) 11:09:34.75 ID:1i6WUaW3
if(honyarara){…}みたいに比較省略できるけど、あれが不具合の原因だと分かりづらいから、何と比較しているのか面倒でも書いて欲しい。
if(honyarara!=false)、if(honyarara!=NULL)、if(honyarara>>0)、if(honyarara==true)とか。
同様に三項演算子使う場合も honyarara ? A : B みたいにしないで、(honyarara != false) ? A : B と書いて欲しい。
63: デフォルトの名無しさん 2018/04/23(月) 12:02:18.74 ID:/uUuSWda
>>60
Javascrptだと特に予期せぬバグになるからな、マジで
65: デフォルトの名無しさん 2018/04/23(月) 12:17:06.31
>>60
boolに関しては書かないのが美しい
62: デフォルトの名無しさん 2018/04/23(月) 11:59:14.16 ID:khho7vfC
ただしこれは同意
> if(honyarara != NULL)
64: デフォルトの名無しさん 2018/04/23(月) 12:17:04.00 ID:V8pBnF9b
>>62
コード中に全角スペースやめてくれ
賢いコンパイラはその旨言ってくれるけどそうでないと
場合によってはデバッグするのかなり大変なんだわ
66: デフォルトの名無しさん 2018/04/23(月) 12:18:31.07
>>64
全角スペースか半角スペースかタブ文字かくらい一目で見分けが付くようにエディタ設定しとけやwww
67: デフォルトの名無しさん 2018/04/23(月) 12:24:05.98 ID:khho7vfC
if(a.isEmpty()==true)
こんなの書いてたら知能に障害があるとしか思えない
78: デフォルトの名無しさん 2018/07/05(木) 06:16:45.11 ID:OTfP6cvC
オブジェクト指向的に考えれば
クラスの内部なんて他のクラスからは知ったことではない
異なるクラスの間でスタイルを合わせる意味は全くない
馬鹿「データベースアクセスクラスとPDFクラスで書きかたが違うんですけどどういうことですか?」
賢者「それらは全く関係がない異なるクラスだからです」
79: デフォルトの名無しさん 2018/07/05(木) 07:56:21.37 ID:qLOD4ZYT
メンテナという全てにアクセスするクラスがいるので統一は必要です
80: デフォルトの名無しさん 2018/07/05(木) 08:14:25.62 ID:68wCRvW6
キャメルかスネークかはそんな気にせんでも良いかなとは思う。
82: デフォルトの名無しさん 2018/07/10(火) 17:15:25.57 ID:hxdwH89H
実際のファイルのスタイルを変えずにエディタ上の編集は好きなスタイルでできるようにする、ってのはあかんか?
細かいとこで無理は出るだろうけど不可能じゃないよな
利点も薄い気はするが
83: デフォルトの名無しさん 2018/07/28(土) 09:28:42.74 ID:E7c9fNX3
>>82
一票!
改行位置とインデントだけでもかなり読みやすくなるし
84: デフォルトの名無しさん 2018/07/28(土) 19:35:15.01 ID:g5xPw0Dm
>>82
今はその方向性が主流
書くときはともかく保存時にフォーマッタに処理させる
フォーマッタに自動でやらせられないものもリンターに指摘させて後で直す
16: デフォルトの名無しさん 2018/04/17(火) 21:35:41.97
プログラマの給料は行数ベースの歩合制にすべき
そうすればこんな手抜きコードじゃなくて
001 for (i = 0; i < 10; i++) {
002 x[i] = func(i);
003 }
誰にでも分かりやすいこういうコードになるだろう
001 x_0 = func_0();
002 x_1 = func_1();
003 x_2 = func_2();
004 x_3 = func_3();
005 x_4 = func_4();
006 x_5 = func_5();
007 x_6 = func_6();
008 x_7 = func_7();
009 x_8 = func_8();
010 x_9 = func_9();
73: デフォルトの名無しさん 2018/04/23(月) 17:37:12.19 ID:f4PMmCW/
やめろ
http://toro.2ch.sc/test/read.cgi/tech/1523930272/
可読性が上がる
この記事へのコメントはありません。