底辺プログラマぼく「2つの値を足し合わせる関数か………tasizan関数でw」
■ このスレッドは過去ログ倉庫に格納されています
tasizanじゃねえよ。tashizanだろがボケ!!! プログラマって勉強すること多くね?
大変なお仕事じゃね? あのさぁいちいち関数作るなよ
ガキじゃねえんだからさ! 天才俺「calcクラスにtashizanメソッドを作成っと!」 高学歴プログラマーぼく「plus(x, y) = x+y」 結構ローマ字日本語にしてるところ多いよな
IT業界ってそういうもんなの? >>13
作った奴がバカか、色んな人がコードを読む可能性を考えてバカでもわかるようにしてあるかじゃね >>13
xxx区分
-> xxxKBN
はああああああ???
死ねや!!! 関数名決めなきゃ…「比較 英語」
変数名決めなきゃ…「部署 英語」
英訳が2単語になるときは必死に言い換えを探す >>17
KBNめっちゃあるよな!なんなんだあれ!
プログラマじゃないからソースコードなんて数社ぐらいしか見てないけど絶対日本のIT企業で何かルールを広めた集団いるわ! 一時的に利用する変数だからxxx_tmpにするか…
これは雛形として使い回す定数としてxxx_tempにしとくか… >>23
アブジャドだろ
ktkrとか書いたことの無い者のみ石を投げよ
FとかFLは良い?
なおそれらの変数は整数型で定義されていて、その内の1つは0と-1以外に1も定義されていた >>23
でもまあ、他にやりようないんだよねw
カテゴリ?
クラス?
タイプ?
あたりかもだけど、それはそれで、そういう別物がいたりするからな・・・
品目カテゴリ matcat
品目クラス matcls
品目タイプ mattyp
品目区分 mat・・・kbn
だから、変に拘らず、区分はkbnっての、わからなくもないw hoge関数hogehoge関数
hogehogehogehoge tsznだな
日立ルールじゃローマ字で母音は除く、だぞ
キガクルットル 普通に
i = i + hoge
でいいんじゃないのか? >>27
typeとかclassとかkindとかじゃね >>36
品目区分だったら、hinmoku_kubun???
なんか、まあ、そういうところもあるのかな
オジサンは見たことないけど 無能ぼく
すべて英語にしたことによって
見返したときにわからなくなる >>41
流石にその量の英単語は覚えろよ
てか覚えるだろエアプだけど >>42
似たような言葉ばっかで微妙
日本語でも間違うやついるのにってレベルの量と単語 マクロでよくね
#define tanashin(x, y) x+y
これがダメな理由を述べよ(配点:3) >>45
仰せの通りでございますが規約を決めて保守する担当がいないと 現場で作り込みするとネット辞書使えないから日本語だらけになる ここ数年はcodicってサービスで適当に変換して付けてる
明らかに変なやつは手直しするけど >>8
calcクラスってただの便利クラスだろ
そこから仕様も読めないしドメイン欠乏も甚だしいな >>44
tanashin(2, 4) / 2 = 4 でも英訳しづらい言葉に出会うこともあるよな
運行情報とかどうするか悩む >>51
diaInfoとかtrafficInfoとか? お前ら当たり前のようにプログラミング出来んのかすげぇなぁ >>4
勉強なんて思ってたら続かない
最近の技術トレンドとか新しい言語とかってのは、今期のアニメって何を見てる?
くらいの感じで普通にチェックして普通にプログラマ同士で雑談するくらいの興味がないとキツい 返信にResponseMessageって命名するくらいなら
Henshinのが楽になることはある >>1は和の頭文字とってwで良いんじゃないかという提案をしているのでは ■ このスレッドは過去ログ倉庫に格納されています