TWO == イラッつとするコーディングスタイル

文法的には何ひとつ間違ってはいないし、本人なりに見やすくしようとする意図は汲み取れるのだが、
どうにも気持ち悪くて、「修正してやる！」と叫びながらキーボードを激しく連打したくなる

そういう薄気味悪いコーディングスタイルを発見したら書き込むスレッド




992 名前：仕様書無しさん[sage] 投稿日：2012/06/03(日) 15:08:56.92
このスレ吐き気する

右に定数書けや糞が

TWO( イラッとするコーディングスタイル )で良かったんじゃないか

タイトルに複数行使えたらよかったのに

for

「STLは遅くてサイズも肥大化するからデータ構造は自作しろ」

乙ｗスレタイうぜぇｗｗｗ

◆zensure
イラッつとするコーディングスタイル
http://kohada.2ch.net/test/read.cgi/prog/1331385629/

このスレタイは好きだ。でも定数は右で

なにげにガンダムZネタ

>>9
じゃマクロ化してやるよw
if( SUCCEEDED( Function() ) )

ヘッダファイルが・・・・
メンテはさほど手間じゃないだろうが、チーム全員で一念発起してかからないと
そのマクロを排除する作業は永遠に不可能

それ以前にMSが使ってるからな
今更変えられん

なんでみんなCなん？

うちは組込みだからCばっかだねぇ
Linuxカーネルにハンガリアンでコードを
ごりごり追加するのが居て気失いそうになります

そりゃ…高級言語の初期ちゅーのはCやろ

大昔から延々と保守されてるVB6のコード相手にしてると
コーディングスタイル？何それおいしいの？というぐらいはちゃめちゃで
こんな高尚なスレにかける話題が提供できないorz

案件として多いであろうC#、Java、PHPがCに似てるからだろう

とりあえず伝えたけりゃCで書いたほうがいちいち説明しなくてすむな

オッサン同士ならな。
今どきの学生プログラマにとってはCなんぞFORTRANやCOBOLと同レベルだろ。

マジだから笑えない。

ドカタ乙

俺今21歳の学生プログラマだがC/C++で書かれるのが一番分かりやすいんだが・・・

>>23
そうか。
俺はわかりにくいんだごめんな。

>>17
長年かけて熟成した秘伝のソースですね。
沢山の材料が変化して複雑に絡み合って、なんとも言えない味になるよね。
特にVBは…

LLはやっぱグルー的な役割が強くて、素材としてはCとかも使えた方が何かといいと思うよ。

>>24
どんだけ素人なんだよｗ

別にCなんて過去の遺物素人でも全然問題ないです

アセンブリ言語もC/C++も使えずしてどうやってデバグやってんだお前ら

は？デバグなんてするわけないじゃんｗ

プロのプログラマーじゃないなら特に必要ないと思うよ。
学生とかに向かって「Cが出来ないと話にならない！」みたいなこといってる奴はもう完全に頭おかしいおっさん。

低レベルなところいじれた方ができること増えるし、プロなら必要だとおもうけどね。

『低レベル』っていう和訳はなんとかならなかったもんかね。

機械からの主観なのがややこしい。

「プロ」ねぇ…

プロの「IT技術者」には必要
プロの「IT事務屋」には不要

歴代担当者がそれぞれ自分の得意な言語でツール実装してたりとか、
言語増えすぎでたまにイラッつとする事もある。

なんか、Cで挫折した奴が「Cなんて今さら不要」って叫んでるみたいだが
Cってそんなに難しいのか？
ポインタがわからなかったか？

図星さしちゃったかなｗｗｗｗ

メモリポインタって何？

ダブルポインタのこと。

メモリメモリ番地

図星のアドレスをポイントしてるのか

>>37
Cはめちゃくちゃ難しい。ハンドルとかポインタとか意味がわからない。ソースは俺。

Cで書いた方がいい時以外でもCを勧めてないか？
むしろ、LL言語に適応できていないんじゃないか？

Cできない奴が必死すぎるんですけどｗ

　　　　　　　　　　　　　　　　　　　　 ／j
　　　　　　　　　　　　　　　　　　　／__/　‘，
　　　　　　　　　　　　　　　　　 ／／　 ヽ　 ', 、
　　　　　　　　　 　 　 　 　 　 /／　　　　‘　 ! ヽ　　　　　　　　　　　　　…わかった　この話はやめよう
　　　　　　　　　　　　　　　　/ｲ　　　　　　 ', l　 ’
　　　　　　　　　　　　　　　iヘﾍ,　　　　　　 l |　　’
　　　　　　　　　　　　　　　| ｎﾍﾍ　_　 　 　 | |　　 l　　　　　　　　　　　 ハイ！！　やめやめ
　　　　　　　　　　　　　　　| l_| | |　ゝ￣`ヽ | |〈￣ﾉ
　　　　　　　　　　　　　　　ゝｿﾉﾉ 　 `ー‐'　l !　¨/
　　　　　　　　　　　 ｎ/7./7　∧　　　 　 　 j/　/　　　　　iヽiヽｎ
　　　 　 　 　 　 　 ｜! |///7/:::ゝ　　　ｒ=＝=ｵ　 　 　 　 |　!　| |/~7
　　　　 　 　 　 　 i~| | | ,'　'/:::::::::::ゝ、　l_こ./ヾ.． 　 　 ｎl　l　.|｜/
　　　　 　 　 　 　 | | | | l　{':j`i::::::::::::::::`ーｒ ' 　 　 　 　 |｜ー---{
　 　 　 　 　 　 　 | '"￣￣iﾉ .l::::::::::::::::::::::∧　　　　　　 |　ゝ　　　 ',
　　　　　 , 一 ｒ‐‐l　　　γ　/、::::::::::::::::::::::::〉ー=　___　 ﾍ　 ヽ　　　}
　　　　／ o　 |!:::::}　　　　 / o` ー ､::::::::::::i　o　,':::::::{`ヽ ﾍ　 　 　ﾉ
　　　/ o　 　 ﾉ:::::∧　　　/ヽ　　o　 ヽ::::::::|　o　i::::::::ヽ、　/　　　/
　　 /　　　 ノ::::::/　　　 /::::::::ヽ　　o 　ヽ:::|　o　{::::::::::::::Υ　　　/

>>44
先輩、C言語でどんなすごいプログラム作ってるんですか？

Cができるのが自慢なのかｗ
まさか21世紀になってそんな奴見るとは思わなかった。

20年以上前にできた言語をいまさら使おうという神経が分からない

オートマ限定男が必死になるのと似てるなw

お前ら調子乗りすぎるなよ。
C出来なくても問題ない分野も多いけど、開き直って偉そうにしたら、C言語最強のおっさんと同じレベルになるぞ。

AT限定免許ができたからかえってMT運転できるのを自慢したくなる、みたいな？

そういやこの前、中型とかいうのが出来たせいで
それ以前にとった普通で少し大きなのを運転できるんだよね

似たようなシチュで、俺の婆ちゃんは大型バイクに乗れるらしい

>>52
別に中型ができたせいで以前の普通で乗れる範囲が広がったわけじゃないけどな。
ただ単に、新しい普通の範囲が狭まったから、以前の普通を「中型の8t限定」に改称しただけだろ。

C読めない奴にイラッつとする
Cばかりな20世紀おっさんを見てるとイラッつとする

>>48
50年前に出来た数式を使おうと思わない

　　　　　::|　　　　　从
　　　　　::|　 　　　从从　
　　　　　::| 　　　从从从
　　　　　::|. 　／　　　|.| ヽ.
　　　　　::|.　/　　　 　|.|　 ヽ
　　　　　::|-〈　 __　　　||　　｀l_
　　　　　::||ヾ||〈　￣｀i ||ｒ‐'''''i| | 　　
　　　　　::|.|:::||　｀--ｲ　|ゝ-ｲ:|/
　　　　　::|.ヾ/.::.　　　　|　　./　 　 　
　　　　　::|　　';:::::┌===┐./ 　　　　
　　　　　::|　＿〉ヾ ヾ二ｿ./
　　　　　::| 。 ゝ::::::::｀---´:ト。
　　　　　::|:ヽ 。ヽ:::::::::::::::::ﾉ 。 ｀|:⌒｀。
　　　　　::|:::ヽ　。ヾ::::::/　 。　 ﾉ:::i　 　｀。
　　　　　::|:::::::|　。　|:::| 　。　/:::::::|ヾ:::::::::）
　　　　　::|::::::::| . 。 (●) 。　|:::::::::::|､ 　::::〈

>>48
80年前にできたアルゴリズムを使おうとは思わない

>>56
流れ止めろよ

switch ((a == 1) == false)
{
case true:
break;

case false:
break;
}

これ書いた奴は天才だと思った(小並)

>>48
100年前から使われてる傘をいまさらつかおうという神経がわからない

>>59
難っｗ

>>48
紀元前にできたコンクリートをいまさらつかおうという神経がわからない

どうせ言葉とか文字とか火とか肉体とか細胞とか言い出すんだろ
つまんねー流れだな

>>48
32年間女から守り続けてきたお前の股間をいまさらつかおうという神経がわからない

>59
いったい何を行う処理なんだ……

大学で出てくるif使っちゃ駄目っていう宿題とかそんな感じだよな

>>59
これってかなり簡略化した形なんじゃない？

if(a>10) {
else if(b<10) {
else if(c==5) {
}
みたいなものを書く時に

switch(true)
{
　case a>10: ・・・ break;
　case b<10: ・・・ break;
　case c==10: ・・・ break;
}

みたいなことができる。

((a == 1) == false) これはtrue/falseが言語で規定されてないのでは？
つまりtrueは1でfalseは1以外みたいな値にしていると高架化ざるを得ない場合がある。

え、何言語？

>>67
falseが0でtrueはそれ以外ってんじゃない環境がいまどきあるのかー
てか、上記環境でtrueと比較するカスがいなくならないのはなんでなんだぜ

>68
VisualBasicはswitchじゃなくてselectだけど、各caseにif文と同じレベルの条件文書けるね。

>>69
お前は文系だろ。若しくは理系でも数学止まりだろ。

COBOLのEVALUATE文はそんなんだけどなぁ。

Perlも>>67みたいなことできるよね。

数学は科学の女王

スリーサイズは?

B: π
W: e
H: i

イラッつ

実際、ゴミみたいなコード書いてイラっつとさせる奴って数学的センスがないよな

でも動くし

そこ言葉にこそイラッつとするわ
まあ俺の周りにそれを言い訳にするやつが多いからかもしれんが・・・

メモリリークしてんのに「でも動くし」で片付けたのはさすがに呆れた

「そこ言葉」にこそイラッつとするわ

あとでまとめて直すから！

なぜか、どんどん空行を詰めていく奴がいるのだが
理由は不明

比較で=をひとつ書き忘れて代入にしてしまう奴ってVB厨だろｗ

>83
逆に無駄に空行入れまくるヤツも居るんだよなあ

>>85
具体例で議論しようか？

>>85
俺の経験上、空行を無駄とか言ってる奴のソースは大抵クソ。

関数分ける程じゃない処理ブロックごとに空行入れるとかはやるな。
最近は中カッコで関数内を区切ったりもする。

>>85
お前には無駄に見えるだけ
てか、空行全くなしで書く奴とかまれにいるんだけど、むかつくわ

実際にコード見てみないと「無駄な空行」がどれくらいなのかわからんね

>>88
意図の判るスコープだったらいいが、意味不明なスコープだったらイラッつとくる。

とりあえず、2行以上の空行はいらんな。

チーム内でインデントにタブ文字使う派とスペース使う派が混在してるとけっこうウザい

>>89
空行なしで書けない奴は下手

>>94
曲芸やってるんじゃないんだから、他人が読みやすいように考えろ
大体お前、毎日ケアレスミスのバグ発見されてるだろ
へらへらしながら「スイマセンスイマセン」連呼してるの傍で見てると
顔面パンチくれたくなるんだよブス

>>95
おまえのレベルが低いのはわかった。
次の方どうぞ

>87,89
1行や2行まあ3行なら全然OK
むしろ適度に入れてくれたほうがいい

が
特に意味もなく10行規模で大量に入れて読みにくくするのを無駄と言って何がおかしい？

他人の読みやすさのための手段が
空白行という発想の時点でしれてるな
要は下手くそ

>>97
理由を考えてみよう

・いやがらせ
・使っている開発ツールのエディタが勝手に入れた
・ファイル分割せよという無言の意思表示
・馬鹿には見えないコード
・君が好きだ

>>99
あれ、あぶりだしだよ
知らない奴結構いるんだな

>99
本人に聞くと「ざっとスクロールしたときに修正した箇所をすぐ見つけられるようにしている(ｷﾘｯ)」だそうで
馬鹿だということは理解した
一応上司なんで流石にウゼエとまでは言えなかったがコミット前に消すようお願いした

そもそもスクロールが不要なように書け・・・・と言いたいが、
たとえばクラスソースはメンバ関数のソースがだらだら並ぶ

どうすれば

まともなエディタ使え。

スクロール不要なソースなんてほとんどねーわ。

今時たいていのエディタもIDEも折り畳みできるだろ

結局折りたたみか・・・・
もっと未来的なすごい何かはないのか

eclipseだとアウトラインプロセッサ的なツリー表示あるじゃん
あれでいいんじゃないの
統合環境じゃなくテキストエディタでできるソフトは知らないけど

昔80x24文字のスクリーンエディタでコード書いてたときは、
関数の頭の行が 1 + 24n 行めにくるように関数の末尾に空白を入れて調整する奴はいた

private string foo(){
string str = hogehoge();
#region スクロールしたときに修正した箇所をすぐみつけられるようにした、俺様用しおり


















#endregion
return str;
}

if(ここにものすごく長い条件式){[TAB][TAB][TAB]//コメント

　・・・・・・・・・・・・・・・・・・・・・・・・

}else if(ここも長い長い長い長い長い長い条件式){//コメント

　・・・・・・・・・・・・・・・・・・・・・

}else{[TAB][TAB][TAB][TAB][TAB][TAB][TAB]//コメント

　・・・・・・・・・・・・・・・・・・・・・

}


↑
嫌だ！！！！

>>110
自分なら、こう書く /* TABの個数はコメント開始の桁をそろうように合わせる */

if ([TAB][TAB]//コメント
　　ここにものすごく長い条件式
) {

　・・・・・・・・・・・・・・・・・・・・・・・・
} else if ([TAB]//コメント
　　ここも長い長い長い長い長い長い条件式
) {

　・・・・・・・・・・・・・・・・・・・・・

} else {[TAB]//コメント
　・・・・・・・・・・・・・・・・・・・・・

}

行頭のインデント以外でTABを使う奴にイラッつとくる

if () {
　　// ※
　　・・・・・
} else {
　　// ※
　　・・・・・
}

俺はelse ifを含む条件分岐はこう書いている
if (条件１) {
　処理１
} else
if (条件２) {
　処理２
} else
{
　処理３
}

ifの桁を揃えたいのが理由なんだが、見づらいだろうか？

>>114
見難いし
最後elseの{の位置がキモイ

>>113
コメントを行頭で揃えるなら、こんな感じかな

if (
　　// コメント
　　長い条件式
) {
　　// コメント
　　・・・・・
} else {
　　// コメント
　　・・・・・
}

>>114
二分岐(普通のif文)と多分岐(else if)との区別しづらいと思う

条件がifと同じ行から始まってないのはイラっとくるな

要はぱっと見てすんなりロジックが”入ってくる”か、違和感があるかの感覚なんだよな



なんだっけ、人種や文化に関わらず全ての人類が共通して持つ感覚
たしか学問的に名前があったと思うけど・・・・
（赤→攻撃的、とか、丸形→親しみやすい、とか）

長い条件式は関数にしろ。リファクタリングの基本だ

変数の名前が長いだけなの・・・

関数の名前も長いんですね

変数名や関数名は長くてもいいじゃん
変に短縮されるほうが困る

センスの問題だよな
イテレーターにiとネーミングしたコード見たらファックしたくなった

イテレータだからiでいいじゃないか。

素晴らしすぎて愛をもってファックしたくなったんだよ

長年やってきたが iter > it > i と変わったな
てか範囲forもっと使えるようにになってくれ

iは整数に使って欲しい
イテレータはitrとかにして

特にメリットを感じない俺様ルールにイラっつとした

それは愛のイテレーション

イテレータはiteだな。お手本がiteだったので

ずっと it にしてるなあ
itr はなんとなくウザったい(t→r のタイプがめんどい)けど i を使うのはなんかちょっと…派

習慣的にiはforループのカウンタにしてるからなんか気持ち悪くてitにするなあ。
なにかを指している→itみたいな意味も込めて

FOR_EARCH( i, destination_container )
{
　　FOR_EARCH( j, source_container )
　 {
　　　　　i.insert( j );
　 }
}

Google Code Searchの生き残りで調べてみた
http://code.google.com/searchframe

検索式はこんな感じ(iter)
\Witer\s*=\s*\w+\.begin\(\s*\)

itr 75044
it 52320
i 37154
iter 23608
p 1830
ite 811

過半数には満たないがitrが流行のようだ。

>>134
どれでも意味はわかるから、どれでも構わないな
自分は i だが

こんだけ散けてればTOP4は容認せざるを得ないだろう

iteはマイナーだったんだな。

まあ、イテレーター使ってるやつが相当少ないのもあるが。

お手本になったコード以外で使ってるのほとんどみねぇ。

itor 1800

iter は、どうしてそう略すの？イテルって読むの？ ってイラッつ。

ENUMerator→enumなんだから
ITerator→itに決まってる。

>>139
こういうわけわからん俺様ルールつくる奴にイラッつとくる

ちょっと納得しかけた自分にイラッつとした

UNIX系のGUIツールキットであるGTKの場合、
Iterator の 略語(変数名)は iter で統一されているみたいだね

あと it という単語は、一見して代名詞(this や that)とまぎらわしいと思う

省略するしないのラインは微妙だね。
iterator, array, index とか instance とか。

aDataとかiNumとかハンガリアン付けたがるオサーンばかりの職場だが
theって頭に付けてるやつは今日初めて見た
singletonなインスタンスとかにはonlyOneとかつけてたし

これ一体どこの流派だ？

theはマイクロソフトじゃないの？

CWinAppの派生クラスのオブジェクトはウィザードでプロジェクト作った段階の
スケルトンでtheAppってグローバルに宣言されてるよ。

>>144
今は亡きCマガの記事で見かけたことがある・・・
と思ったらWebで見れるのね

プログラミングの禁じ手（C言語版）
ttp://d.hatena.ne.jp/elwoodblues/20090206/1233878765

> 名前といえば，ハンガリアン記法という，暗号めいた名前を作り，型情報を名前の
> 一部にするという不思議な記法があります。ある大手のソフト会社の社員が提唱
> しているので有名ですが，同時に，同じ会社の社員から強烈に批判されていること
> でも有名な記法です。

中略

> 筆者は型よりも，むしろスコープ(通用範囲)を基準に命名規則を考えています。
> これは筆者がよく使うCode WarriorのPowerPlantというクラスライブラリで
> 採用されている命名規則をほとんどそのまま見習っているだけですが，参考まで
> に示しておくと，
> ・関数名は大文字で始め，変数は小文字で始める
> ・外部変数は「g」で始まる名前にする
> ・構造体(あるいはクラス)のメンバ変数は「m」で始まる名前にする
> ・自動変数は「the」で始まる名前にする
> ・引数は参照のみは「in」，書き換えをするのは「out」，両方あるのは「io」で始まる名前にする

なんか違和感あるのもあるな

static または private な関数は小文字で始めるという規約をテスト中

privateな関数名は小文字で始めるって規約あるある。
変数名と同じ表現になってイラっとした。

メンバ関数なら、スタック変数とは使うときの書き方が変わるから、同じ名付け方でいいと思うけどな

the はコードウォーリアのサンプルコードがそうなってた。
Smalltalk 方面の anApple とかからインスパイアされたんだろうが、単数か複数かならまだ情報も増えようが、the はノイズが増えてるだけに思う。
ただ、これをまねて、大文字の The はアプリケーション唯一のインスタンスに使うようになった。TheDictionary のように。

関数名と変数名の命名の差で言うと、関数は動詞始まりというのが昔あった。
動詞始まりというのは要するに関数名全体を命令形の節にしてしまうということだ。
英語で読み下せるプログラムを目指してた人たちがいたらしく、SQLとかそういうことだと思うが、今の obj.pred() 形式には合わないかもしれないね。
if ( container.Contains( item ) ) ...
みたいなのに名残はある。
これはたまたま珍しくきれいにハマる例だけど、なかなかきれいには命名できないね。

>>118
亀だが
集合的無意識だっけ？

引数はa_ 参照はrf メンバはm_ constはc_とかにしてるな。

右にどんどん長くなる。　フルHDじゃたりねぇ。

bool型変数へ代入するときや、bool型の戻り値を返す際の、
比較演算子・論理演算子使用禁止

そんなに中括弧が好きなのか、コーディングルール作成者は

>>153
つまりこういうのが禁止ってこと？

bool b = (x > y);
return x == HOGE;

ぶるっつ

>>153
デバッガでステップ実行したい、っていう理由で、そういう縛りがある客先があったなぁ。
三項演算子も使うなって言われたわ。

>>154
そうそうそれ

>>154
bool b = std::less<decltype(x)>()(y, x);
return std::equal_to<decltype(x)>()( x, HOGE );
でどうだろう?

すげぇイラッつとするなｗ

>>150
theとかってのはシステムハンガリアンじゃない本来のハンガリアンじゃないか？
あと、theってのは唯一じゃなくコンテキストに依存してるって意味だと思うぞ。

>>158
うぜぇｗｗｗｗｗｗｗｗｗｗ

>>160
>システムハンガリアンじゃない本来のハンガリアン
アプリケーションハンガリアンな

データ仕様書に「2の補数をとる」とあって、2の補数を計算するコードを真面目に書いた奴にはイラッつときた。

const int getIndex(void) const { return m_index; }
const int* const getArray(void) const { return &m_array[0]; }

キモッ

>>160
俺は定冠詞と解釈したんだが、アプリケーションハンガリアンだと the はどういう意味になるんだよ。
そして読み落としだと思うけど、「唯一」に関しては、「大文字の The」って書いてあることを確認してくれ。

>>163
1の補数マシンを想定してより完璧な移植性を取ったのでは。

>>165
Theだと、この前のアレとか、ニュースになってたアレとか、
文脈上で個が特定できるが、固有名詞が無いんで抽象的に呼んでるものを指すだろ。
ただ、文脈の主体が変わればTheが示してるものは変わるんだから唯一ってのはやっぱり変じゃね。

>>164
publicに変数置いてるやつに比べると、天と地の差がある。

もっともオレがそのコードみたら、アホが、publicに移動しないようにcppに移動させるけどな。

コメントが関西弁

コメントがハングル

>>170
イラッつとするより、反吐が出るな。

>>168
C++ならgetが付いてんのがキモいわ
go langとか新しい言語なら非推奨ですらあるのに

C++()じゃ命名規則ぐらいしか新しくできるとこないもんなｗｗｗ

162 ： 仕様書無しさん [sage] DATE:2012/06/30(土) 12:38:09.93

printf("%d", node->next->next->next->next->next->next->next->data);


163 ： 仕様書無しさん [sage] DATE:2012/06/30(土) 12:59:45.09
>>162
そんなコードを書いた奴の後ろに回って、グーで殴りそう。

164 ： 仕様書無しさん [sage] DATE:2012/06/30(土) 16:39:05.05
>>162
クソワロタｗ

>>172
省略引数があるから、GetとSetはつけなきゃマズイだろ。

Javaのbeanによる悪習を他の言語に撒き散らすなよ

Javaがもたらした最大の功績はJavaDocスタイルのコメントの普及

//! //<　こういうやつだっけ。　あれなんかのツール使ってると意味があるのかね。

>>172はむしろ省略するならIndexの方だったな

>>164
＞const int* const

const int*で十分だな
典型的なconst病

const int*

int *const

これ意味違うんだから意味あるんだぜ。

イラッ

>>179
うちも昔const病にかかってたわｗ

const char **a;
const char **const b;
const char *const *c;
const char *const *const d;

労力や可読性が犠牲になる割には見返りが少ないんで、
結局 a に落ち着いたｗ

>>180
後者を関数につける意味あんの？

typedef int *pint;
void foo( pint &&x );に渡せないとか?

>>183
関数もクソも戻り値だろうが。　ポインタとしての変更禁止と、ポインタが示す先の値の変更禁止で両方意味あるだろう。

意味を調べもしないでイラッつっとしてるとかまだまだゆとりだな。

>>185
変数だったら意味があるが、関数の戻り値の場合は
const int * でも const int * const でも差はない。
なぜならポインタ値はコピーされるから。
int x() でも const int x() でも差がないのと同じ。
お前こそちゃんと調べたほうがいいよ。

戻り値の受け型の指定だからコピーとか関係ないだろ・・・

>>187
>>164の「関数の戻り値の型」の話だろ
戻り値を受ける「変数」だったらそりゃ意味あるわい

恥かいたのをごまかしたいのか？

>>185
だから戻り値のアドレスを変更禁止にしてどうすんだ
バカだろお前

getArray() = &hoge[0];
こんなことができるとでも思ってるんだろ。
ポインタ覚えたての学生が鼻息を荒くして噛みついてみたってとこか。

>>183はイラッとしてるのか？
>>185のお子様臭が凄い

馬鹿晒しage

inst = GetInsutansu ();

朝っぱらから頭の痛いものが送られてきた
会社行きたくねぇなぁ・・・

ローマ字かｗｗ
ローマ字禁止って縛りは今まで経験したことがないが、やっぱり長ったらしい英単語を
つなぎ合わせた名前より、ローマ字で短くした方が判りやすいって思う人多いのかな。

>>192
バカは勉強すればいいけど、クズが上塗りされてる奴は本当にどうしようもないな

>>196 主張に御同意頂き恐悦至極

>>185
40前後のメガネデブ。
基本情報技術者の試験に3回以上落ちたことがあると見た。

5回ほど落ちましたが何か？

今、仕事でプログラムのメンテやってるんだが、ソースコードの酷い事。
マジックナンバーだらけだわ、同じコードの繰り返しがあるわ、意味不明な名前の変数があるわでもう・・・

コーディングの勉強をある程度やってきた人なら、それくらい駄目なことは分かるはずだが・・・
お陰で機能修正や拡張がすさまじく面倒。
でも、仕事だから嫌とは言ってられない。

ああ、明日も頑張ろう・・・・・

>>200
仕事でプログラミングするのは初めてなのかな？

これから先もずっと、そういうどうしようもないコードと付き合っていくことになるからね。

おれ、commandのこと、ずっとcommandoって書いてた

>>201
そう。
今年新人で入って初めてプログラミングの業務に就いたんだ。

当初は、企業ではもっとソースコードの管理に厳格なイメージを期待してたから、
そこから色々学ばなきゃという印象を持ってた。

学生時代には、エレガントなコードを書くよう、口を酸っぱくして言われてきたので、
なおさら愕然としちゃったね・・・・・
これも一つの勉強だと思って頑張っていこうと思う。

>>200
うちも似たような事やってるわｗ
どうにもならんのでリファクタしていらんコードとか
使ってないコードとか消して行ったら機能追加する前よりコードが減る減る
最近いかに行数減らすか楽しくなってきたよｗ

長くやってりゃいい事もあるさがんばれｗｗ

>>204
ありがとうございます

>>200
意味不明なコード
規約なし
書き方に一貫性なし
コメントなし
ドキュメントなし
テストなし

こんなのザラだ
気持悪くて鬱になりそうだ

そうやって自分では直したつもりなのに、バグを出して痛い目に遭うのが次の段階

そして自分ではエレガントだと思っていたコードがこのスレで叩かれるのが数年後

良いコード：　縦に短く、横に四角く
悪いコード：　縦に長く、横にとんがる（ifのネストが主な原因）

#define PREFIX "foo"




PREFIX".txt"←というリテラル文字列を使う



IDEが親切にSyntax Errorを警告してくれる
かたじけなくてとてもイラッつとする

気持ちは分かるが広く使われ過ぎているしエラーにもならんだろ。

>>200
悪いのはコーディングした本人でも無いことが多い
あなたにもそういうスタイルのコーディングを強制されることになるでしょう

>>204
リファクタリングが許されるようなところは、そもそもそうはならないレベルの職場と思ってたけどそうでもないんだな

そもそもリファクタリングしてるほど納期に余裕無い

主なリファクタリングの流れ

「あとでリファクタリングするから今は動けばいいや」

数年後

「なんだこのクソコードは」

リファクタリング

>>190
変更不可能の定数に意味はある。

>>216
変数なら意味があるのはみんな知ってるんだよ
関数の戻り値の型の話だっつってんだろ

そこをねじ曲げてゴリ押そうとしてるんだな
ゆとりとか言って煽った手前、引くに引けないんだろうが恥の上塗り
メガネデブ確定

for(int i = length - 1; i >= 0; i--) 流派と
for(int i = length; i > 0; i--) 流派と
for(int i = length; --i >= 0; ) 流派で社内派閥争いしてるんだが

惜しいな、俺は
for(int i = length; i > 0; --i)
派だ

> for(int i = length; i > 0; i--)
> for(int i = length; i > 0; --i)

ターゲットCPUによって使い分けるんじゃなくて、どちらかに統一するの？
何か理由があるのかね

>>219
不等号の向きにイラっとするのは目をつむるとして、
1番目と2番目はループの中でのiの使い方次第じゃね？

3番目は有り得ないだろ

>>221
前置にするのは c++ のクラスの場合に一時オブジェクトのコピーが発生しないようにするため。
int には関係ないが、教条主義的に前置に統一しても問題ない。

>>222
ありえないってことはないと思うが while にしろと思う。

>>223
iをブロックスコープの中に押し込めたいんじゃね？
whileでそれをやると{}がもう一段増えるだろ

>>223
一時オブジェクトのコピーが発生するかしないかはコンパイラやコンパイラの最適化条件によるだろ
アホかよ

>>225
おじいちゃん、もうご飯食べたでしょ

うん、おととい食べたばっかり

>>217
戻り値の型でも意味あんだろうが

ポインタのアドレス変更禁止とポインタの参照先の書込み禁止にマジで意味ないと思ってんの？
readオンリーのポートのアドレス返すのに使うだろ。

中途半端に片方にだけconstつけてもメモリ空間に割付られるだろうに。

>>186

>>229
アドレスとポインタの違い分かってるか？

分かってないから食い下がってるんだろ

>>225
どんだけCompilerが進歩しようと
組み込み型以外のPost Inclimentで一時変数作らんなんて無理だろうが
最速な方法でも一時Pointerに突っ込んどくぐらいしか方法がない

int *point = &abs( 100 );
*point += 10;
こんなんできたっけ？

>>233 register

つーか、組み込み型以外のPost Inclimentって何？
言葉作らないでほしいなぁ、まー、知ったか野郎によくあるパターンなんだけど

ところでInclimentのスペルが違ってるけど、大丈夫か？

Incrementだよな?
2カ所も違っててこれは恥ずかしいw

頭の中にClitorisの綴りが焼きついているのだろう

筆記体で書かないとスペルが怪しくなるおっさんが通りますよ？

昔は、筆記体で書ける→勉強できるカッコイイだったのに、いつのまにか
筆記体で書ける→古い世代

悔しい

　　　　　　　　　＿人人人人人人人人人人人人人人人＿
　　　　　　　　＞　　　そうなんだ、すごいね！ 　　　　　＜
　　　　　　　´￣^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^￣
　　　　　　　　　　　　__､､=--､、　　　　　　　　　＿＿
　　　　　　　　　　　/　　　　・　ﾞ!　　　　　　　／・　　　｀ヽ
　　　　　　　　　　　|　・　　　__,ﾉ　　　　　　 （＿　　　 ・　|
　　　　　　　　　　　ヽ、　(三,､,　　　　　　　 　＿）　　　 /
　　　　　　　　　　　　/ー-=-i'’　　　　　　　（__＿＿,,,.ノ
　　　　　　　　　　　　|＿＿,,/　　　　　　　　　　|＿＿ゝ
　　　　　　　　　　　　　〉　　）　　　　　　　　　　（　　）

>>238
筆記体、スペル覚えやすかったよな
ブロック体で書くと間違うから書けなかった…

筆記体じゃないけどadministratorとかは
キーボードならすらすら打てるのにスペルを
口で伝えようとすると混乱する

>>235
registerがどうしたって？
register使おうが一時変数に突っ込まにゃならんことに変わりないだろ

>>237
Christrisがどうしたって？

>>242
ARMでも勉強しとけオッサンorボーヤ

ARMでC++がどんだけ普及してんだよ

iPhone や VITA では普通に使うし、十分だろう。
つーかもう新品売ってないし、D&Eで。

お前が組んでるのかって話だろ

>>244
詳しいんなら、あの三番地コードでどうやって
一時変数を消せるのか書いてみ

>>247
普及がどうこういうのに、「お前が組んでる」がどう関係あるんだ。
ちなみに、俺の話ならどっちも組んでるよ。

そんで、The Annotated C++ Reference Manual
　http://www.amazon.com/dp/0201514591
ってのがあって、これが 244 の ARM ね。
その和訳 注解 C++リファレンスマニュアル
　http://www.amazon.co.jp/dp/4810180271/
は絶版なわけ。
で、今読むならC++の設計と進化
http://www.amazon.co.jp/dp/4797328541/
になるんだけど、これの略称が D&E ね。
って、こっちももう在庫ねぇし。

という共通理解があるからこそ 245 がボケとして成り立つわけだ。

>>249
お前がiteratorでポストインクリメントすることとそれになんの関係があるんだ？

>>249
>ちなみに、俺の話ならどっちも組んでるよ。
で、Post IncrementしたIteratorはどういうニーモニックを吐いてるんだ？
組んでるんだしコードで説明できるだろ早くしろ。
ちなみに、std::vectorじゃ意味ないんでstd::listを使った場合の
ニーモニックで説明してくれ。

>>249
てっきりこれの話かと思った
http://ja.wikipedia.org/wiki/ARM%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3

http://goo.gl/toasP
これか？どこのことを言ってるんだ？

>>250-251
俺は 246 なんだけど。
君はどっちの立場で、どっちの言い分が分からないんだ？

ちなみに Xcode についてくる iPhone 向け stl のソースコードでの std::list::iterator の operator ++ のソースは
_Self&operator++() { _M_node = _M_node->_M_next; return *this; }
_Self operator++(int) { _Self __tmp = *this; _M_node = _M_node->_M_next; return __tmp; }
だよ。

>_Self operator++(int) { _Self __tmp = *this; _M_node = _M_node->_M_next; return __tmp; }
一時変数発生してるじゃねぇか

>iPhone や VITA では普通に使うし、(何が？)十分だろう。
>つーかもう(何の)新品売ってないし、D&E(C++の設計と進化)で。

主語がなさすぎるし、最後の一文が他とどうつながってんのかさっぱり判らん
そりゃ周りが混乱するわ

あれ？アセンブリまで下がったレベルの話でないの？
やっぱ、変な言葉作っちゃう知ったかはダメだなぁ

ARMったらNEONだとかThumbたとかそっちの話だと思うような…

俺は 244 ではないし、一時変数のコピーを否定してない。
245 のボケを拾ったのと、ARM での C++ の普及について突っ込んだだけ。

>>259
じゃお前の書いたD&Eって何だよ

やっと帰れる

せうえば今日if(var=false)にであったぜ
何してくれてんだおっさん…

>>261
if(false=var)　→　コンパイルエラー

if(var=false)はwarningは出るんだけど
エラーにはならなかったな、ウチの環境だと。

大量のwarningに埋もれてたんで発見遅れたが。

>>263
if (var=false)はエラーにならないが(ただし動作としては想定外だろう)

if (false=var)はエラーになる。

変数に定数を代入出来ても、定数に変数を代入は出来ないだろう？

またその話題を繰り返すというのかｗ

それ以前に真偽値をわざわざ比較で聞くなよ、って話じゃないのか？

ぼくは左定数派ちゃん!
もうc++書かなくなったけどなー

左に定数つかうのってjavaで
if( "Hoge".equals( str )) ...
の時だけだろ。

両方とも定数っての見たことある

PHPで本番環境と開発環境で別々の文字列をdefineしてる場合に、定数同士で比較して環境により分岐させることはある。

エラーにならないなら同じ変数を比較することがあるな
NaNを調べるのはそれが一番手っ取り早い

自己流のスタイルにこうでいする奴にろくなのがいない

うちのはそんな高尚な理由ではなくて、
最初は
If Hoge(fuga) = 7 Then
だったのが、さまざまな改修を経た結果、よく見るとHoge()関数の戻り値が常に７であることが判明
Hoge関数を全部7に置換した結果
If 7 = 7 Then
両方とも定数のIf文のできあがりｗ

マジでそんなコード存在してるのか...

常に0とか常にtrueならまだしも、常に7を返す関数とはいったい……。

cやperlみたいな定数を持たない言語では関数で定数を表現することがある。
ていうか昔のperlのマニュアルにはシンボル使うよりも高速って書いてあったくらいだし（うろおぼえ）

>>273
今の実装ではHoge(fuga)はたまたま常に7を返すけど、
本来のHogeは7以外の値を返すこともある関数
だったりしないか？

>>274
残念ながら存在するんだ。
このIf文消しちゃうとコードチェックの範囲が広がるってんでそのままにしたらしい。
Else以下も普通に残ってる。
>>275
もとはfugaの値から判断していくつかの値を出していたんだけども
平成15年ぐらいからその判断が意味をなくしていたらしい。
>>277
年度ごとに判断内容を切り替えていたらしい。
でも平成15年以降はどう考えても7しか返せないようになっていて、
システム全体で過去の処理は行えないようになっているので
今となっては何を聞かれても７としか答えないアホの子みたいな関数になってました。

よくわからんのだが、それなのになんでわざわざ関数を定数に置き換えたの？

後々のためにコード内に過去の実装をそのまま残すとか、もうやめてほしい
どうせ数ヶ月もすれば何が書いてあったかなんて作業者本人すら覚えていないんだから
コメントアウトを外すよりも一から作り直したほうが安全で速いだろ

>>279
だよな・・・
わざわざ関数を定数に置き換える理由がわからん

こうしてソースコードにおけるトマソンがまた一つ出来上がるのであった

>>282
『トマソンコード』

(　・∀・)ｲｲ!!

ファッション業界見習って無駄なコード追加しよう

>>275
constの無い言語で定数を定義してる場合7だけ返す関数とかありうるな。

Resize( ShowLimit() /* 7 */ );

このスレのせいで他人のコーディングスタイルにイラッとすることが増えた気がする。
コードの解析が進まなくなっちまったでねぇかｗ

>>278 歴史や理由があるなら、許されると思う。
結構高級な悩み。

このスレに出てくるイラッっとさせるコードを生み出してる人たちって、
フォーマッターとか使わないで手作業でコードスタイル修正してる人たちばっかりなん？
アホみたいな作業は自動化してしまうような時代に、原始的すぎだって指摘してやろうぜ

あー、変数名とか左辺右辺とか、フォーマッターとかでどうしようもない問題もあるか…
ちゃんと見てなかったわ

イラッっとするのは、名前がつけれる処理をprivateメソッド化してない多機能メソッドだなぁ
20行越えるやつとか、保守時に機能の分析にかける時間がめんどくさくてしゃーない

"つけられる" を "つけれる" って書かれるとすっげーイラッつとするわ
「つけれる《ら抜き表現》」って出なかったか？

>>290
もうすでに人口に膾炙してる言い回しを、いちいち指摘する奴にいらつくわ

ら抜き言葉を使う奴はあんまり見ないな
日雇いのバイトとか清掃婦とかが口にするけど
深く関わろうとも思わん

>290
『つけられる』だと『つけることが可能』と『つけられてしまう』の2種類の解釈が可能で紛らわしいから、
ら抜き言葉で使い分けるのは言葉の進化だとする主張もあるぞ。

言い訳に必死だな

イラッつとする日本語スタイルのスレはここでつか？

コメントの日本語がおかしいとすごく気になるよな
特定のテクニカルタームに複数の訳語とか

SCSI インターフェース
TCP プロトコル
COBOL 言語
DLL ライブラリー

VB6厨はどうにかしたほうがいいのかと思う。
Boolean型変数Hogeで
If Hoge = False Then Hoge = True
こんなIf文があると書いたやつを小一時間問い詰めたくなる。

それjavaにもいますから。

いますから・・・。

頼むからこんな低レベルなことコードレビューで指摘させんな

>>299
javaでBoolean(先頭大文字)ならnullも取り得ることお忘れ無く。

お忘れ無く。 （ｷﾘｯ
じゃねーよｗ
それはそれで突っ込みどころ満載だわｗ

>>297
頭字語の元になった単語と重複するからと
名詞を分解したがる奴を思い出した
NEC社製はNE社製になるんかいといじったら収まったが

>>302
こういうふうに的確な突っ込みをくれるといいのだが
たいていは「なんとなく」「いままでそうだったから」

だから、イラッつとされようがなんだろうが俺は沈黙しない

ターミナル駅

Kinkakuji Temple
Biwako Ohashi Bridge
Inawashiroko Lake

標識にはよくこう書いてあるよね

〜寺、〜橋、〜湖までを含めて固有名詞扱いなのかな

ちょっと亀なうえに流れを読まずに恐縮だが、
ら抜き言葉が発生する理由の学術的説明らしきものが
「日本人の知らない日本語」の２巻で説明されていた

説明のところはやや文字が多いが基本漫画なので
読んでみてもらいたい

ステマとか言うヤツは無視してリンク貼れや
でもアフィリエイトは勘弁な！

>>283



バケツウラン方式
＝「あとで問題が発生する可能性も確率論的になくはないかもしれないけれど、とりあえず早いからやっちゃえ」

>>302
NEC製でよくね

ＴＷＯ＝＝じゃねえけどよぉ
比較する方をＩＦ文で最初にもってくる奴ってまじいらつく
俺はそんなコードを引き継いでも絶対同じにしねーからな
後任者が困る？んなの関係ねー！！

>>67
遅レスだが、true/false は件の環境では実装されているようだぞ？
case: true だの case: false だの書いてるから。

このコードが悪い点は、
a == 1 が成立したか否かを見るのではなく、a == 1 が「成立『しなかったどうか』のブール値を見る」という、
かなり後でメンテする人間にやさしくない書き方をしていること。

このケースだと、case 文中の true と false をひっくり返して switch (a == 1) と書き換えたらすごくわかりやすくなる。
さらに進んで、
case 1:
default:
のように書けば switch (a) と書いたり、if 文に書き換えれば良し。というかそう書くべき。

>>264
その書き方は古い。そんなのはコンパイラに「if 文中に代入があるけどおｋ？」言わせればいい。
言わないコンパイラを使ってる？捨ててしまえ。

>>268
if (str.equals("Hoge")) {
じゃないの？

>>306
その通り

>>313

str.equals("Hoge") はstrのnullチェックに一手間要るのよ。

>>314
待たれよ。
ということは、その str はどこの馬の骨か分からんメソッドから渡された引数なのか？
ならば呼ばれた時に null チェック。
自分が呼んだメソッドが null を返すかもしれない、というなら即座に null チェック。

信用できないやつから呼ばれた、もしくは信用できないやつを呼んだ、でなければ基本的に null チェックは不要だと思う。
しかもそのチェックをやり過ごすためにコードスタイルがおかしくなっては元も子もない。

引数のnullチェックをするかどうかは、nullを許容する仕様なのかどうかによるだろうが。

javaの悪習の一つだし、文字列リテラルを左においてequalsは使わないな
見た目がイマイチってのもあるけれど、
一番の理由は、それはnullがあるケースを想定してそうしたのか
本来はnullである事はバグなのに、それを無視して動作するように書いてる
(もしくは単に何も考えてないのか)が、コード上からだけでは判断つかないから、基本的にやらない

nullが来ることも想定してるのなら、コード一目見てすぐわかるよう、
nullのチェックはnullのチェックでちゃんと明確にわかるようにコード書くわ

コメントでも事足りるけど、コメントは保守されないことが多いし、
コードで表現できる情報ならそれはコードで表現したほうが確実

>>316
よるが、でも if 文内で逃げるようにはしないのが普通。
引数を受け取った直後にチェックするか、戻り値が帰ってきた直後にチェックする。

>>317
まさしくその通り。
素晴らしいレスだ。

チェックする理由がある箇所でチェックすればいいだろ？
nullを許容するのであれば当然nullチェックは記述しないが、
それで意図がわからないとするならどう書くんだ？

例えばこんな処理で、

foo.f( bar.g() );

bar.g()の返値がnullの可能性があってfoo.f()がnullを許容する場合でも
こんな風に書くのか？

G g = bar.g();
if ( g == null ) {
　foo.f( g );
} else {
　foo.f( g );
}

>>319
話の本筋には関係ないが、こういうのはこう書きたい
if (条件) 処理Ａ;
else 処理Ｂ;

ただし
・条件は静的でＡＢともにワンフレーズ
または
・条件で関数を呼ぶが、ＡＢでは代入のみ
な場合だけ（デバッグ作業対策）

if 文でブレス省く記述はｲﾗｯとくるスタイルの筆頭だな。

”縦長の”五行を二行で済ませるんだからいいだろ

省くなら全部省いて欲しい。

見たらイラッつとするだろうがｗ

>>320
いらん括弧は省く派だけど、
インデントするのが標準じゃないかなぁ

if (条件)
　　処理Ａ;
else
　　処理Ｂ;

でもガード節だけはこう書く

if (条件) return;

>>322
>>324
要は自分が最初に書くときの都合しか考えてないってことだろ。
だから、メンテのために後からいじる人がｲﾗｯとする。

>>325
そのためにコーディング規約を作るんだろ。
括弧の有無くらいIDEのオートフォーマットがあれば困ることもないけどなー

>>326
>コーディング規約

この人は何を言い出すのん。
スレタイを見てないのか見ても意味が理解できないのか、
あるいは、額面通りの言葉から演繹して考える思考力が無いのか。

>>324
自分も同じだ

>>320
デバッグ用途ならコードレビューでも無視するよ
ただし、それがコード上で明確に表現されている場合に限るけど
たとえばC言語なら、#ifdef DEBUG .... #endif で囲むべき

String data = null;
data = xxx.getXXX();

その宣言時のnullはなんなのかと
初期化がないならまだ許せるが...

>>329
null どころか "" やら new String() で初期化してるやつもいたぞ
そいつはクラス型は全部
AAA aaa = new AAA();
aaa = bbb.getAAA();
みたいにしてやがった

C#だと初期化しないとビルド時にVSに怒られるんでやってます・・・

>>331
宣言時に値が決められるのなら宣言と同時に入れておけ

宣言時に明らかにダミーと分かる奴で初期化されてるのはちょっとイラッつとした。

$userId = "user_id";

みたいな

このスレで分った事
慣れとか見た目でコーディングスタイルを決めちゃう人は言い分けが上手い

>>330
あるある過ぎて泣けるわ

>>329
String data = null;
と
data = xxx.getXXX();
の間にコードが入れられた時のための予防策

try catch のせいで宣言と同時に初期化できないこともある。
Java7のtry-with-resourcesでマシになったんだけど、Java7を使わせてもらえねー。

If Hoge = 1 Then
・・・
ElseIf Hoge = 2 Then
・・・

orz

>>336
String data = xxx.getXXX();

入れられようが無いよね

javaではやらない(どうせフォーマッターが保管してくれる)けど、
別の言語で{}の省略は割と多様しちゃってる
使うのは、基本的に処理が増えるようなところじゃないから、問題になることはないんだけど
やっぱ直さないとだよなー…

変数名の長さがアレで、フォーマット後の折り返し位置に納得がいかない場合とかに
宣言と代入を分けることあるな。でもその場合は無駄な初期化はしない。
まぁ、基本的には宣言と代入は同時にやるけどな

>>337
それなー
java7どころかいまだにjava5のプロジェクトとかあってハゲそう
interfaceの実装に@Overrideつけるとコンパイルできないとかないわ…

最近職場で見るイラっとするコーディングスタイル

if( test==test ){
　　hoge();
}
else{
　　hage();
}

式の前後に入ってるホワイトスペースとか、
ifのあと中括弧の前のホワイトスペースがないあたりが落ち着かないけど
そんなことより else 前後、ほかはまだ我慢できるが、テメーはだめだ！

ただの好みの問題だな。

if elseif else 辺りのそれぞれの条件にコメント入れようとすると
地味にどう書くか悩むｗ

>>341
わかるｗｗｗ

if (expr) {
　　;
} else {
　　;
}

こっちが好きだけど
else if だとこうしちゃうな・・・変かな？

if (expr) {
　　;
}
else if (expr) {
　　;
}

elseで改行しないメリットがわからんのだが
コメントも入れづらいし、処理の括りが分かり辛いだろ

おれは、こういうのでイラッつ

if[TAB](条件){[TAB][TAB][TAB]//コメント
処理
}



>>341
何べん見ても笑えるｗ

>>341
else以下が不要になったときコメント化しやすいとか
IDEの機能使ってコメント化している人ってそういう書き方する
のを見かける。

>>346
こう消せばいいだろ

if( test==test ){
　　hoge();
//} else{
//　　hage();
}

>>344
うーん・・・たぶんメリットはないな・・・ｗ
K&R or BSDのスタイルに見慣れてるからってのが大きいかな。

>>346
そういう、コメント化されたコードが残ってるのを見るとイラットする。

>>347
場合によったら ifの ｝ 探しで疲れそうだからそれはやめて欲しいｗ

>>350
エディタやIDE に探させればよい。

うちのエディタはコメント内の { } もカウントしてしまうから
// if (oldCondition) {
if (currentCondition) {
というようなありふれたコメントアウトで対応が取れなくなってイラっつ。

>>341
そのイラっとするスタイルは昔(1980年代)から目にしていたよ
おそらくは当時のC入門書であった「はじめてのC」の影響が大きかった
当時はUNIXワークステーション全盛時代でアプリ開発に大量の新人が投入された
その部署で使われたテキストが「はじめてのC」だった

自分がいたのは通信ドライバ部門だったので「プログラム言語C(K&R本)」だけどね
新人の立ち上げには苦労するけど、最初からK&R本で学ぶことは正解だと思う
「三つ子の魂 百までも」と言われるように、最初に出会った本の出来不出来によって
コーディングスタイルにおける感性(美的感覚)の基礎レベルが決定される

ブロックのブレースを条件と同じ行に置く奴は
何が嬉しいのかよく判らん。対応が見づらいし
ちょっとしたコメントあうともだるい。
そんに1〜2バイトが惜しいのか。

//if( x )
{
}
//else
{
}

バイト数が惜しいんじゃなくて行数が惜しい。

郷に従ってるよ
郷の方が統一されてないことがほとんどだが、その時は好きに書く

>>353
予約語 if の後に空白が無く小カッコの両内側に空白を入れるスタイルにイラっとする
　X: if( x )　　O: if (x)
これを含めて、ブロックのブレースを条件と同じ行に置くのは、
書籍「プログラミング言語C」(K&R本)に沿ったスタイルだからというのが理由
このK&R流儀は1980年代から続く古典的なスタイルだ
もちろんスタイルは(明確な理由があれば)時代と伴に変化があるものかもしれない
でも、わざわざその伝統を捨てる理由が(少なくとも自分には)見当たらない

a=10*-*n+(p+v)
が読みづらい

a = 10 * -*n + ( p + v )
なので式に空白を入れるようになる

if( ( p + v ) > 0 )
式に空白を入れるようになると一貫性があるので
丸カッコの中に空白を入れるのが当たり前になる

if ( ( p + v ) > 0 )
既にカッコに空白が入っているので
制御文の直後に空白が入ってんのが気持ち悪くなる
また、単行演算子はくっつけるので
ifを単行演算子と見なせば一貫しているように見え自然になる

>>356
そういうのを見ると、ああ、この人はちゃんと勉強してないんだな。
フリーソフトのソースも見ていないんだなって思うね。
あ、でもGNUスタイル。てめーはだめだｗ

>>357
単項演算子？

>>357
>a = 10 * -*n + ( p + v )
>なので式に空白を入れるようになる
a = 10 * -*n + (p + v)
で十分なので
>式に空白を入れるようになると一貫性があるので
>丸カッコの中に空白を入れるのが当たり前になる
はおかしい。

>>359
　-( p + v )
　if( p + v )
　 !( p == v )
while( p == v )

>>359
if や while といった予約語は「文(statement)」を構成する要素であるにもかかわらず、
それを単項演算子に見えるのが変だということじゃないのかと

以下のような例ならOKだと思うけど

a = c ? x : y;　　/* ? と : はC言語の三項演算子 */

a = if c then x else y　　# Rubyだと if は式を構成する要素

うろおぼえごみん
bool b = (a > 100) ? false : true;
刺したくなった。

PEP８に「括弧の内側に空白入れる奴はバカ」って書いてあったから入れないことにした

ifの後ろに空白は入れないな。

でも、今の仕事でEclipse使ってて、自動成型で空白入るから
最近はどっちでも違和感無く書けるようになってきた。

if /*(p+v)*/ (p-v) {}

みたいに書く気があるなら空白入れるのもいいのかもｗ

a = if c then x else y

と

if c then a = x else a = y

これを見比べればわかるように、

三項演算子に代入は必須でないことに気づいてチョット賢くなった気分
条件付きビット処理とかやりたい放題

やめろｗ
何のための「三」項なんだよ

>>362のRubyコードに間違いがあったので訂正

X: a = if c then x else y
O: a = if c then x else y end

まあ、MLやHaskellみたいな関数型言語であれば後ろのendは書かないんだけどね....

>>368
いいじゃんべつに

condition ? bits &= FLGA : bits &= FLGB;

三項演算子自体をやめてくれ
1行ifでいいだろ

>356
＜書籍「プログラミング言語C」(K&R本)に沿ったスタイルだからというのが理由

その本でそのコーディングスタイルを採用した理由は明記されてるの？
明記されていなければ、単にたまたま最初に読んだ本がそうだったから、というだけで最近の本で勉強した人と変わらないと思うけど。

>>370
イラッｗ
せめてこうしてくれ。

bits &= condition ? FLGA : FLGB;

>>372
書いてたかは覚えていないが、予約後のあとに空白を入れるのは
関数の呼び出し箇所をgrepを探せるようにするためって、
昔おっさんに教えて貰った。まぁそんな俺ももうおっさんだがｗ

最近はIDEが色々やってくれるから、今じゃ紳士のたしなみって感じかねぇ。

>>373
例だと両方&=だったけれど、片方|=とか<<とかだとどうしても三項演算子を使いたくなる

「今の子供たちは、国語でこういう書き方はまちがいだと教えられるらしい。」

「これが、いまどきの子供が仕込まれる正しい書き方だそうだ」


わかるか？

議論に参加できるほどコーディングスタイルにポリシーがあるわけじゃないが、
「間違い」ってスタイルがあるんなら教えて欲しい。

先生から教わることは絶対だろ
教わっていない漢字を使うのは間違いだし

>>372
理由は書かれていなハズだよ
でも他の本との決定的な違いは、「プログラミング言語C」が
C言語の設計者自身の手によって書かれた書籍であるということ
（通称の「K&R本」のKとRは著者(=C言語設計者)のイニシャルに由来する）
C言語を誰よりも知り尽くした人によって書かれた本であり、
それゆえK&R本はC言語の原典(バイブル)であると言われている

また、C言語がANSI規格化されるまでの間、
このK&R本がC言語仕様に関する業界標準であったことも付け加えておく

VisualBasicはIDEの整形機能が強力だからおおむね誰が書いても同じスタイルになる。

>>379
字句解析がしょぼかったからでないかな？

if( 10 > b ){}
F( 5, 10 > b );
*( p + 1 );

やっぱif ()は無いで

Code Searchさんに聞いてみたぞ

if (
http://code.google.com/searchframe#search/&q=if\s%2B\%28&type=cs
6,610,000 件

if(
http://code.google.com/searchframe#search/&q=if\%28&type=cs
1,580,000 件

if (　　のほうが多数派であることがわかると同時に、
if(　　 のほうも相当数存在することもわかるな。

まあ、ifでかっこを省略できるなら、if ( とかかせる意味もあんだろうけど。
言語仕様の穴をコーディングスタイルで隠そうとするのはチョットひどいかなぁ。

>>378
触っちゃいけない人だったんだね。やっぱりROMに戻ります。

>379
同じ理論で、Rubyのコーディングスタイルはまつもとゆきひろ氏の書き方が絶対的に正しいと思う？
俺は思わないな。

学習初期に、先人のスタイルを模倣するのはいいことだと思うよ。
でも、ある程度習得できてからは、自分なりのスタイルを確立することのほうが大事だと思う。

組織に参加してプログラミングするとき、その組織ですでに運用されているコーディングスタイルがあるなら、
一般論よりも、すでに運用されているスタイルに準拠するべきだということは異論ないよね？
だったら、自分一人のプログラミングだったら、自分にとっていちばん見やすいスタイルで書くのが正しいと思うよ。
ただし、ファイルごとに書き方がブレるようでは無意味。『自分なりのスタイル』が統一されていれば、ってことね。

言語開発者はたしかに最初のうちはもっとも言語に精通している人物だろうけど、
プログラム言語は使っているうちに洗練されていくものでしょう？
かつてベストだったものが今でもベストだとは限らないよ。
それに、画面サイズだけでいっても、C言語が開発された当時と現在では、1画面に映せる文字数がまるで違うでしょう。
デバイスの進化を追いかけようとしないのはやはり間違ってると思う。

>>383
google code でコード検索できるんだな。
プロジェクトの検索方法は解るがコードの検索方法がわかんね。

デバイスの進化つーても、画面の広さは限られているでしょ
DPIがいくら高くなったところで、文字の大きさはある程度ないとつらいから、表示できる文字数は限られてくる
diff見ることも考えれば、横に２つ並べても支障がないくらいに押さえて欲しい
いつでもデュアルディスプレイやら２７インチやら使えるわけじゃないんだから、横に長いコードは嫌だよ

そして縦にやたら長い関数/メソッドは下手くその書くものってのは今でも変わらんわけで

インターフェースとして機能してるわけでもなく
一度しか呼ばれない関数もいらっとするけどな。
よく有るのがInitialize()とかMakeToolMenuXxxx();
コメントで/*初期化処理*/とか/* ツールメニューXxxx */作成で十分

関数が長くなり過ぎないように処理単位で分けてるだけだろ
任天堂のソースなんてアセンブラですら数行で終わるサブルーチンだらけだ

何の意味があるんだ？

a(){}
b(){}

void f(){ a();b(); }

↑を↓で書いたって変わらんだろ

void f()
{
　/********* a *********/
　{
　}
　/********* b *********/
　{
　}
}

>>388
http://code.google.com/searchframe

>>392
コメントを書かずに言語の文法で意味を
記述するようにするのが最近の流行りだよ。
「Clean Code」とか「リファクタリング」を読むといい。

読むといい、と言ってみんなが読むなら苦労しない。

元々コード要素として現れるべきではないものが
関数として現れてるのがウザいんだけど

>>390
関数として仕様を決めることができる。

>>397
何の意味があるのか？

経験則として1つの関数の1箇所しか呼ばれない関数を作る奴は
OOPLの使い方やモジュール化が下手な事が多い。
まぁ、Cで例外処理用に関数を分離してる奴はそれなりに技量が有ったりするが。
それ以外の奴は論理的じゃなく感覚的にコードを書きやがる。

>>392
一度書いたら二度と修正しないほど完成度が高い設計だったら問題はないんだがな
たいていは後でaとbの間やa、bの中に元のa、bの切り分けになじまないコードを追加したりする

それを禁じるために上の書き方をするんだよ

>>398
「仕様通りに書いてね」
「仕様を満たしてるかテストしてね」
って言えるじゃん。

例えば、プログラム起動時に起動オプションと設定ファイルの内容を調べてメモリ上に展開するような
処理は一回しか行われないからmainにべた書きしてもいいかもしれないが、そういうのは初期化関数
として作るのが好みだなぁ。

>>400
むしろ上の方が柔らかい実装の時に困るでしょ
ちょっとした変更のたびに関数のシンボルが増えたり消えたりする

>>401
本来ひとかたまりのものを分割してんだからテストしづらいじゃん
そもそも再利用可能な単位に関数を分割していけば
一度しか呼ばない関数の大きさは呼び出し元に吸収できるぐらい小さくなって
テストの大半は再利用可能な単位に下ろせる筈でしょ

>>403
柔らかい実装って、単に設計がフニャフニャだだけじゃん。

> そもそも再利用可能な単位に関数を分割していけば
> 一度しか呼ばない関数の大きさは呼び出し元に吸収できるぐらい小さくなって
そんなことないよ。
一カ所からしか呼ばれないけど、中で複雑な処理をする関数なんていくらでもある。

>>404
仕様変更があれば結構有るよ。
ボタンが増えたり減ったりとか。
そういう所は固い設計は難しいから柔らかい関数や柔らかいクラスにカプセル化するね。

>>405
具体的にどんな？

>>392
それは「aを行ってbを行う」と"読む"
確かに前者はコード量は増えたし行数も増えたし最終的なルーチン呼び出し回数も増えた（ベタ書きのほうが僅かに確実に高速）

しかし、名前がつけられている
「変数/定数として切り出して名前をつけるとコードの流れが読みやすい」のルーチン版
クラスやメソッドのある言語だとこの「メソッド細分化と再命名」によるリファクタリングが最近は頻繁に行なわれているが、
そうじゃない言語だと見栄えが絶妙に面倒だな

>>406
物理シミュレータの場合、メモリ領域の確保などのソフト起動に必要な処理をコンストラクタに任せて
物理パラメータの設定や相互連携、間接インスタンス生成をInitialize()関数に任せてしまう、とか

>>407
逆にリファクタリングしづらいでしょ
本当に処理が独立してるなら再利用できる訳だし
リファクタリングすればどんどん再利用可能な処理が抜けていって
一度しか必要ない処理はどんどん小さくなっていくでしょ。

>>408
その処理は本当に1プロジェクトに依存してる処理だけなの？
XMLに吐き出しておけば十分とか、切り抜けば他のプロジェクトで
再利用可能な処理が殆どで本当にプロジェクトに依存してるのは極一部でしょ。

>>407
「書くのが若干めんどい」「見掛けが若干キモい気がする」と「読み下しやすくて間違いにくい」とのトレードオフだからなあ
わかりにくいような処理に対してピンポイントに使わないとお釣り出ないよね

> 本当に処理が独立してるなら再利用できる訳だし
この辺が空論だな。
独立してることと、再利用可能であることは別だし、
再利用できるように独立させても、誰も使わないことはよくある。

>>409
一概には言えんが
コメントを書かないとわからんような処理なら
メソッドの抽出はすべきだろう。

参照が一つしかない関数を作るななんて言ったら
main()は何千行にもなってしまうぞ。

>>411
誰も使わなくても再利用可な状態にしておくほうが
人間の感覚で分割するよりマシだよ。テストも作りやすいし。

>>413
その再利用可能っていう基準もお前の感覚でしかないじゃん。

>>412
Unixのソース見てりゃ数百行程度は別に構わないと思える。
他から操作されてる可能性考える必要なくてメンテしやすいし。

1プロジェクト中で1回って話じゃなく他でも再利用できない部分って話だよ。
例えばこういうのはあり。

//一度しか使わないExample
class Example:public TextFormat
{
// プロジェクト依存処理
};

Example examle( コンテキスト情報 );
Label label( &example );// TextFormatは自分で用意してねなライブラリ

>>414
再利用できる以上感覚じゃないじゃん。
できるできないがはっきりしてるなら感覚じゃないでしょ。
再利用できないコードをある人が書いて、
他の人が使うとある日突然再利用可能になったりする？

>416
そこまで徹底的に『再利用できない』と断言できる処理ってどんなの？

(>417の続き)
ふつうプログラム中で1ヶ所からしか呼ばない関数って『再利用しようとすればできるけど、現状では再利用の必要がない』ってものじゃない？
『絶対に再利用できない』って断言できるんなら、たしかに関数化する意味はないけど、
再利用しようとすればできるなら、『ここからここまでのソースがひとかたまり』という部分は関数化しておくべきだと思うよ。

>>417
処理というか関数。イベントで呼ばれたりするわけでもなく
main関数から呼ばれるだけなのにプロジェクト依存のコード
たっぷりねじ込んでInitializeとか大雑把に切り抜いてる関数。
〜MakeProcessとかとりあえず関数が長くなったので抜き出しました系。
リファクタリングすればたいてい再利用部分と呼び出し元に分解できるヤツ。

メンテ考えるなら、関数にわけるなぁ。一人でメンテするならどうとでもなるけど、
他人にメンテさせる場合関数でわけとかないとaの処理とbの処理が密結合しそうで嫌。
関数にわけたところで絶対に密結合が避けられるわけじゃないけど、
「ここは処理をわけてるんだぞ」ってのを明示する意味で関数にくくりだす。

そもそも密結合なものを見かけだけバラしてるから再利用できないんじゃないの？

あと、例えばInitialize関数なら、とりあえずInitializeのことだけ考えればいいので頭が楽というのもある。

再利用不可能な部分、プロジェクト依存な部分は極力小ぢんまりと
一箇所に収まっててくれてた方がいいよ。そこだけ書き換えれば大雑把な変更はそこで収まる。

>>419
そこまで再利用性に拘る必要性を感じないかな。
始めから再利用前提のライブラリを組むなら別だけど、
リファクタリングの結果出てきたようなものはどうせ再利用されないし。

>>422
これならブロックの中だけ考えれば十分でしょ
ただ、このブロックの範囲なんて業務が変わるたびに
ぐちゃぐちゃ変わるわけだけど。

/****** Initialize *****/
{
}
/****** Uninitialize ******/
{
}

> ただ、このブロックの範囲なんて業務が変わるたびに
> ぐちゃぐちゃ変わるわけだけど。
ダメじゃん

>>424
リファクタリングすればする程再利用性の低い部分は局所化するでしょ。
iniline化機能とか大活躍。

>>426
だから関数にするのが間違ってるんじゃん。
頻繁に変わるような部分は局所的なクラスや関数に封じ込めといたほうが楽だよ。

>>415
> Unixのソース見てりゃ数百行程度は別に構わないと思える。
いいわけねーだろ。大丈夫か。
gitのソースだって93%が70行以下、うち75%が30行以下だ。

> class Example:public TextFormat
基準が全然わからんぞ、
そんな一時的な継承の方が余計に判りにくくないか？

>>429
単に70行以下に収まってるだけでしょ。それに7%は70行超えてるんでしょ。
局所化した部分は長くなるっていい例じゃん。

あと、linuxのvnsprintfの例。
http://code.google.com/searchframe#3C3saXwSWsQ/trunk/linux-2.6.24.3/lib/vsprintf.c&q=lang:%5Ec$%20function:snprintf&type=cs&l=376

200行近いけど蜜結合してる部分は1つの関数に納めてる。

>>429
クラス部分に関しては避けようが無いから仕方ないという話。
それから同じプロジェクト内なら完全に再利用不可能なわけじゃないし。

読み直してるとちょくちょく誤解を与えるレスしてたような気がする。

ここでの再利用不可な関数の定義
・一つのプロジェクト内でも共有不可
・プロジェクト間で共有不可

プロジェクト固有の処理を1個の関数内に全て納めろと読み取れる
レスが有ったら混乱してるだけなんで無視してね。

>>430
おいおい、それはパフォーマンスを重視して
保守性や可読性を犠牲にしてるところだぞ。
そんなやり方を全部にやってたら全体の7％じゃ済まなくなるんじゃないか？

switchだらだらはどうかと思うが
可読性さがってるか？

>>433
これ以上保守性挙げられるか？

>>427
埋め込む先の関数がある程度以上大きいとキャッシュ容量を圧迫してかえって遅くならないか？

一箇所からしか呼ばれないんだからキャッシュ化されても意味無いでしょ。
大体、1つの関数をキャッシュメモリに載り切らない量にするとなると
1000行以上の巨大関数になるよね。そんな関数を頻繁に呼ぶこと自体なくね。
仮に数百行の関数が有ったとしても全体の7%以下だし。

＞1000行以上の巨大関数になるよね。そんな関数を頻繁に呼ぶこと自体なくね。



ﾆﾔﾘ

>>436
200行前後とかなら気にする必要なくね？
標準ライブラリーですら200行超える関数使ってんだから

キャッシュには、その関数だけでなくほかのもんも入ってるでしょ
エレベーターにデブ（制限重量以内）が居たら他の客も迷惑でしょって話し

他のを含めて1000行以上って書いたんだけど。
64kbとかが主流の時代なんだから1000行なんて60分の1にもならんでしょ。
それに1度しか呼ばない関数をインライン展開する可能性もあるし、
インライン化しなかったらキャッシュひっくり返す可能性もあってそれはそれで効率が悪いじゃん。

×他のを含めて1000行以上って書いたんだけど。
○他の関数が乗っている事を踏まえて1000行以上って書いたんだけど。

大した問題じゃないけど1次キャッシュの命令用は32KBか

64kBだと原稿用紙80枚か
命令数は原稿用紙3枚で40として3200

合ってる？

命令が1バイト固定じゃないから考え方を変えろとしか・・・

話の流れで見易さとか感覚による部分に
明確な基準を作りたがらない辺りがやっぱり
プログラマーの集まるスレだと思ったｗ

キャッシュの話出てたけどよく考えたらC++やネイティブ向け言語処理系固有の話で
インタプリター系言語じゃインタプリター次第だから気にしても仕方ない話だよね。
それにC++やCに関しては処理系次第で必要があれば勝手に調整するし。
例えばVCはブロック{}使えば同じ関数内でもスタック調整するしね。

>>435
それこそ一度しか参照しないstatic関数に分割していけば
わかりやすく、かつ保守しやすくならないか？こんなイメージで。

static int init_context(&context, .......
static int reject_out_of_range(&context, ........
static int parse(&context, ........

int vsnprintf(char *buf, ...........
{
　　struct vsnp_context context;

　　init_context(&context, .......
　　reject_out_of_range(&context, ........
　　parse(&context, ........

　　......
}

実際やるとポインタのデリファレンスが増えるんで、
インラインで書いてるだけの話じゃないか？

だったらstatic inlineで

サッカーの説明をするのに
「味方側11人・敵側11人で行う、外周70cmで重量450gの球体を、人体の手以外の部分で1m以内の範囲で操作し、
時には味方に蹴り渡したりして、より多く敵側の一定領域へ蹴り込む競技」
と言うよりは
「11人vs11人で、ボールをドリブルしたりパスしたりしてより多くゴールを決めた方が勝つスポーツ」
にして、各単語の意味を別に定義しておいたほうが、自他の意思疎通の際に簡潔で分かりやすいし、「文章の」意味の理解で発生する齟齬も防げるじゃん

って話じゃないの？

>>324 括弧は必ずつけろ。これは命令だ。

命令じゃない構文の場合は不要なの?

return に括弧を付ける奴が実在する。
しかも return( 0 ); のようし、括弧との間に空白を付けずに。
聞いてみると関数のように見えるようにだと。return を呼び出してそこから戻ってきたら困るだろうに。

if と括弧の間の空白はどっちでもいいと思ってたが、これを思い出したので、今日から if の後ろに括弧を付けろこれは命令だ派になろうと思う。

逆に関数のシンボルと括弧の間に空白を置くやつも実在する。
これは常にというわけではなく、引数セットが同一の時に引数の桁を合わせようとしているのだが、括弧の後ろの空白で調整すればいいじゃん。

> if の後ろに括弧を付けろ
って何だ俺は。
括弧の前に空白を付けろだ。

>>448
linuxのコメントで説明してる方がましだナァ。
わざわざ流れを絶って他の関数見に行くのも面倒だし
その関数名でどの値が変更されるのかもわかりづらいし

【命名】　馬から落馬コード


foo = (cond) ? true : false;

>>387
>同じ理論で、Rubyのコーディングスタイルはまつもとゆきひろ氏の書き方が絶対的に正しいと思う？

絶対的かどうかは知らないが、現行のRubyのスタイルはまつもと氏の原典「オブジェクト指向
スクリプト言語Ruby」に沿ったものになっているのでは。もちろんRubyは表現力の豊かな言語であり、
原典出版当時からメタプログラミングや関数型言語風プログラミングなどの発展があった。
それでも原典にある改行やスペースの入れ方に従ったスタイルになっていると思う。

>一般論よりも、すでに運用されているスタイルに準拠するべきだということは異論ないよね？

もちろんだ。郷に入れば郷に従う。それがプロ(職業プログラマ)だと思っている。

>だったら、自分一人のプログラミングだったら、自分にとっていちばん見やすいスタイルで書くのが正しいと思うよ。

自分一人のプログラミングならば、自分なりの個性的なスタイルを追求するのは間違っていない。
でも、スレタイにあるイラッとするうんぬんというのは、集団での開発や外部へリリースするコードという、
書く人と読む人が別々の状況ではないのかな？その場合、個性的なスタイルは、他のメンバからすれば
一人よがりだったり自己満足のオナニーに映るよね。

>かつてベストだったものが今でもベストだとは限らないよ。

前にも書いたように(>>356)、わざわざK&R Cのスタイルを捨てる理由が見当たらないんだ。
少なくとも、if/while/for/returnの直後にカッコを置くスタイルは、関数と判別しづらくなる欠点がある。
これは文と式(関数)という言語設計の基本を理解していない、思いつきで生まれたスタイルだと言わざるをえない。
もしも明らかに可読性や保守性に優れたスタイルが提案されたなら、それを受け入れるよ。

>>455
んな事いってたらOOなんか使えないだろ。
メンバ変数がどのメソッドで変更されるのか全部把握するのか？

>>457
予約後が関数名と区別できないならマを辞めたほうがいいんじゃないか？

>>458
前スレでprivateなメンバー関数は極力static関数にしてメンバーを引き渡せってのが有ったね。
あれには同意する。

>>458
OOのと違って目的が決まったメンバーじゃなく
とりあえず分割して追い出すためだけに
寄せ集めた構造体なんで解りづらいっす
出来の悪いオブジェクトみたいな感じ

ちゃんと呼び出し元と独立してて再利用できるような形で整ってると読みやすいんだけどね

>>461=462
>>461の補足したつもりだけど>>461=462が解るようにレス番付けてなかった

>>461
分割前とどう違うんだ？
でかい関数の上の方に寄せ集めた変数の塊も判りにくいんじゃないか？

常にA-B-C-Dの順番で呼び出してくださいという関数があったら
使いづらくて仕方ない。いっそ一つの関数にまとめろよと思う
それと同じだな

>>465
途中にreturnやbreakを入れないで下さいという
長い関数があったら使いにくくないか？
gotoなんかも入ってるぜ？

>途中にreturnやbreakを入れないで下さいという
>長い関数があったら使いにくくないか？
どこから出てきた話だ？

>>465
外から使うための関数じゃないから。

もはやコーディングスタイルの話題から脱線している件について、

>>465
それだったらA,B,C,Dは非公開にして、A->B->C->Dの順に呼び出す公開関数Eを普通は作るだろ

>>465
open->read->closeも順に呼び出さないと使えないんだが…

>>468-470
隠すかどうかはどうでも良くて読みづらい編集しづらい
読むってのはライブラリとして利用させてもらってる立場の話じゃなく
隠したコードを編集する立場だからな
linuxのコードと見比べてみ

>>471
RAIIな形ならいいじゃん
あと、ある一点でしか想定してない関数とは違うでしょ

>>471
readとかwriteとかcloseとかハンドルが無効だったら戻り値とは言え
安全になるようエラー返してくれるよね。件の一度しか呼ばない関数も
安全に使えるようにチェック入れるの？

どう思う？


if ( !(....)) {}
↑
↓
if (!(...)) {}

>>473
そんなの当たり前だろ。意味のある入力と結果を返すように
しなければリファクタリングする意味がない。

あとファイルディスクリプタの番号は再利用されるから
いきなりcloseしてエラーになるとは限らないぞ。

>>475
そうか。やっぱ保守性悪いな。

多少大筋の変わる仕様変更があると、関数消して
新しい関数追加して引数コメント付けて
呼び出し元にもコメント付けて >>475 の様な人の場合なら
エラーチェックも追加して

もう一回別で使ってるんなら我慢も出来るコストじゃ有るんだけどねぇ

エラーチェックじゃなかった入力チェックだった

そんなに関数分割って解りやすい？
再利用のための必要悪でしょ？

わかりやすいこともあるしわかりにくいこともある
悪のこともあるし正義のこともある。

関数分割はただの道具だ。
正しく使えばいい結果をもたらすに決まってる。

>>477
大筋が変わるような時点で負けていることに気付け。

勝ちとか負けとかどうでもいいよ。
すごくどうでもいい話。

どっちみち先に進まないといけないんだからさ。

変更履歴をコメントで入れるヤツにイラッｗｗｗ

// 管理番号 xxxxxx ほげほげ 2012/08/14 田中 Start
if (hoge) {
　　hogehoge();
// 管理番号 xxxxxx ふがふが 2012/08/15 鈴木 Start
　　fugafuga();
} else {
// 管理番号 xxxxxx ほげほげ 2012/08/14 田中 End
　　piyopiyo();
}
// 管理番号 xxxxxx ふがふが 2012/08/15 鈴木 End

田中と鈴木で範囲被っててカオスｗｗｗ
svn使ってるんだからやめて・・・ｗ

>>483
結構大手が開発したソースでもそんなんだよね
Hとか

>>481
勝ちたかったの？君の勝ちでいいよ。

それはともかく、機能追加しただけで1つの関数の
内容が大きく変わることは割とよく有るね。
今まで読み込んだバイト数が必要になって関数の
数行ごとにカウントの式を追加したり。

他人に勝った負けたで生産性やら保守性やらが
上がるんならいくらでも勝った宣言するんだがな・・・

>>483
あるあるｗ
ソースには変更履歴書くくせに、コミットするときにコメントはろくに書かないとか。
何のためのバージョン管理システムなのかと……

>>483
ありすぎて困る
そして誰得になっていって、どこかのタイミングで誰かが消す作業を行う・・

消すと激怒するんだよなｗ

>>486
そこは「いくらでも負けを認めるんだがな」と言うんだよ
イラッとするぜw

修正履歴はヘッダと修正箇所に日付氏名を入れて記入すること
って普通大手では決まってるのよ

だから大手は軒並みソフトが弱いんだな。

>>479
分割されたものがきれいな範囲でまとまっていればわかりやすい。
そのように分割して外に追い出すことができれば、元の関数は手続き的凝集となり、あれもこれも一つの関数で行っていた状態よりは、いくらかはマシになる。
分割されたそれぞれの関数の凝集度もよくなる。
きれいに分割できた時にはね。

>>491
修正部分の上に別の修正がかぶさって２０年ちかく熟成されたカオスなコードを読まされる身にもなれっつーの

>>494
いやバグを作りこんだ下請けと担当者に死の鉄槌を加えるには必須です

鉄槌さえ下せればコード自体はどうなっても構わんとか、まさにクズの思想だな

>>495
バージョン管理システムも導入してないの？

バージョン管理は最初から固定メンバーや若干の入れ替わりなら有効だけど
頻繁に派遣や下請けが入れ替わる環境では返って邪魔なだけ

邪魔になる理由がわからない。。
バージョン管理システムも使えない派遣しか雇えてないところとか？

数人規模の零細に流れ流れてやってきたコードなら文句言うのもわかるが
大手は下請け別部門別担当者別でバグ発生率とかデグレ発生率とか普通に管理してるから
会社によっては壁に貼りだすところもある成績表みたいにな
そういうところではソース上に記入させるのは普通です

>>497
某大手メーカM菱電機では、一切使われていなかったなあ....
自分達の担当部分に関してはOS標準(HP-UX)のRCSでしのいだけど
派遣なのでシステム権限が無く、SVN/Gitは導入できなかったし

バグ管理システムも使ってないとか？

大手ほどExcelで管理とかソースに履歴とか原始的な方法使ってるよな。
ベンチャーなんかの新興企業の方が発想が新しい傾向がある。

そりゃ能なし飼っとく余裕なんてないからね

部分的に切り出して個々は協力会社Aにアウトソースしようとかあるか
10人とかで開発してるわけじゃないので外部のどの会社にもソースリポジトリ触れる状態にはしておけないでしょ

>>502
当然，使っていない
HだとB票/P票で採取してPCL消化/バグ発生曲線で管理するけど、類似のQA(品質保証)手法は見たことがなかった
あと、線表(工程管理表/ガントチャート)すら使われていなかった(工程会議は口頭説明のみ)
すべてにおいてプログラマ個人の力量に頼った開発だった
しかたないから、自分達はExcelで線表とバグ発生曲線を書いて自己管理していた
まあ、末端のコーダ扱いで投入されたから、そんなものかと気にしていなかったけど....

だから、
これ実行できないんですけど、どうやってテストするんですか？
っていう状態でソースがやってくるんだな。

ま、結局テストせずに納品するんだけどね。

あ、>>507は>>505へのレス。

>>505
逆に、外部の会社使ってるのにソース管理システム使わずにどうやって
管理しているのか興味ある。手作業でマージしてるとか？

プログラムって楽しいよな
でも、いま学生の人は間違ってもIT業界には就職するなよ

アウトソースって意味わかってるのか？
手取り足取りバグのとり方から品質管理までやってたら意味ないだろ
ほんと零細かお前らｗ？

>>509
横レスだけど、>>501のケースでは最終顧客との間に専用のネットワークがあって、
M菱側で結合テストを終えたコンポーネントのソース一式をtar.gzで固めてから
FTPで指定ディレクトリへアップロードしていた
そして客先の連動テスト環境化でバグが見つかれば、再度アーカイブをアップロード
おそらく最終顧客の担当者が手作業でマージしていると思われるw

最終的にはWordで書いたドキュメントと一緒にソースをMOで納品となる

>>498
情シス部門が無いなら(無いのも問題だが……)しょうがないかもしれないが、
普通派遣PGの入れ替わり程度なら即座にアカウント発行されているぞ。

それに、そんなに頻繁に得体の知れない奴が入れ替わるんだったら、正常に
動いていた状態に即座に戻せるようにバージョン管理システム必須じゃないの？

気持ち悪い！！！やめてくれ・・・・・・・・・・

foo(aaa + bbb,ccc - ddd,eee + fff);

>>514
foo(aaa() + bbb(),ccc() - ddd(),eee() + fff());
これはどう？

発射する・・・・・発射してまうで・・・・

>>514
そんな書き方されて、バグだされて、デバッグするとき物凄く苦労した覚えがある
あーそんな書き方してた奴、今どこでなにしてんだろ

ソース管理でコミットログとか残してるのに、不要処理をコメントアウトするのがｲﾗｯとする

メソッドのへの分割は、処理にコードレベルで名前をつけることでもあるしな
それと再利用とはまた目的が違うとおもうけどなー

コメントで処理を説明すればいいっていうのはわからなくはなし、やるけど、
コメントはフォーマッターとか効かないし、文体や書式の個人差が大きいから機械的に処理できないし
本人以外にうまく伝わらないような説明文かかれてたりすることもある
それに、コメントってコードじゃないから保守されないことが多くて、
嘘説明になってたりするのもよく見るから、長い処理ほど説明コメントは避けたい
コードで表現できることはコードで表現したい

まぁぶっちゃけ、イラッとするような冗長メソッドは基本的にコメントもついてないけどな…

未来の自分に、お前はまたこのコードを書くだろうがこのコードを書く必要はないんだ
って事を伝えるためにコメントアウトして残す事はたまーにある。

>>520
そりゃたんなる横着じゃないかｗ
ソース管理から過去のソース(どのリビジョンか調べる手間が要るが）ひっぱって
くるだけだろうに。

すべてのソースファイルの一行目に

//TAB4

うざ・・・

>>522
4^10000とかにでも書き換えたれや

誰も困らん
困るやつが悪い

コメントトラップって、詳細設計を後書きしてるようなプロジェクトに多い気がする

変更開始のコメントはあるのに、変更終了のコメントがなかったり
変更開始〜終了がいっぱい合って、それぞれがスパゲッティになってる状況とか
やめて欲しい。

てか紛らわしいのでむしろ要らない

1関数1000行単位で１ファイル1万行単位とかやってるからそうなる。
関数に切り出せる塊で、ブロックで治すんだったら、関数に
切り出せよとかマジで思う。

コーディングルール強制エディタって、ない？

行数が増えすぎた関数とか、スペルが怪しい命名とか、
リアルタイムで監視していて即画面を赤くしてその後作業を拒否るみたいなの

直せなくなるじゃんｗ

前回のセーブポイントまでもどるわけだな

スペルチェックは欲しい。略語辞典付きで。

それでも辞書に登録されちゃうと、Syainmei_NyuryokuInput()とか馬鹿な関数は撲滅できないんですけどね。
あ、でもSyanimeiとShainmeiの混在は減るのか

Romajiで打ち込むと、英単語の候補を表示してくれるとか、どう？

MS-IMEはカタカナから英語に変換できるよ

それがプログラミング環境で役にどう立つと？

VBで漢字変数でなくかっこいい英語変数を使える

知らない英単語使って、後で何の事か分からなくなる位なら、
最初から日本語で書けって。

それも仕方ないけど、その前にシソーラスを使おう。んで、検索ヒットの多いのを選ぼう。

コメントが関西弁
本人は東北出身

// なんでやねん

bool flg = (condi) ? true : false;//いらんがな

シソーラスもいいね
今まで英辞郎使ってたよ

public int hoge() { return bool値 ? 1 : 0; } // そのままbool値を返せバカ (Java)

//foo.cpp

#define False 0
#define True 1




なんでやねん

しかし、trueやfalseに変更しようとするとなぜかエラーが出るので
面倒くさくなって放置している

大した規模でもないのにいたるところにboolが氾濫して混乱するし、微妙なtypoがムカツク

#define T 1　// hogeh
#define true -1 // fuge.h
#define Ture 1　// fuga.h

ソースのコメントアウトの件は、発注元の役所なりの要求だから残さざるを得ない。
自社で開発して維持してるならともかく、年度契約とかで落札した案件じゃ、渡されるのは生ソースのみ、納入するのも生ソースのみ、一応コメントアウトが役に立つ場合も少しだけはあった。

10年以上次の状態のソースを何人も手を入れたソースをいじることになった…orz

・修正時はコメントにし、新たな記述追加
・なんでもグローバル変数で、あちこちからアクセス
・一番最初のコーディングスタイルがみんな嫌いだったのか、スタイルが統一されていない

みんな、その場さえしのいで逃げちゃったｗ

ちょっと日本語がおかしいですね

544の書くコメント文にイラっとする人は少なくないはず

>>544
おまいの日本語はアレだが内容については激しく同情する。

似たような状況のVB6ソースをC#に移植するプロジェクトに投入させられたのだが
どうやって逃げようか検討中だ。

別言語への移植だったら、表面上の動作だけ同じで、旧ソースは読みもしないってわけにはいかんかな？

それがいい
リファクタリングの名の下に好き放題やっちまえ

>>548
バグが有った時に元のソースを確認しやすいと言われる。
主に目Grep、日付フォルダバージョン管理システムが主流の
ところでよく言われる。

クソソースはもう読みたくないマジで
そんな俺は職業プロ失格なんだろうなきっと

>>548
細かいとこで相違点でまくりでフルボッコにされるわｗｗｗ

細かいところまで同じを望むのなら、システム変更する必要ないのに。
VB6のソフトの外面をC#で包むだけで検収通るかもしれないぞ。

相手方にはソースも渡しますorz

>>551

それでずっと通ってきたのなら、いい環境だったのだと思う。

最近そんなのばっかで、これで金をもらってるからしょうがないと思うようにしてるが、
実際他の派遣さんはすごく嫌がって、なるべく関わりあいになりたくないのがありありと分かる。

最近だと、機能修正で判定するロジックをちょっと変えるのに、（"<"を"<="に変更するレベル)
関数の追加は機能修正なので禁止とか言われて、いちいちその場で
全部コピペしまくって直してた。

１回目の修正は頑張ったけど、その後、それだと仕様に問題が
あるとわかって更に徹夜で修正させられたときはマジデ泣けた。

>>544
その手は結局自分の担当範囲だけ自分の分かるように作るのが一番だってオチに行き着くんだよね。

似たような処理があったらコピペするという発想が生まれるやつは全員しねばいいとおもう
共通化できるならユーティリティ的な処理として切り出せ、コピペするなよ
修正量が倍倍になっていくっつのアホか！！！！

っていう愚痴(´・ω・｀)

1個所のロジック使いまわすと、そこがダメになった時全部だめになるじゃないか！

と逆切れされたんだが、俺の1徹半目の頭では反論が思い浮かばなかった
てか言葉が思い浮かばなかった

皆さんは1行だけのif文ってカッコつけますか？
自分は何行だろうと付ける習慣がついてるんだが

昔読んだ本に1行でも修正で複数行になることがあるので最初から付けておいた方がいいと書いてあった
今は付けなくなったけどｗ

処理ブロックを見た目で明確にするためにも付ける派

>>558
一箇所だめになっても全体では大丈夫（結果に影響しない）ということは、
その箇所はそもそも不要だったってことにならない？

それから、ここはダメでもほかはＯＫということは、
そもそもそのダメになった箇所は他とは別の位置づけだったということで
それなら”その箇所に”使い回しをしたこと自体がおかしいでしょ

結論として、基本設計がタコでゲソ

その先輩の真意はわからんが、バグやなんかの修正で、そこに依存する部分が
多すぎると逆に大変、てのはあるな。
それも含めて、共通モジュールはそれを利用する側よりしっかりと設計・実装
する必要があるわけだが、同じような処理だからまとめてしまえ、ってのも
その意味では安易すぎるだろ。

>>563
おいおい、問題のあるコードを
百箇所に以上にコピペしちゃうのと、
一箇所にあるコードを百箇所で呼び出してるのと、
イザ実際に問題発生した場合どっちが収束早いと思う？
もちろんコピペ箇所の発見から始めるんだぜ。

>>564
問題のあるコードを残してる方が悪い。
100箇所コピペする前に修正しろよ。

似たような処理をまとめた共通処理は、
時間が立つと共通処理じゃなくなってくるのが問題。

まあ、たいていの場合
コード書く連中と、
数ヶ月後に不具合が発覚して修正する連中は
別の人なんだけどね

仕様レベルで同一な事を指しているかどうかが肝だな。

共通処理を基底クラスにまとめているようなプロジェクトには近寄りたくないな

え？ その為のモリタポイズムだろ？

古いソースコードをコメントアウトに#if 0 〜 #endif　使うのマジでやめて欲しい

>>571
統合環境使えよ

古いコードをコメントアウトって時点でｗｗｗ
残さずきっちり削除してしまえｗｗｗｗ

>>573
とあるメーカーのコードは、歴代機種の残骸が漏らさず残ってるぞ。
なんでって、それがそのメーカーの社内ルールだから、外部者もそれに従う。
おかげで有効なコードが全体の一割しか無いとか普通。

>>572
統合環境でも対応できないことが多々あるからなぁ。
灰色になってたから、コメントアウトされてるんだと思ってたら
実は生きていたとか。

>>575
そう言うのはステップ実行するしか無いなw

>>574
実はうちのも結構コメントが多かったりするｗ
フリーソフト駆使して数えてみたら有効なコードは六割だった。
バッサリ削除してぇ。

フリーソフトのコードがメーカー謹製のコードに入ってるわけ無いけどな。

突然何を言っているんだ?

: 　 |:　l　 　 |　 |:　　 /　 :|│　　　　　 | 　 l |　　 :| |　　　　　 　 　 　 　 | ＼__
: 　 |:　l　 　 |　 | 　 /| 　 :|│　　　　　 | 　 l |　　 :| |　　　　　 　 　 　 　 | 　'⌒）
: 　 |:　l:　__/|　 |: 　ｌ│　　│　　 　 ､ _|_,,...斗匕ﾞ∧|　　　 |　　　　　　　 |, ﾞ　 ∧
: 　 |:　| 　 |人｀T¬ト|--ﾍv|　　　　　　| 　 /| __/　 |　　　 |　　　　 　 　 ； 　 ハ
: : . |::八　:ﾙィ斧芋ﾐ∧　　│　　　 　 :ﾙイ斧芋弌ﾐ|_/|　　　　　 　 　 ﾄ :| 　！ |│
::::::::|::.　|〃　 ん::（,,ﾊ｀ヾ　八　　　　 〃　ん::（,,ﾊ　 }i　|　 ′　　　　　 |　|　　{　|│　｢バレなきゃ
::::::.八 _圦 　 {/{:::::j゜| 　 :　 　 丶　 /:　　{/{:::::j゜|　ﾉﾞ ﾘ / 　|　　{｢＼|│ l. 　 ｌＶ　　　　　　　　犯罪じゃないんですよ」
::::::::. 　 |　 　 乂＿ン　_: : ＼　＼∨ : : _ 乂＿ン ,　 /　　　'　　 | 　 Y|　|. 　 | ∨
::::: |＼八　　 ` ー…_彡　 　 ＼／＼　　`ー…_彡 /|/　　　　　 | 　 'ﾚ"⌒＼|乂＼
::::: |　 丶＼ ::::::::::.　　　　　　　　　　　 　 　.:::::::::.／　 ／/ 　 　 ﾘ 　/　 ヘ.　 ＼ ￣
　:::∨　　　 ＼＿_ 　 　 　 　 　 {　 　 　 　 　 ∠二イﾞ::/　:| 　 /　 　 /　　 ＼.　｝
　　::＼＼　　　 ＜＿_　　　　　　　　　　　　　　　　八/　　|　 ,ﾞ 　 ﾉ_,| 　 ヘ、　 〉
＼ 　:::|＼＼_＿＿_／　　　　　　　　　　　　　 　 .:':::/　 　 |／{ 　｛_ノ|　/　 　　 ﾊ
,'∧:＼|　　　ゝ .　　　　　　　 '⌒＾`　　　　 　 イ/:::/　　／//八　　　［〈　 r'-　 }∧
/,'∧　　　　　∨ ＞　　　　　　　　　 　 _ ＜///:::/　　　 ////ハ　／　ﾄ､ }　　/'/∧
//,'∧　　　　　∨///{≧o｡　 ..__,..　＜//////:::/　　　 /,'/////}/　　└ ´ ／'////〉

なにこの流れｗ

変数名とか関数名を変えたり関数の順番書き換えたりして使ってるわw

>>576
うちはエラーになるように書き換えて
コンパイルエラーが出るか試してたわｗ

自分が過去に書いたソースで、実際には再利用されることがありえない
オブジェクト指向の箇所は削除して回りたい

>>584
なんで？

今の現場の場合、予想ステップ数と実ステップ数を比較して、
進捗率を図るｗので、古いソースコードをコメントアウトしてる。

行数が減ると生産性がマイナス評価を食らう。
予定行数より足りないとわざわざループ開いて水増ししてる人もいるが、自分はコメントで水増しをしてる。

そんなんだからゴミみたいなコメントとコードが減らない。

そもそも、C言語で１ステップって１行なのかずっと疑問に思ってる。

「予想ステップ数」を出せるのがスゲーわ。

>>587
おれも馬鹿だと思うけど、コーディングとかしたことない人間が弾きだしてる。
毎回全く当たらないが、儀式のように見積もってる。

>>586
まだそんなとこあんのか
納品用ソースコードを生成するコード用意しとくと捗りそうね

>>588
見積もるだけならまだいいが実際とずれたときに原因分析までやるようになったら末期

やってるんならマシだと思うけどね。
プログラミングはできなくても管理のプロフェッショナルなんてのが
そういう役割してたりするし。

往々にして、管理のプロフェッショナルに合わせることが目的になってたりするけどな。

管理のプロフェッショナル様のお使いになられている情報は
現場が手間暇かけて作り上げています。
どうぞ有意義にご活用くださいませ。

まともな予実管理しないで数字合わせを強要するのは
そもそも「管理のプロフェッショナル」とは言えんだろう。

ここって管理スタイルスレだっけ？

そういう管理者がイラッつとするコーディングスタイルを生んでいるって話だろう
>586を見よ

報告する側も適当な辻褄合わせをするからそんな意味のない管理が
いつまでも続いているんだろう。管理者の側からはその管理方法で
プロジェクトがちゃんちゃんと進んでいるようにしか見えないからな。
似たような話がワインバーグの本に書いてあったはず。

>>593
まさにそれだｗｗｗｗ
このスレで初めて腹抱えて笑えた。

ちなみに品質向上でナゼナゼ分析もやってるんだけど、
ダレダレ分析になって犯人を挙げることに目的が変わってるから、儀式だよね〜

そして人はノイローゼになって、い亡くなり、根本原因にたどり着かず品質も向上しないし
見ててイラッとするコードになる。

>>598
だって馬鹿な顧客が月例会議で進捗率を要求するんだもの
月次報告書に載せる数字が要るんだもの

胃が痛くなる話ばかりだ
管理の奴らの分析って、諍いの原因創出とマの神経摩耗以外に価値あんのかねｗ

特にドラッカー敬愛してる奴らの要求の意味不明さが疑問だったので読んでみてるんだけど、
別に理不尽な事が書かれてる訳でも無くて尚更混乱する

＞ちなみに品質向上でナゼナゼ分析もやってるんだけど、
＞ダレダレ分析になって犯人を挙げることに

元請けのデバッグ屋が馬鹿なせいなのか、陰謀なのかわからないけど
リリース前の不具合が孫受けの俺のせいにされそうです！w

古いコメントも重要な情報なので消さないで残しましょうと言われたorz

// del // とか
/* 以下削除コメント */ とか

禿げそう…

//の形式ならまだ許せるが
/*〜*/の形式でそれをやられると殺意がわく

>>603
まさにソレ
grepしただけだとわからないという…

>>600
管理の奴らの分析って、最初に理屈が通るストーリーを作って、
そのストーリーに当てはまる原因を「考えている」
ストーリー上で説明の付かない原因は「認めない」

コーディング規約に、
コメントは /*...*/ のみ。 // ... 禁止。
ってのがあって萎えた。

C言語ならわりと普通。

>>605
ああ、なんか凄く納得
それを防ぐ効果的な方法論書いてる本でもないかなｗ
ジュンクあたりでゆっくり立ち読みしてくるわ

>>606
コメントの内容でコンパイラがエラー吐いたりする事あるから・・・

いまだにC99未対応(コメントだけすら)のコンパイラ使ってるところあるんだな
てか、コンパイラが対応してるのにデフォのオプション設定が未対応になってて、それを変更してないからエラーとかってところもあったなｗ

C99対応のコンパイラでC99としてコンパイルするんならいいんだけどね。
言語としては未対応なのに、コンパイラが対応してるからという理由では
//コメントは使えない。

でも動くし

最近のコンパイラならC++形式のコメントを許可するとかってチェックあるよな

みんな使えるんだけど、移植性のため規約はC89どまりってのはあるな。うちだけど。

実際に//が使えないコンパイラに移植する機会はあるの？

<table>
<% If isAdmin Then %>
　<tr>
　　<td>管理者：<%= rs.("USERNAME") %></td>
　　<td>ユーザID：<%= rs.("USERID") %></td>
　　<td>所属：<%= rs.("DIVISION") %></td>
　</tr>
<% Else %>
　<tr>
　　<td>登録者：<%= rs.("USERNAME") %></td>
　　<td>ユーザID：<%= rs.("USERID") %></td>
　　<td>所属：<%= rs.("DIVISION") %></td>
　</tr>
<% End If %>
</table>

×　rs.("USERNAME")
○　rs.Item("USERNAME")

>>616間違えたorz

ははっVBとASP.NETか
rs(foo)とかユーザコントロール作ってバインドしろという話し?

管理者と登録者にラベル使えってことか

どういう経緯でこうなったんw

<table>
　<tr>
　　<td><% If isAdmin Then %>管理者：<% Else %>登録者：<%= rs.("USERNAME") %></td>
　　<td>ユーザID：<%= rs.("USERID") %></td>
　　<td>所属：<%= rs.("DIVISION") %></td>
　</tr>
</table>

せめてこうしてくれ

あ End If 忘れた　どうでもいいけど

少しも問題の本質にかすってねえしｗｗｗｗｗｗｗｗｗｗｗｗ

これ問題の本質なるものが介在してるとですか。すまんわからんw
vbつーか.netよう知らんけど

VBもHTMLに埋め込むことができたのか
PHPではなさそうだし何のタグかと思った

知らない言語だとどうもピンと来ないな。
俺も最初は>>616みたいに書いて、使い慣れた１週間後くらいに書き直す気がするｗ

>>620みたいに複数の節を一行にまとめられると見にくいから

<table>
　<tr>
　　<td>
　　　<% If isAdmin Then %>
　　　　管理者：
　　　<% Else %>
　　　　登録者：
　　　<% End If %>
　　　<%= rs.("USERNAME") %>
　　</td>
　　<td>ユーザID：<%= rs.("USERID") %></td>
　　<td>所属：<%= rs.("DIVISION") %></td>
　</tr>
</table>
こんなかんじかな

HLTMLの構造を維持しつつ埋め込みという意味で
>>626より>>620の方が俺には解析しやすい。

HTML(+埋め込み言語)の場合、あとで非プログラマのデザイナーがメンテナンスすることを考えて、
行数削減よりもとにかく可読性を高めたほうが正しいと思う。
だから>616もありえなくはない。

つか、ビューに条件判断なんか入れるんじゃねぇよ

それはMVCをちょっとかじっただけの奴によくある間違い。
オブジェクトの設計論なんだから、MVCそれぞれが内部にロジックを
持っていて何もおかしくない。
逆に、Viewでやるべきロジックを全部Controllerに持たせていたりしたら
そっちの方がおかしい。

プログラムのバグはどうとでもなるけど、
Webの見た目がゴネ始めると辛いからな・・・

>>2
何故か俺のコードに対して、解り易いと言われた
もちろん左に定数書いていたw

>>622のいう本質っていったいなんだったんだろう・・・・

ここは本人にタネあかししてもらわんと本当のところはわからんが、
>>629というオチじゃね？

ってことは、
rsの中に「管理者」か「登録者」を示すカラムを入れておく
か
Userクラス作って「管理者」か「登録者」を返すメソッドを用意する(rsの内容もUserクラスに)
？

#if HOGE
public class Service : Hoge.hoge.Service {}
#slif FUGA
public class Service : Fuga.fuga.Service {}
#slif HAGE
public class Service : Hage.hage.Service {}
#endif

書いたやつ氏ね。

slifちゃうelifだった。typoしたままコピペってもうた

おまえにイラッつとするわ
てか、おまえみたいなのがイラッつとするコードを量産してるんだろうな

イライラの大半は構文だけあっているものや、コメントに存在する
IDEがそういう風に育ててる気すらしてくる

あと規約

>>632
え？左に定数が常識じゃないの？条件文。
ゆとりはどうか知らんけど〜

>641
いろんなソースを見てきたが、少なくとも『常識』ではなかった。

おれよくこういうコード書くけどダメなんか？

if ( 0< hoge && hoge <= max )

別に普通なコードだと思いますが

結局、左右どっちでも書くから固定するのが常識という訳ではない。という話。

javaでは 定数.equals(変数) にしろとよく言われる

>>643
括弧でくくれよハゲ

if ((0 < hoge) && (hoge <= max))

この程度で括弧つけると逆に読みにくくなる

さすがに>>463にカッコつけるのはどうかとおもうが、ORとANDの優先順位が自明かどうかで悩むときがある
論理「和」と論理「積」なのだから順位は自明でカッコつけるのは汚いだけ、と個人的には思うんだけど

その辺は、同一プロジェクトに馬鹿が混ざってるかどうかで変わるんじゃね
格好つけずに括弧つけとけハゲ

>649
(〜&&〜) || (〜&&〜) のときだよね？
俺が大丈夫でも引き継ぎした新人が間違えるかもしれないからカッコつける。

ふふふ、みなさんはまたしょうもないことでお悩みのようですね…… Lispを使えば優先順位など関係無いのですよ！ ふあはは ふはは ふはははは

君はもとから括弧だらけじゃないか

bool b=(((a&0x1)==0x1)?true:false);

>>654
やめろ糞デブ！

>>649
どう書かれているかだけじゃなく、どういう意図かにもよる
文法だけで判断するのはまちがい

>>646
作法だよね。ドットネットじゃあまり普及してないけど
ちゃんと定数は左に書け、
と思う。

>>654
こういうので、1→trueの自動キャストってやっていいもの？

ダメ

好きじゃないけどこんなbool変換もあったね。

bool b = !!a;

「ノンゼロは真にキャスト」って、言語仕様のレベルで規定されていなかった？

Cでは、ノンゼロは真にキャスト、真は1にキャスト、と定義されていたはず

そんなks言語捨てちまえよ

偽は0、真は1つーとPythonもそーだな
別にクソとも思わんが

#defone TRUE (0==0)
#define FALSE (!(TRUE))

誤字でいらっと？

>>641
俺以外はみんな右に定数だったなぁ

別にどっちでもいい
一方に強制しようとする奴が馬鹿なだけ

>>606
MISRAで/*...*/に決まっていますので・・・
ありがとうございました

ありがたくねえけど
「ありがとうございました」としか言いようのない気分になった

https://twitter.com/void_No3/status/250896800112844800

たしかに林晴比古推奨な時点で定数左は終わってるな

voidまだネットで活動してたんだ
すげーな

今だにCだけの知識で頑張ってるよ。

条件文が長くなって複数行になるとき、短い方を先に書くのが解りやすいから、
定数を左にしているよ

俺は、定数名は長く、変数名は短くするけどなぁ。ふつうそうじゃないか？

たとえば変数statusに入れる定数はSTATUS_RUNNINGとSTATUS_WAITINGみたいに、
定数はプリフィクスが長くなるから自然と長い名前になる。

条件文が長くなるのって、コーディングスタイルに問題があることを暗示しているんじゃないかと思う

条件文に限らず、１行で書くべきコードがつづら折りになっているのもそうかもしれない

同一仕様のコードで比較した場合はそうも言えるかもしれないけどね。
仕様を考慮せず絶対的な長さの比較だけなら、コーディングの問題の
有無とはほとんど無関係だろ。

話題ずれてね？まあスレ的には今更か
どんな複雑怪奇な仕様だったらその手の汚いコードを許容できるんだろ。時間ないときの仕様変更かな
はじめから複雑な仕様なら設計でクリアに扱えるよう努力するし、余裕あるときの仕様変更なら腕の見せ所だとばかりになんか燃えるw

個人的には、イライラするコードに陥りがちな要因は、仕様よりは謎スタイルを強制される時に多発する印象

値の上限と下限をチェックするだけでも単純に長くなるだろ？
なんか努力すればそれを短くできるのか？

何言いたいのか明確にしてけろ
前提語らなきゃ「関数化なりマクロ適用するなりクラス設計で吸収するなり好きにしろボケ」みたいな事しか書けないが、そういう回答は望んでないんだろ
定数が長いんだろ。で、一体どういう状況で何にお困りなんだ？
言語の想定は任す

困　←凝視していると松井に見えてくる

>>681
誰に言ってんのかわからんからアンカーつけろ

>680
言語側に努力してほしいね
if (20 <= age && age <= 60) ってのを
if (20 <= age <= 60) って書ければいいんだ

>>684
（・∀・）ｲｲﾖｲｲﾖｰ

>>684
理想っぽいけど優先順位以外の演算子のルール増えてますよねそれ
実装してる言語ってあります？

>>686
結合性の規定があるから一意に決まるだろ？

>>687
型が混ざるとそう簡単には決められないかと
全体をboolとして評価するルールが必要になり、その場合の結合法則がまた必要になってとBNF相当混乱するんじゃないか

関数作るのがそんなに面倒くさいか

if(age.ge(20).and.ge(60))
これで読みやすい。

(if (< x y z) hoge fuga)
やはりLispは最強か

sorted :: (a->a->Bool) -> [a] -> Bool
sorted _ [] = True
sorted _ [_] = True
sorted comp (x1:x2:xs) = comp x1 x2 && sorted comp (x2:xs)
if ( (<) `on` age) [person1, person2, person3]

実際に左に定数を強要された人はいるの？

>>693
ほとんどの会社のコーディング規約が、条件式中の定数は左に書くようにと定めてるよ。

つまりコーディング規約を作ろうなんて思う奴は馬鹿なのさ

>>694
マジデ？
その割には見かけないけど

某ゲーム機のサンプルが左側定数だったような気がした。

>>694
俺はそんなコーディング規約は見たことがない。
多いかもしれないがほとんどってのは眉唾もんだな。

決めたころに==演算子の左辺は定数にしようというバカげたな主張がまかり通っていただけでしょ。

逆に、なんで定数が右じゃないとイヤなのか理解できない

ルールは偉い人が決めるからね
どうでもいい項目に角を立てて反対する理由もない

>>700
日本人だから。

他人のコードを読む場合は、左定数だろうが右定数だろうがどうだっていい
自分が書くコードは、自分の流儀に反するスタイルを強制されるとイラっつとする

結論：各自好きなように書け

本来 == と書かなきゃならない所を

if (FIXEDPARAM = testdata ) { func(); }
って間違えて書いてコンパイルエラーで救うためさ

これが右定数だったら、
if (testdata = FIXEDPARAM ) { func(); }
必ず通るか、必ず通らないってなるからな。

まあ、こういう間違いはワーニングレベル高くしとけばレポート出るけど
ワーニングは無視する奴らだと、BUGが潜在化するからな。

>>704
そんなことするくらいだったら
#define EQUALS ==
ってやっときゃもっと確実じゃね。

>>705
if ( FIXEDPARAM EQUALS testdata ) { foo(); }
誰がメンテすんだよこんなもんw

別に関数ぽく書いてもいいぜ。
#define EQUALS(a,b) a == b

= と ==を間違えるっていうんならこれくらい徹底すべき。

経験２0年以上のプログラマですが、
＝と＝＝を書き間違えたことなど一度もないです。
ほんとにそんなミスあるの？

>>708
俺もたまに思う
あってもテストでさくっと潰せる程度の問題しか経験ないす
過去にそれに起因するよほどのバグでもあったのかね

>>708
他人のコードメンテする機会があると、笑っちゃうようなミスが沢山あるぞw
もちろん == と = の書き間違いなんてザラ

代入文がIf文の条件式として使えることに問題があるんでないの？

>>710
他人はともかく、あんたはどうなんだ？

= と == 書き間違えたらデバッグ時に分かるはずなんだけどねぇ

= と == の書き間違えなんて、都市伝説だろ？
そんなものが他人の目に触れたり、コードメンテ(笑)にまわる？
>>710 は、意図的に代入してるのを、盲目的に == に変えたんちゃうか？(笑)

意図してやってるのはまさにイライラするコードだな
稼働中のソースで条件式内代入あったら見なかった事にしたくなるw

>>714
C FAQに載る程度にはよくあるミス
ttp://c-faq.com/style/revtest.html

そこには、最も経験を積んだプログラマですら犯す可能性のあるミスと書かれている
実際、俺は何度か見たし自分でも何度かやらかしたことがある
俺は右定数派だが、Cとは異なる代入比較演算子を採用している言語で開発した後とかに、まれにやっちまったことがある
コンパイラの警告で潰せるミスだけどな
見たことないって言ってる奴は日曜プログラマかJava厨だろう

>>716
> そこには、最も経験を積んだプログラマですら犯す可能性のあるミスと書かれている

どこにもそんなこと書かれてませんが？

信号は赤、より、赤は信号、って言われた方がしっくりくるチョンコPGだろ

>>717
To be sure, accidentally using = instead of == is a typo which even the most experienced C programmer can make.

>>716
おまえみたいなオナニープログラマの話はどうでもいいんだよ

だから、 ただの typo だろ？
= と == をことさら取り上げる必要あるのか？
辞めたら？プログラマ

>>716
は、その前に英語の勉強をした方がいいな。
老婆心ながら

>>716
ミスが良くあるんじゃなくて、0 = xと書く奴がC FAQに載る程度には有名って事だろ。

> まれにやっちまったことがある
Cは多分50万行くらい書いたと思うけど、こんなミスねーよww

コメント英語縛りは幸いにして未経験
でも、やれって言われたらコメント書く量減る気がする。

>>716
見たことある：
　自分がやっちゃった→お前が未熟なだけ
　他人がやったのを見た→お前の周りは低レベルだらけ

そちゃ、typo はあるだろ、人間だから。
だけど、そんなのに気づかずに人に渡すような奴のプログラム、一から信用できんな。

>>726
だから、定数を左辺に置くスタイルにするんですか？

そちゃとか書くおまえはtypo多いんだろうなあ
つーかtypoが多い奴がtypoを防ぐための工夫を否定してるのか
終ってんな

俺ならtypoを防ぐことよりも可読性を高めることの方を優先するわ。

同値分割くらいやるだろ
そんなテストやりもしないから、左を定数に書けってか

逆に左に定数を書くことでテスト項目減らせるならそれもありかもなｗ

左定数派は値テストを削ってバグの温床を生むことが証明されたな

a == 0と書こうが0 == aと書こうが、
・aが0の時のテスト
・aが0以外の時のテスト
のどちらもする必要があるだろ。

>>731
一体どのテスト項目を省略するつもりなんだ？

そういうテストで出ない危険性があるから、定数は左なんだよ
何入れてもtrueの場合はどうするんだよ

条件分岐する意味がないですね
左定数派は想像以上のスキルをお持ちのようだ

ﾜﾛﾀ

typoはテストで全部見つけられるものじゃないだろ
typoが多い奴がtypoを防ぐ工夫を否定してるのがひどいわ

>>734
if (a = 0)
と書いてしまったとき、

> ・aが0以外の時のテスト
がパスしないだろ。

左定数派ってテストしないのか

するだろ

Cならlintかsplintくらい使えよっちゅーことですな

tmpHeikin = (tmpKei=GetKei())/GetKazu();

スキルを見習えと言われた人のコードが関数名とか変数名もほぼそのまま、これだった…

ＶＢじゃないのにＶＢ臭がすごい

なんか>>714が必死すぎて笑える
仕事回してもらえなくてよっぽど暇なんだな

>>723
> Cは多分50万行くらい書いたと思うけど、こんなミスねーよww
50万行程度じゃ、２〜３年程度の経験だろ
まだまだだな

最近の本「リーダブルコード」の7.1「条件式の引数の並び順」では
調査対象となるものを先に書くのが自然になる。と書かれているね。
ついでに定数を左に書くヨーダ記法は過去のものである。とも。

>>746
へー。海外にもあるんだ。
日本ローカルのルールだと思ってた。
仕事でアメ人やインド人のコード読んでるけど定数左に書いてるのは見たことないな。
やってるのは日本人のしかもスキルが微妙なやつだけだったりｗ

それを否定してる奴はいないんじゃね？

= と == を間違えるなんて見たことないしありえない
↓
C FAQには、ありうるtypoだと載ってるが
↓
どこにも書かれてませんが？
↓
> To be sure, accidentally using = instead of == is a typo which even the most experienced C programmer can make.
↓
発狂

というつまんねー流れ

typo で間違えることはあるけど両方変数だったらどうしようもないしな。
つまらん小細工よりリーダビリティのほうが重要だよ。

>>747
> へー。海外にもあるんだ。
> 日本ローカルのルールだと思ってた。

これはもうゆとり乙としか言いようがないw

>>747
ちょっと話はずれるが、最近のインドは日本に特化しすぎて
何も言ってないのにエクセルの方眼紙仕様書とか作ってきてうざいよｗ
大手企業がインド使いまくるのはのはいいけど、俺ルールゴリ押しして
日本の悪習を世界にバラまかないでくれと言いたい。

定数左に関しては、20年前には既にlint使えよって言われてる話なんだけどな。

>>750
すまんがおっさんだよ。
調べてみたら C FAQ に書いてあるのな。
ここ10年くらい見てないから忘れてた。

C言語のポインタ配列とか配列の参照渡しとかで頭ぐちゃぐちゃですorz

鼻から脳みそ垂れてきてるぞ

鼻から悪魔がじゃじゃじゃじゃーん

20年前にlintねえ

なかったとでも？w

>>757
Wikipediaより
> Lint first appeared (outside of Bell Labs) in the seventh version (V7) of the Unix operating system in 1979.
> It was derived from PCC, the Portable C Compiler, which was included with that system. Lint and PCC
> were developed by Stephen C. Johnson, who also authored the parser generator yacc.

少なくとも、1991年には日本のWSには入ってた。
多分1980年代に普及したんじゃなかろうか。

色々と記憶が薄れているが、1990年代中頃には
PC用の製品(Gimpel SoftwareのPC-lintとか）が
サザンパシフィックなどにより輸入販売されてて
C Journal あたりに広告載せてた。

おまえらは20年前にlintを使ってたの？

20年前はbasicとマシン語で遊んでた

20年間はプログラムなんて他人に組ませればいいと思ってた。
どっかで道を間違えた。

20年前なんて、アセンブラでゲーム作ってよ。
UNIXを使う環境だったけど、そもそもlintなんて使う理由も無かった。

>>764
そりゃ仕事でUNIX Cやってないなら使う理由内でしょ

今日見たイラっとするコード
ttp://kohada.2ch.net/test/read.cgi/prog/1306646249/746n

定数位置より実害は出ないけど、括弧のスタイルは簡単に人をイライラさせることが出来るよな

ttp://i.imgur.com/x4Hha.jpg
ttp://i.imgur.com/rczj4.jpg
ttp://i.imgur.com/Kg4B4.jpg
ttp://i.imgur.com/47RgE.jpg
ttp://i.imgur.com/x51uU.jpg
ttp://i.imgur.com/YnLhI.jpg

何これ、続きがすげえ気になるんだけどｗ
タイトル教えてくれ

>>766

756 ：仕様書無しさん [sage] ：2012/10/05(金) 12:10:34.02
>>746とかイラッつとするわｗ
http://kohada.2ch.net/test/read.cgi/prog/1338703896/l50

757 ：仕様書無しさん [sage] ：2012/10/05(金) 18:05:32.18
この程度で読みにくいとかイライラするようなプログラマはいらねーな。
レベル低い

不統一な中括弧もうんこだけど if( hoge ){ みたいなカッコの開始終了に無駄ホワイトスペース入れる奴はやめてほしいな。
むしろ外側にスペース入れたいくらい。

if ( hoge ) {
    /* do something */
} else {
    /* do something else */
}
僕なら、こう書くかな

↓俺のバイヴルなんだけど、お前らにもこっそり教えちゃおう☆
http://www.kernel.org/doc/Documentation/CodingStyle

>>773
Linux style か。
Cだけだと 8 タブでいいけど C++ と混ぜると無駄に横長になって見づらいんだよな。
別々のスタイルにする手もあるけどついてこれない人間も出てくるし。

Bivle

1ファイル1万行超えが普通にあるプロジェクトで、万元戸とか言って
バカにしてたら、当の本人に

「知ってるかい？古いVisualStudioは1ファイル65536行超えると
クラッシュしやすくなるから、ちゃんと分割しないといけないんだよ」
とか言われたorz

もう、この人と仕事したくない…

Cがステータスな人とも仕事したくない

Cしかできません（ｷﾘｯ
っておっさんに会ったことあるけどどうしてるかな。
ご飯食べられてるのだろうか。

組み込み分野で食ってるんじゃないの

文法だけしか知らないのでは？
組み込みは無理

派遣で申し訳ないんだが、今の現場、Cの仕事が一人分以上は楽にあるんだが、
なぜかC言語だけしかできないと落とされるっぽい

オーダー出している人と現場が乖離してるのか、１言語だけだとNGなのか
わからないけど謎

>>781
C言語だけしかできないってのが良くわからん。
普通に考えて、Cがそこそこできれば、C++だってC#だって書けるだろ？

いまどきCしかできないってのは経験不足と見られるんじゃね？
プログラミングはCだけだったとしても、長くやってりゃスクリプト
言語のひとつくらいツールとして使いこなしているのが普通だろうし。
あと、オブジェクト指向言語を経験してないと見られるのも弱いだろうね。
実際の仕事がCだけだったとしても。

表向きの募集と実際の仕事が違うんじゃね？

C以外を使ったシステムも連動してるかもよ
まぁ再利用し辛い人材は使いづらいから要らないんだろ、当然な感じはする。

AもBもなしで、いきなりCからでした。
ただ苦しいだけでした。
今はずっとPTSDのリハビリ中です。

つまらないおっさんのジョークを聞くとイラッつとする

分かる自分もおっさんと言う事に気付いて欲しい

>>787の意図するもの

Ossan res786;
Ossan me;
if (res786.joke() == DULL) {
　me.irritated();
}

>>788

Ossan res786(DULL);
Ossan me(NOTDULL);
me.irritated(res786.joke());

こうだろ

>>787

Ossan res786;
Ossan me;
if (res786.joke() == DULL) {
　me.irritated();
}

>>788

Ossan res786(DULL);
Ossan me(NOTDULL);
if (res786.joke()) {
　me.irritated();
}

>>788
俺わからないんだけど、AとかBとかCについて教えてもらえないかな

意味わかんねーとイラッつとするなｗ

キスをAとかいうアレか。

>>761
家内制手工業してた

【１】
sqlSelect = "SELECT "
sqlSelect &= "COL1, "
sqlSelect &= "COL2, "
sqlSelect &= "COL3"

【２】
sqlSelect = "SELECT"
sqlSelect &= " COL1"
sqlSelect &= ", COL2"
sqlSelect &= ", COL3"

さてどっちがイラッつとするでしょう

こんなテーブル定義にイライラする

どちらもわざわざ分けて書く必要ないじゃん

COL2とCOL3の間にCOL4が入る仕様変更が来るのが
お決まりの会社なのかもだぜ

&=にイラッとする。

SELECT * のほうがイラッつとする

インデントされてないのにイラっつとする

qstr = _
q.Select_("foo", "bar", "sum(baz) as sum_baz") _
.From_.Lp_.Select_("top 100 hoge", "huga", "*").From_("HOGE").Rp_.As_("T1") _
.Where_(e.Eq_("foo", piyo).And_.Lt_("bar", poyo)) _
.GroupBy_("foo", "bar") _
.Query
どうせ書き捨てのソースだから良いよね、と思って
上みたいな感じでクエリが作れるようにMeを返すクラスを作って魔改造している
これ見せたら先輩になんて言われるんだろ

＜ どうせ書き捨てのソースだから良いよね、と思って

そういうソースにかぎって長生きするんだよ

>>802
仲間がいたとは驚きを禁じ得ない
俺はSQLビルダー用途でのメソッドチェインは一度の満足で終わってしまったけど、一式やってる様子見るに使い物になってる風だなー楽しそう
超イラっとするのも素敵ｗ

OpenGL扱うイライラメソッドチェインやったらおもろなくて意気消沈
ステートマシンでやっても繋げにくいだけで萌えなかった。いややる前に分かれよボケって話だが
くけけ

頑としてコーディングスタイルの標準化を受け入れないリーダー


どのコードをチェックアウトしてきても常に常識的なスタイルであれば
今の残業時間を大幅に削減できると俺は思うのだが、どうだろう？

（見やすければ、そのぶんすみやかに思考を整理できる）

常識的なスタイルで書く分、思考能力が削られることになるけどな。

>>805
全員にとっての標準が作れないと悟ってるんだろ、そのリーダーさんも
強制力のないおおまかなガイドライン作る提案程度から始めるのが吉

君が他スタッフ全員から全幅の信頼を受けてない限りは、君の望む事態にはならんと思うよ

フォーマッターにかければものの数秒で終わる話なのに・・・・・・・・・・

>>806
そんなわけないだろ

>>807
おれのことを信頼しろと言っているのではなく、
カーニハン、リッチー、クヌースの経験に基づいたスタイルをリスペクトといっているのだ

>>810
今更それかーって言う奴らがいるから悩んでるんでそ？
そんだけの根拠じゃ権威主義と笑われて終る上に、古いって馬鹿にするだけの奴も居る訳だ。無駄に間延びするわとか最近の本でそんなん見たことねーよとかさw
聞いた事のない出版社のJAVA教本盾にして迫ってくるアホとかぎょうさんおるのよ
論拠整えなきゃそんな馬鹿どもと同列扱いよ

だから強制力のないおおまかなガイドラインの提案から始めろって。膝付き合わせてりゃ、十人十色のいろんな論拠聞けるぜ

君の望む事態にはならんと思うが

ゲリラ戦
くっさいコードファイルを見たら即indent

インデントしただけでもその箇所をテストしないといけなくなるじゃん

インデントだけでもスペース派とタブ派とか空行もインデントするか空白なしで即改行かとか派閥がある

ふいたｗ

>>814
空行のインデント？流石にそこまで気にする奴はバカ認定していいと思うｗｗｗ

Man Page of indent

http://linuxjm.sourceforge.jp/html/GNU_indent/man1/indent.1.html

コーディングスタイルの差異でいちいち思考が妨げられるなんて甘えだろw
困るのはメンテナンス作業での追加削除のスタイルが統一出来ない程度だ。

まともな同僚が多い職場なんですね
うらやましいです

>816
改行コード表示するエディタで表示がデコボコになってると気になる
バージョン管理システムで変更箇所とみなされちゃうから直すわけにもいかないでうっとおしい

ウンコスタイルに育てられた新人がウンコスタイルになった


他人に迷惑がかかるバグを絶対に出さないならいいが、そうでないんだから、
あとからコードを読む人間のことを考えて書いてほしい
（お前、毎日毎日バグ修正情報のメールだしてるじゃん）

書いて欲しいというか、コミットする前に自動整形ツールを通して欲しい
（処理ブロックを作業終了時に空行なくミッチリつめるのは、やむをえないから許す）

コミット時に処理動かすくらい簡単にできるだろ。

できるなどうかじゃないし

メンバー全員に上が指示すればいいのに
あれこれ理由をつけて、やらない

無駄なことはしないのは正しい。

バグが多すぎるとさらに上から何度も言われているくせに
派遣と外部委託を切らされた途端にそのザマなくせに

TWO==varみたいな変な書き方を「うまいやり方」だと思うようなセンスの人って、
同時に「三項演算子は解りにくいから禁止」なんていう変なセンスも併せ持っていたりするのかな。

どんだけ左定数に恨みがあるんだよ
先輩に苛められたのか？
左定数は昔のCのバッドノウハウだから、左定数が好きな人は昔からCでコード書いている人
そういう人はむしろ三項演算子大好きが多い

三項演算子を代入しないで使ったらキモがられたでござる

最後にC言語で書いたのは何時の話だったか・・・

三項演算子で副作用だけ使うのは俺もキモいと思うわ。

>>827
え？なんでバッドノウハウなんだ・・・？
だめなん？

またシーかぁ

>>831
別に俺はどっちでもいいが、このスレには左定数を狂ったように叩く奴がいるからな
過去にトラウマでもあるんだろう

>>833
そうなのか、解説サンクス
おっちゃんよくやるから焦ったわ

>>829
大学の単位で。
今25だけどCやる機会あるかなぁ

>>831
コンパイラの警告すら読めないか、解析ツールも使えない人向けのノウハウだから。

>>834
叩かない側の意見だけ参考にして納得してるのはどうなんだ
まぁお前の問題だから別にどうでもいいけどさ

>>837
叩く意見出してからもの言え

まぁ実際には「左定数は有効だ」という意見が否定されているだけで、
べつに左定数で書いて悪いわけじゃないしな。
それを、叩かれたと感じた人はいたのかもしれんけど。

まったくだな
左定数でコードを書くことを強制されるのは勘弁だけど
他人が書いたものを読んだり、そのスタイルに合わせて部分的に修正するくらいならどうってことないしな
ただ>>836は間違いだろ
用心を重ねることが悪いことであるはずがない

用心してコンパイルオプションを指定しておけばエラーにできるので不要かと。

うん、不要だね
やってもいいけどね

そいう意味では、システムハンガリアンみたいなものだね。

システムハンガリアンは抽象度を下げるだけで害しかないだろ

わかりやすいと思ってる人にはわかりやすいんじゃないの？

抽象度が高ければいいわけでもないよ。
rubyとかやってると、ぶっ壊したくなる。

アセンブラ上がりの俺にとっては有難いルールだったんだが、
高級言語だとその辺はあると逆に邪魔ってのもわからなくも無い。

仕事する上では自分のポリシーは特に持ち込まず現場のルールに
従っている。

if (ZERO >= cond) {

//デバッグ用、リリース時にはDEBUG ENDまでコメントアウトしてください。

>>849
#ifdef〜#endifで囲んどけよｗｗｗ

Cから来た人間の適応力の無さは異常

テンプレートは躊躇するよなあ
適切に使えるのかとか、バイナリに無駄が発生しないのかとか
気になって

著名なプログラマは大体Cあがりじゃないの？

>>851
Cで落ちこぼれて他の言語に鞍替えしただけじゃないかと思う。

C上がりの老害プログラマーがアレルギー反応するもの
・class意外のC++キーワード、特にtemplateとoperator
・関数の途中にある変数定義、特にfor文の中
・例外処理、特に失敗したnewがNULLを返さないこと

>>855
Javaあがりのゆとりの間違いだろw

はぁ？

まぁ確かに、長いことCとJavaやってきて最近C++使うことになった俺からすると、
templateをgenericsのようなものかと思ったら「はぁ？」な状態だったし、C系統の
言語でoperatorは逆にやりすぎだと思った。
ただ2番目は、C99じゃあ認められているしそれ以前からも使える処理系はあったから
べつに違和感はない。

三番目知らない人多いかも
おれも、入門書に書いてあったの忘れて、あとで読み返して愕然とした

operatorなんて多言語への移植性がなくなるものを使うなよ

>>860
Delphi厨乙

>>855
一般的な内容のように書くから誤解を招くんじゃないの？
「Cをちゃんとマスターできなかった老害プログラマ」のことだったら
納得いくけどな。そういう人はもともとやっていた言語すら怪しい。

「Cをちゃんとマスターできなかったプログラマ」はC++についていけなくて
Javaが出たときに大喜びだったからな

Cもできなかった奴がJavaやってどうするよ。

Cって言うよりポインターな。

まぁたしかに初心者がつまづくところだが、いくらやっても理解できなかったとしたら
そもそもプログラマとして才能ないだろ。
Javaなんかさらに理解できないんじゃねーのか。

>>861
Delphiでもできるぞ

ポインタを関数の引数と配列へのアクセス手段にしか使えない奴は糞。
C/C++プログラマーを20年やってる奴でもそんなのばかり。

最近多いんだよねー
Javaとかちょっとかじった程度で
「俺プログラマーやってます」って顔する子

あるある
最初の入り口がオブジェクト指向なんだよね
最近の子って

そうそう
そんなんじゃ使い物にならねぇっての

>>869
まぁまぁそういうなや
若いってことはまだ成長するんだろうし

>>868
いや、それ以外に使うと一気に危険度が上がるから使わないに超した事無いんだけどな。

うはっ、新人に説教されちゃったよ俺

「使わないに越したことはない」に反論できないなら老害乙としか言えない

> 関数の引数と配列へのアクセス手段にしか
あと思いつくのは構造体のメンバにポインタ使うくらいなんだけど
具体的にどういう用途に使えたら>>868に認めてもらえるの？

定期的に見かける、「ポインタをマスターできた奴」が、どこにいるかわからん
「マスターできなかった奴」を馬鹿にするという低レベルの争い。
「マスター」するのによっぽど苦労したんだろうなｗ

CUDAならシェアードメモリにデータを写してポインタで扱ったりするから、引数や配列じゃない扱いをしてると言えるっちゃ言える
そういった、ハードと密接な関係を持った技術が足りないって事なのかな…オブジェクト志向だとそんな部分は隠蔽する方向に設計するだろうし

>>875
確かにちゃんとポインタ使ってプログラム書ける奴が「俺、ポインタをマスターしたから」
みたいに言ってるのは見たことが無いｗ

別にトリッキーなポインタの使い方が出来るから偉い、というわけでもないと思う。

でもポインタが絡んでくると「俺には分からん」とデバッグを投げる奴がいて迷惑かけられた
上に、ポインタは可読性を損なうから使うな、バグの温床だ、と言われた(要は俺の先輩）。

ついでに誰も突っ込まないから
>>869,872
例の漫画のセリフだねｗ最近あのURLのコピペを見かけないが。

>>875
糞スレ立てたのお前だろ

>>878
糞スレ上げたのお前だろ

ポインタマニアなのかキャストマニアなのか、
こういうのをやっててイラッとした事ならある。

extern char *dynamic;

if (dynamic != NULL)
　　((int (*)(char *, int, int, int))dynamic)("hoge", 1, 2, 3);

>>880
マニアでも何でもない。
ただの老害。

「コマンドラインインタプリタみたいなもの」を
安直に作りたい時には、そんなキャストもしたくなるかもな。

最近はもうコーディングの制限を規約じゃなくて
言語の選択で回避する時代になってきてる感じ。

>>874
関数ポインタくらいは使えてほしいところじゃね？

>>876
隠蔽する技術があるのと、隠蔽された環境をつかう技術があるのは違うからね。

>880
普通のポインタと関数ポインタとの間には、互換性がないから、危険

全角英数が入り混じったファイルをプログラマーに見せると最悪しぬ

>>880

つうか、なんで最初にchar*で宣言しているのかが意味不明。
組み込み？

>>887
void *がなかったK&R時代には、その代わりにchar *を使っていたから

>>888
そうじゃなくて、後でキャストするくらいなら最初からそのポインタ型で宣言しとけって話だろ。

あんな函数やこんな函数を呼ぶための
函数へのポインタの配列を使いたい時もあるかもしれないぜ。

まあ一枚皮かぶせたほうがすっきりしたんで必要なくなったが。

そこまでやるなら「ポインタマニア」と呼んでやってもいいかもしれない。
が、俺ならそこは構造体にするな。なんで配列なんだろ。

関数ポインタの配列なんてc++のメンバ関数ポインタに比べたらどうでもいいレベル

テンプレートじゃダメなんですか？

a == 0 を a = 0と書いてしまうより、
a = 0 を a == 0
と書いてしまうことが多い。

無駄にタブが多いコード。
コードの無能さとタブの多さは比例する。

4tabで書いたのを8tabで見ていたり?

逆に言えばタブを全く使っていないのが有能なコードということになるが

1行プログラミングの再来か!?

expandtab余裕

tab使わないとカーソル移動がめんどいな

この前他人のPHPの仕事の引継ぎで、
規約にタブじゃなくてスペースってあったからそうしたけど、
思った程困らなかった。

Eclipseで自動変換ではあったけども。

厳密にインデントしていったら画面が真っ白になって
右スクロールしてようやくコードが見えたなんてことも

>>902
それは適度に構成考えて分割しないからだろw

更新履歴で埋め尽くされたコードを見ると、
「コミットメッセージに書けよ」と思ってしまう。

マージして更新履歴でコンフリクトでると萎える。

カーソル連打してインデントされてる場所を移動するケースとかそもそもないけどな
だいたい、最終的にフォーマッターかけりゃいいだけだから、行頭のインデントずれてるとか関係ないし
そのあたりはカーソル位置とか気にせず適当に書いて大丈夫だもんな

だれがいつ更新したかなんてゴミデータをコードに残す慣習はいい加減やめるべきだよな
ゴミデータと一緒に時代についていけないゴミもごっそり削除してしまいたい

更新履歴、それは責任のなすりつけあいを回避して、よりクリティカルな責任を現場に課すための絶好の治具
更新履歴を甘く考えてはいけない
あれはIT土方どもを畏怖させる鉄球付きの足枷だ
服従せよ、バグに鉄槌を、バグを生んだ物には制裁を

って事になってる現場も少ないみたいね
今の現場も形骸化しとるわ。誰のバグか追跡はできるけど、それする暇でバグ治す感じで毎回うやむやに

>>908
バグ仕込んだ当人がとっくの昔に辞めてるなんて珍しくも何ともないからな。

>>908
マジで担当してねープログラムに俺のソースからヘッダコメントを名前そのままに
転載すんのやめろあのクソ野郎
てめえの責任を俺になすりつけんなよ

それはひどいｗｗｗｗ

整列された数万件のデータをご丁寧に全舐めして検索するコードを書く奴は恥ずかしい。

それはコーディングスタイルの問題とは違うような・・・・。

あー、告白すると関数分割をつい忙しさにかまけて怠ってしまうことはある
巨大で同じような処理が何個も放置して済まないとは思う
メンテできない長さじゃないが、あれは恥ずかしいな、我ながら

WindowsAPIがサッパリ理解できない
何と何を組み合わせて機能が実現するとかサッパリわからない。

>>915
初めはみんなそうよ、そこでいい書に出会えるかどうかってけっこうキーポイント
だとおもう。
俺のオススメは「解説」ではなくて「書物」のような印象を受ける本をまず選び
それから本格的な解説なりを読んだほうがいいと思う。

語る感じのするものね。回りくどいけど、そのほうがいい。入りやすさが違う。
感のいい人なら解説でもいいけどね。

今はブログに書いてくれてる人が多いおかげで本とか読んだこと無いな。
特殊なハード向けだとそもそも本が無いとか、
本が出たけどそれよりいい本書ける程度の知識があったりとか。

語る感じのする書物といえばオライリー

冒頭のアメリカのオタクのジョークが寒いからあんまり読みたくない

>>915
複雑だけど決まりきった使い方しかしない
あるAPIは別のAPIの入力のためにだけ存在する

だったらまとめてひとつのAPIにしろよと小一時間愚痴りつつ
今日も決まりきったコピペをしている

ｐinvoke.netからのコピペを生業としています

コーディングスタイルというか、メイク時に発生するワーニングをずっと放ったらかしに
されると、気になる

いやそりゃあ実行ファイルはできるぜ？
でもさ、ワーニングって完全ではないから出るものが多く、放ったらかしていいものだとは
思えないんだよね

1.　この〜は使われていませんというワーニングが出る。
2. 〜を削除する。
3. リリース用にマージしてコンパイルしたら、「〜がありません」というコンパイルエラーが出る。
4. 開発環境では〜は削除されているが、削除した部分の変更は、顧客の都合で、
　適用が差し止められていた。

警告放置のヤツに限って
「クオリティを上げようｷﾘｯ」とか説教を始めるから困る

コンパイルが通らないソースをチェックインして帰る奴はもっと困る。

Javaだと警告は全部削除するけど、昔C勉強してた時は
「警告は問題ないものが含まれており、完全に出ないようにするよりも、読みやすくする方が大事です」
みたいな事が本に書かれてたなあ
そういう警告の例も出てたけど、今振り返ってみるとそのコンパイラが腐ってんだろ？と思う

Microsoft謹製のVisualC++でDirectXプログラムを普通に書いただけでも警告出る

重要な警告が埋もれて見落とす

消せる警告は消していくべきだけど無視する糞が多いこと
あとは俺々フォーマットでコード書く奴

っていうか、コンパイルオプシションで出る
ワーニングが制御できることを知らん人がいるのか。

>>930
問題にしてるのは姿勢であって、そういう臭いものに蓋をして知らんぷりする
態度はどーもな
無論、わざわざ警告が出ることを承知で書いててなら全然ありだけど

臭いものに蓋っつか、必要じゃない警告は止めてかまわんだろう。
態度のことを言うなら逆に、どういう内容の警告なのか考えず
一律に「出るからダメ」的な態度をとるほうが問題のような気が。

コンパイラオプションで止めてしまったら、
必要な箇所も必要でない箇所も一緒くたになってしまうだろ。

>>932
だから姿勢だっつーのに頭悪いな

アプリケーションの要件や適用分野を考慮して、
コーディング規約を作って、コーディング規約に従って
ワーニングオプションを設定するというのは、
そんなに間違った態度とは思えないんだが。
無関係のワーニングの中に、重要なワーニングを埋没させてまで、
すべてのワーニングを表示させることがそんなに立派な態度なのかね？

まてまて。警告を表示させる事それ自体が目的の奴はいなかろうｗ

うちはJava一本だからか、警告は全て潰せで済んでるんだけども。
スレ読む限りどうしても消せない警告があるとか、警告通りに対処するとむしろ害がある場合があるって事のようだし
なんかしら事情があるなら、ワーニングオプションと規約による対処はもちろん妥当だと思うよ

register教信者にイラッ☆

register int hoge;
register int fuga;
// ...10個くらいregisterが続く
register int piyo;
register int piyopiyo;

get(&hoge); // アドレスを取る・・だと！？

まだregisterってあったのか

>>937
っていうか、コピペで意味知らずに使ってるんじゃね？

似たようなのにinline教がある
そして邪教__attribute__

#pragma 最強

#ifndefだらけのソースを今だに書く老害がいる

普通にインデントしたら100行位になるコードを一行にずらああああっと書くクソゴミ

生クエリを1行で書きやがったか？ｗ

多重ネストさせた三項演算子とか

50行ほどの同じようなコードを数ブロックコピペしてある
よく見ると変数が一つだけ違ってる

そういうのに限ってpublic staticとか

プロパティなら許すん

クラスメンバー変数に「m_」を付けるスタイル、
最初は気持ち悪くて仕方なかったが、
今ではすっかりこれ無しじゃダメな体になちゃった・・・
人が作ったクラスにも全部付けちゃう。

きもいな
なんか利点あんの？

俺はアンダーバーは付けないタイプだなー

利点としては、ローカル変数との見分けがつくくらい？
ほかにはハンガリーなんて使わんが、メンバ変数だけには付けるな

>>950
ローカル変数や引数と名前が重ならない。
逆にローカル変数にはthe, 引数にはin/outをつけて区別するというような
風習もあるけど、それやるくらいならメンバ変数に接頭語つけた方がいいと思う。

一行120文字くらいのクソ長いコメント書くのやめて欲しい。
視線移動を考慮してないので読みにくい。

メンバ変数にtheなら昔見たことあるけど、ローカル変数に
接頭辞付けるルールってほとんど聞いたことないな。

ハンガリアンコーディングは本家MSもやめたんじゃなかったっけ？
Java ならメンバ変数は、this つければ見分けがつくから、
メンバ名自体を変える必要を感じないな。

thisつけなくても使えてしまうから区別したいわけでしょ。
まぁ、JavaならEclipseなんかで見分けてくれるけど。

スレの趣旨的には、プリフィックス云々より、
this つけないコーディングの方がイラッとくるな。

>>955
今はハンガリアン記法使うなって以外にも命名するときには略すなって言ってるな
徹底できてるのかどうかは不明だが、英語できない奴はイラッとしてそうだし、英語できないプログラマにイラッとしてる奴も居そうだｗ

booleanだけは「b」付けたいなぁ。
bSuccessみたく。

あと参照渡しで結果を期待する引数には
「ret」付けたい。retErrorとか。

>>959
いまどきのbooleanはisHoge/hasHogeだろ

わかりゃいいんじゃね？

変数名が英単語として意味をなさないものになるのがなんか抵抗がある。
論理値は「〜ble」とかでいいんじゃね？

flgHoge は何故かよく見る

furaguHogeだろ

flgOreta
flgTatta

flgEnableFlag

flgとflagが混在してるとイラっとする

「flgとflagとfuraguは用途が異なるので違う名前にしています」

boolean YuukouFlag;
boolean YuukouFlagInvalidFlag;
long YuukouFlagInvalidFlagNoYuukouKigen;
boolean YuukouFlagInvalidFlagNoYuukouKigenNoUseFlag;

変数名／関数名ネタはどうしてもuwariteと比較してしまう

>>966
これはあるあるだな

関数の中で被らないように長い名前にしてるのは分かるんだけど、ちょっとイラっつとする事はあるな。
実際 data とか名前付けて被ってておかしな動作した事はあるんだけどもｗ

それも居るな
tempとか安直な変数宣言して複数のロジックで使い回して
微妙にスコープがかぶってるところで
特定のケースでのみ値上書きするようにしちゃって
みょーな挙動させてイラッつとさせるコード書くヤツ

英単語2〜3つ続ければ大体かぶらない

FirstTemporaryData
SecondTemporaryData
ThirdTemporaryData

dataだのtmpだの安直な奴はメソッドの中で定義していても多様されるとイラッつとするレベル
逆に広域定数かつ使用頻度の高い変数名がやたら長いのもイラッつとする
例えば整数を直接書くなというコーディング規約が生み出すConst hogehoge_zero = 0;やらConst hogehoge_one = 1;の事
最近は見てないけど、整数を直接書くなっていうのはマジ簡便だわ、どうせそこら中にif(foo != PublicData.hogehoge_zero) { return bar; }だの何だのがはびこって結局保守性変わらない
整数とか使用頻度高すぎだから、結局一箇所一箇所hogehoge_oneとかで書き直さなきゃいけないの目に見えてるから

oneとかzeroとかいう名前にする意味が分からない
どうして列挙型を使わないのか

×
Const hogehoge_zero = 0;
Const hogehoge_one = 1;
○
Const SUCCESS = 0;
Const ERROR_HOGEHOGE = 1;

zeroだのoneだのの意味が無い名前はダメ

>>97
const int kErrWrite = -2;
const int kErrOpen = -1;
const int kOk = 1;

数値の0を表すconst変数をzeroにしたことはあるな。

>>977
「定数は必ず別に定義する事」
みたいなルールがあるとたまに見かけるなｗ

#define KANRI78493_00
#define KANRI78493_6464
#define KANRI78493_256256

char temp[KANRI78493_256];

助けて・・！