プログラマの雑談部屋 ★32
■ このスレッドは過去ログ倉庫に格納されています
>>99
さんこうなんちゃらは
普通、使用禁止のコーディング規約じゃね? >>102
俺は、色々な会社で色々なプロジェクトを死ぬほど経験した
非正規底辺プログラマーのおっさんだが
だいたいどこ行っても大手のコピペだろうコーディング規約は、
禁止されてることが多かった気がする。 ジャップランドのIT現場では規約とは足枷のエイリアスなんだよって世界中で笑い者になってるよ >>105
その定義は世界共通なんやけどおたくナニ人? >>100
「引数は時間、返り値はvoid、引数が3600秒未満60秒以上なら分のみ出力、引数が60秒未満なら秒のみ出力せよ」
って関数を作る場合、分出力と秒出力のどっちが異常系?どっちが正常系? 異常系は3600以上
0から3600未満は60進数の最上位桁を得るという問題なので分岐は不要 ミリ秒にも対応しろ、って仕様変更されたら、秒出力が正常系から異常系に移るって事かな >>109
お前、それ明日の昼休みに同僚に言ってみたら?
「分と秒なら、秒が正常系、分が異常系ですよね」ってさ
どんな回答が返ってくると思う? 条件文の後置を全ての言語がサポートすべき
return "a" if flg = 0
return "b" if flg = 1
return "c"
最高に見易いし英文(命令文)としても自然だ >>108の問に抜けがあるのが問題だな
単位も出力しろって問にしないと、10秒のときと10分の時で出力が同じになっちゃうじゃん ジャップランド滅びねーかな
日本の国土は好きだよ
ある意味で俺は愛国者だ
日本は土地は好きだからな
でもジャップ民族とジャップの文化歴史は嫌い
中世ジャップランドはいつ迄続くんだよ
海外からの移民受け入れでジャップの文化を上書き更新したい。 >>115
自分の意に沿わない部分があると問題に集中できないタイプだな 妙なこといいだすとおもったらまたそういうあれか
Janeやめたほうがええかしらん >>109の書くコードは読みにくそうだな
素直に書けばいいのに >>91
>プログラマはコードを読むときにいちいち日本語に置き換えません
意識してなくても自然に日本語に置き換えて理解していると思うのですが。
もし日本語に置き換えていないのなら「イフ」等も頭の中に浮かんでいないことになりますが
どのように理解しているのでしょう
もしかしてコードだけで会話できたりするのでしょうか?
>アメリカ人が英文を読むときに頭のなかで日本語に置き換えない
これは当たり前ですよね
「日本人が英文を読むときに頭のなかで日本語に置き換えない」
の間違えですか? >>119
そいつ、コード書かないから
仕様を上から下に投げるだけで金を貰える、私大文系プログラマだよ >>101
大手SIerだが、三項演算子は基本禁止だったな
三項演算子を使うなif elseを使え、if elseを使うときは中身が一行でも{}を付けろ
規約はガチガチに固めてあるよ
まぁ、守らない人もいっぱい居るけどね >>120
ifはプログラムの構成要素なのでそのまま理解すればよい
自然言語のifと混同しているようだが同じではない
--
そう当たり前の話
当たり前のようにプログラム言語はプログラム言語のまま読む
外国人だろうが日本人だろうがC言語を読む時にわざわざ母国語に変換して読んだりはしない
母国語に変換するのは対象言語に不慣れなビギナーだけ
英語を習いたての子供は日本語に変換して理解するが英語に慣れた大人は変換しなきても意味を理解できる
英語から即座にイメージがわいてくる
例えばC言語で
a[i++] = 0;
と書いてあった時にビギナープログラマは
配列aのi番目の要素に0を代入してiをインクリメントする
と自然言語に置き換えて読んでしまう
しかし熟練のプログラマは
a[i++] = 0;
とそのまま読んでそのまま挙動を理解する
その間に自分の母国語が頭の中に出てくることはない
それがC言語ネイティヴの思考方法
いちいち母国語に置き換えて理解していたら時間の無駄だし意味が曖昧化して間違えやすい
そして自然言語に置き換えにくいあるいは置き換えられないプログラミング要素を忌避するこおとになる
例えば三項演算子やλ式だ
母国語変換が必要なビギナーはこういうものを嫌うがプログラミング言語ネイティヴには全く抵抗感がない
母国語変換は低レベルな私大文系SEのやる事なのではやく卒業しよう > 108仕様書無しさん2018/04/19(木) 22:28:42.02
> 「引数は時間、返り値はvoid、引数が3600秒未満60秒以上なら分のみ出力、引数が60秒未満なら秒のみ出力せよ」
> って関数を作る場合
まだ言ってんのかこのヴァカ
判定する関数で、出力するとこまで関数に含めるな ボケナス
役割分担、いつになったら理解できるんだ 死ね >>124
ほんとelse以前の問題だよな
オールインワンを求めたりするのはプログラマとして致命的 else騒ぎが続いてるけども、何処よりもプログラマーの集うSIer界隈では、規約で三項演算子禁止。
正規表現も環境によって動きが変わるから多用は推奨されない。もちろん否定的先読みなどは禁止。
SQLも入れ子はダメだ。
実務の世界では分かりやすくないとダメなんだよ。
だからifとelseは大歓迎。
特に三項演算子・SQL・正規表現はSIerレベルのエンジニアでもよく分からない人が多いので、禁止事項が沢山設けられている。 >>127
だからお前らのプロダクトは特にユーザビリティの面において品質が低いんだよ。
おまえら、システムつくるためにシステム作ってるだろ? >>129
給料をもらうために作ってるよ。
給料をもらえればなんでもいい。 車の運転は難しいから車道全面禁止、歩行のみ許可みたいなもんか
頭悪いよなぁ
慣れれば車のほうが楽でしょ
長距離なら車が圧倒的でしょ
私大文系
ほんとバカ >>135
仕事を趣味と勘違いして
やりたいことをやりたいようにしかやらないヤツより
はるかにマシ。 >>136
結果ゴミを産出してたらカスなんだよなぁ
捉え方なんかどうでもいいからちゃんと動く成果物をあげてくれ >>137
おまえリアルで叱られた自分の欠点をそのままここで言っとるやろw Java使えなくてクビになった爺さんと初心者どもにはお似合いのスレだなw >>140
それも叱られたんかw焦りすぎやろお前w >>142
しつこいわw
おまえどっかいいとこあるんか?さすがの俺でもなかなか見つけられんでおまえのいいとこw >>144
ごめんけど、まず質問に答えて
なんでそんなに必死なんですか? >>146
おまえここでその3連荘はやばいやろw
客観的に言っておまえの必死の抵抗感やばいでマジにw
やばすぎて同情をかっちゃうレベルw
悪い事言わんからまず深呼吸してみろ?落ちつけ?な?w >>123
>熟練のプログラマは
>a[i++] = 0;
>とそのまま読んでそのまま挙動を理解する
それなら
if ( flg )
return "a";
else
return "b";
もそのまま挙動を理解できるわけで、else不要って主張するのはなぜ?
elseがあると挙動を理解できない? >a[i++] = 0;
この書き方悪いよ
int i = 0;
i++;
a[i] = 0;
と書くのが正解
可読性が大事なのよ。
関数でもそう、そのなかに処理がいくつもあると
可読性が悪い。 >>152
そのまま理解できるから無駄な記載を無くしたいんじゃねーか >>154
それが無駄じゃないんだよなぁ
例えばifの中がユーザーが男か女かのフラグだとして、男なら"タロウ"、女なら"ハナコ"を返す関数だとすると
if ( userInfo.IsMan() )
{
return "タロウ";
}
return "ハナコ";
if ( userInfo.IsMan() )
{
return "タロウ";
}
else
{
return "ハナコ";
}
上のコードは、男なら例外的に"タロウ"を返し、基本は"ハナコ"を返す、に見える
下のコートは、男なら"タロウ"、女なら"ハナコ"を返す、に見える
この2つの違いを見ればわかるように、elseには「これは例外パターンを扱う処理ではなく、並列した2つの処理を扱ってますよ」という意味を持ってる
elseには意味が有る、無駄ではない
(そもそも、無駄な記述を無くしたところでなんの意味も無いんだけどね、わざわざ消す方が無駄w) >>152
全くベクトル違う話題をそれならとか言って繋げるなよ
ちょっと軽率すぎるぞelser >>155
オカマは無視かよ
今それやったら差別的って怒られるぞ >>155
何度も言ってるが対等の場合は三項演算子が正解だよ
そろそろ理解してくれ
君が書いたif/elseバージョンの問題はreturn文をコピペしてる点ね
これは気が付きにくいけどDRYに反する粗悪なコードなんだ
return文という短い文だからif/elseでreturnを2回書いてもいいように勘違いしてしまう気持ちはわからなくもない
しかし一般的には文の長さはもっと長くなるかもしれないんだ
だから文は共有して差分がある式だけを三項演算子で切り替えるのが正解ってわけ >>157
オカマからマイナーの権利を取り上げる気かひどい差別主義者やな >>153
それな
熟練プログラマは挙動を理解すると同時に、書いた人間が老害かシロートだって理解する 初歩的なバグに気がつかない自称熟練プログラマーたちw >>158
この例は単純化してるから三項演算子でもできるけど、現実はそうじゃない
return に関数呼び出しがあったら
return flg ? <関数呼び出し>() : <関数呼び出し>();
なんて書くのか?
気持ち悪いだろ
さらにその関数に引数が必要ならどうするんだ?
オカマに対応しろって言われたら三項演算子をネストするのか?
お前の理想は汎用性に乏しいんだよ、コードを綺麗に保つのはソフトウェアを保守するためだって知ってるだろ >>162
良いコードだね
これを気持ち悪いと感じるのは君が未熟だからだよ
文を重複させるif/else方式のほうが遥かに汚い
if/elseは見た目も汚いけどそれ以上に論理的に汚い elserってさこういう類のコードをシンプルで読みやすいとかいって平気で書くよね
保守担当者に罪悪感とか感じないのかな
ほんと迷惑なんだけど
if (user.isMan()) {
String fmt = resourceManager.getMessage("INFO-001");
String msg = FormatUtility.format(fmt, user);
return "[INFO-001]: " + msg;
}
else {
String fmt = resourceManager.getMessage("INFO-002");
String msg = FormatUtility.format(fmt, user);
return "[INFO-002]: " + msg;
} いや違う
elserならこう書く
elserってさこういう類のコードをシンプルで読みやすいとかいって平気で書くよね
保守担当者に罪悪感とか感じないのかな
ほんと迷惑なんだけど
if (user.isMan()) {
String fmt = resourceManager.getMessage("INFO-001");
String msg = FormatUtility.format(fmt, user);
System.out.println("[INFO-001]: " + msg);
}
else {
String fmt = resourceManager.getMessage("INFO-002");
String msg = FormatUtility.format(fmt, user);
System.out.println("[INFO-002]: " + msg);
} あとメソッドをvoidにして参照渡しパラメーターを戻り値風にするとかな >>167
if (user.isMan()) {
String fmt = resourceManager.getMessage("INFO-001");
String msg = FormatUtility.format(fmt, user);
System.out.println("男性: " + msg);
}
else {
String fmt = resourceManager.getMessage("INFO-002");
String msg = FormatUtility.format(fmt, user);
System.out.println("女性: " + msg);
}
これとかだったらどうすん? そしてこれが美しいコード
if (user.isMan()) {
String fmt = resourceManager.getMessage("INFO-001");
String msg = FormatUtility.format(fmt, user);
System.out.println("男性: " + msg);
return;
}
String fmt = resourceManager.getMessage("INFO-002");
String msg = FormatUtility.format(fmt, user);
System.out.println("女性: " + msg); private String getMessage(String resourceId, Object arguments) {
String format = resourceManager.getMessage(resourceId);
return FormatUtility.format(format, arguments);
}
String resourceId = user.isMan() ? "INFO-001" : "INFO-002";
String message = getMessage(resourceId, user);
System.out.println(message);
--リソース--
INFO-001=男性: ...
INFO-002=女性: ... if文を排除しようとするとしばしば行き過ぎた一般化をもたらすことが証明された
if文が気に入らないからってリソースの情報定義までリファクタすんなし
print文の頭なんて何出すか一番変更かかりやすいとこ一緒くたにしたら扱いづらくてしゃーない 相変わらず elser は汚ねぇ下等コードを恥ずかしげ無くさらすな。
チンパンジーなんじゃないか? ウチならこうかなぁ
class ResourceManager
{
private ResourceValueMale="男性: INFO-001";
private ResourceValueMale="女性: INFO-002";
private ResourceValueMale="LGBT: INFO-003";
public static String GetValue(Sex sex){
if(sex==SEX_MALE)
{
return ResourceValueMale;
}
if(sex==SEX_FEMALE)
{
return ResourceValueFemale;
}
{
return ResourceValueLGBT;
}
}
}
class UserData
{
public static String GetResourceValue()
{
return ResourceManager.GetValue(m_sex);
}
}
System.out.println(user.GetResourceValue()); 2年ぐらい前に性別列をSexって命名したらコードレビューで新人の女の子にセクハラですかって真顔で言われた
ゆとりってこの程度の英単語も知らんのかね >>181
頭がマトモな奴はgenderを使うんだよ、ロートル 【貧困生活】無能残業は結婚障害【家事困難】
☆偽装請負多重派遣SE結婚相手の犠牲対策☆
両親や親戚に反対されましたが、偽装請負多重派遣会社に搾取金を提供したり時間外労働違反で家事をしないSEと結婚してしまい、生活困難で中絶と離婚をしました。現在は犯罪損害なく共働きも可能な相手と結婚して数億円損失を防げました。
・モラルがない
・キモい
・ファッションセンスがない
・コミュニケーションが苦手
・コンピューターが趣味
・プログラムの料金以上の不利益生産
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・プログラムの知的財産を人売に提供
・ITスキルが高いのに低料金請求
・高度情報処理技術者なのに請求料金不足
・高利益なのに請求料金不足
・高生産なのに請求料金不足
・高需要なのに請求料金不足
・学習多いのに請求料金不足
・人員不足なのに早期退職
・会社員なのに早期退職
・PC使用過多で不健康
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難
・低収入なのに鬱病多発
・低収入なのに早死多発
・不利益なのに断らない
・偽装請負の多重派遣損害あるのに稼働
・裁判官が技術判断不能だから賠償困難
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf >>184
sexは肉体的な意味での性別
genderは社会的な意味での性別
これらは別のものだから適切に使い分ける必要がある
何も考えずにgenderを使うんだよ、なんて発言は無知を表明する行為にほかならない >>187
肉体的意味にLGBTなんかあるか、バーカ
思いも至らなかったくせに後付けで苦しい言い訳すんなよ、カス
大体、肉体的な問題を答えさせるケースなんか、殆どねぇよ、ノータリンロートル >ゆとりってこの程度の英単語も知らんのかね
自分が馬鹿なだけという事に全く気付いていない老害 >>188
なんも理解してないんだな
なんかここまでくるとかわいそう >>179
スマホで適当に書いたんだ、それくらい許してよ
>>180
いつもIDEに頼り切ってるゆとりだよ、オレは >>190
6869 だね、このCPUなんとかして手に入れたいんだが sexとか使うヴァカって、若手女性社員のに「置換して」とか言ってそう。
頭悪いSIに多い、そういう無思慮な奴。 >>194
アキハバラのビープなどでFM-7を手に入れれば、あるいは・・・ ■ このスレッドは過去ログ倉庫に格納されています