長い関数名をつける奴は技術力が低い [転載禁止]©2ch.net

**仕様書無しさん** · 2014/11/08(土) 12:28:11.13

汎用的な関数は短い名前。汎用的じゃない関数名は長くなる。

そういう関数はコードの中を見ないと何やってるかわからない。
名前と簡単な説明だけでは理解できない単なるルーチン。

複雑な機能の関数しか書けないから、その説明である関数名も長くなる。

※名前空間がない言語で、名前空間的に使わざるを得ない場合は除く。

**仕様書無しさん** · 2014/11/08(土) 13:13:31.56

せっかくスレを立てたのに２ゲットすらされない……
そんな悩みを抱えてらっしゃいませんか？
ご安心ください！クソスレ２ゲットサービスです！

**仕様書無しさん** · 2014/11/08(土) 15:07:10.23

書いた本人しかわからないような略語を使われるよりは省略しないほうがずっとマシ

**仕様書無しさん** · 2014/11/08(土) 15:09:44.52

>>3
誰も省略しろなんて言ってないだろ。

document.getElementsByTagName() みたいな長い名前の話だろ

**仕様書無しさん** · 2014/11/08(土) 16:35:22.51

俺の場合、関数名は長く、変数名は短い

**仕様書無しさん** · 2014/11/08(土) 21:56:32.45

>>4
タグ名をキーとして要素のリストを取得する
何も問題ないだろ…

**仕様書無しさん** · 2014/11/08(土) 22:02:28.21

>>6
どんだけ入力遅いんだよｗ

普通はtabで候補を選んでる間に入力してしまうって。

**仕様書無しさん** · 2014/11/08(土) 22:16:41.42

>>4
あるねえ
おまけにスペルが間違ってたりして失笑モン

**仕様書無しさん** · 2014/11/08(土) 23:27:01.51

>>8
お前だったらなんてメソッド名つけるの

**仕様書無しさん** · 2014/11/08(土) 23:54:48.41

jQueryとかで$(セレクタ)みたいなのが流行ってるけど、
もしセレクタで引っ張ってくるというアイデアを思いつかなかったとしたら、
getElements(条件) かな。もしくはfindElementか、単にfindとか。

メソッド名は大した問題じゃなくてキモは条件だな。
条件にはオブジェクトが入る。 { tag: 'SPAN' } みたいに。
つまり、 getElements({ tag: 'SPAN' }) これなら
Byなんたらを大量に作らなくても一つのメソッドで
いろんな条件から引っ張ってこれる。

もしくはSQLみたいな簡易言語を作っていたか。
まあセレクタはその簡易言語みたいなものなんだけど。

**仕様書無しさん** · 2014/11/09(日) 00:11:45.95

つかjavascriptってメソッドのオーバーロードできるんだっけ。

switch使うとかいうなよ

**仕様書無しさん** · 2014/11/09(日) 00:45:49.96

>>11
switch？

オーバーロードって引数の型と数の違いで、
実行する処理を変える機能じゃなかったっけ？

オーバーライドと間違ってない？

**仕様書無しさん** · 2014/11/09(日) 00:54:57.19

え

**仕様書無しさん** · 2014/11/09(日) 06:23:31.34

>>12
え？

**仕様書無しさん** · 2014/11/09(日) 09:35:22.94

>>11
getElements({ tag: 'SPAN' })

>>10は見ての通り、引数に連想配列を取っている。
お判り頂けただろうか。

**仕様書無しさん** · 2014/11/09(日) 10:35:51.79

オーバーロードでやろうと思ったら、
引数にSPAN文字列ではなくて、
SPANオブジェクトを渡せって話になるのか？

こんな感じ？
getElements(createSpanElement())

SPANかつ.classの場合とかどうやって書くつもりなんだろう？

オーバーロードでやるとかセンス無いと思うわーｗ

**仕様書無しさん** · 2014/11/09(日) 11:04:29.39

>>10はオーバーロードなんて話はしてないよ。
>>11が条件の変化を表現するために、オーバーロードを使うって勘違いしたんだろう。

**仕様書無しさん** · 2014/11/09(日) 11:13:12.22

getElements({ tag: 'SPAN' })
getElements({ class: 'email' })
getElements({ name: 'user01' })

↑は何が戻ってくるか大体想像が付くけど

↓こういう入力にはどう対処するつもりなのか、

getElements({ tag: 'SPAN', class: 'email' })
getElements({})

**仕様書無しさん** · 2014/11/09(日) 11:16:36.01

>>18
特に問題無いと思うけど。
SPANタグでemailクラス持ってるエレメント返せば良いじゃない。

**仕様書無しさん** · 2014/11/09(日) 11:32:20.14

Byなんたらにしておけば
そんな必要もないものわざわざ実装しなくて済むのに。

**仕様書無しさん** · 2014/11/09(日) 11:36:21.57

tag と class どっちを先に絞り込むつもりなんだろう。
遅い方だとヤだなあ。

**仕様書無しさん** · 2014/11/09(日) 11:43:54.70

>>21
getElements([
{ tag: 'SPAN' },
{ class: 'email' }
])

**仕様書無しさん** · 2014/11/09(日) 11:44:45.89

想定しないものがわたってきたら何返すつもり

**仕様書無しさん** · 2014/11/09(日) 11:46:09.35

例外

**仕様書無しさん** · 2014/11/09(日) 11:47:45.36

そしてどんどん複雑になる仕様…

**仕様書無しさん** · 2014/11/09(日) 11:49:47.39

セレクタとかxpathがあって良かったね

**仕様書無しさん** · 2014/11/09(日) 12:04:25.59

おい>>1よ、

> 複雑な機能の関数しか書けないから、その説明である関数名も長くなる。

jQueryのセレクタって、複雑だけど関数名短い（ってか無い）じゃねーか。
どういうことだ。

**仕様書無しさん** · 2014/11/09(日) 15:43:33.49

>>27
ここでいう複雑っていうのは機能の多さだよ。
jQueryのセレクタは単機能だからシンプル。

一回の呼び出しで、同時に複数の処理を行うことが
複雑ってことなんだ。

**仕様書無しさん** · 2014/11/09(日) 16:31:06.88

書いた本人しかわからないような以下略

**仕様書無しさん** · 2014/11/09(日) 21:02:29.03

スペルミスしてるのは後々恥ずかしい

**仕様書無しさん** · 2014/11/09(日) 21:06:04.28

>>28
> ここでいう複雑っていうのは機能の多さだよ。
だからgetElementsByTagName()よりも機能多いよね

**仕様書無しさん** · 2014/11/10(月) 01:01:59.53

>>31
だからそういう話じゃないんだって、
頭悪いなぁ。

**仕様書無しさん** · 2014/11/10(月) 22:52:44.32

必殺技アタマガワルイナー
今日も見る事が出来ました

**仕様書無しさん** · 2014/11/10(月) 23:06:04.47

イチガイニハイエナイ
大抵の必殺技を無効にする呪文だ

**仕様書無しさん** · 2014/11/11(火) 06:00:10.59

必殺技ソレハヘリクツダ

**仕様書無しさん** · 2014/11/11(火) 07:12:32.01

魔法少年ブチドキュン
ツキが変わってオチなしよ

**仕様書無しさん** · 2014/11/11(火) 12:38:31.68

>>27
>jQueryのセレクタって、複雑だけど関数名短い（ってか無い）じゃねーか。
$が関数名なんだが。

**仕様書無しさん** · 2014/11/11(火) 12:48:48.83

jQueryのセレクタは関数名こそ短いけど、その分引数が複雑になってるから

**仕様書無しさん** · 2014/11/17(月) 08:22:21.92

英語にしなくていい
日本語使えるなら日本語関数にしてくれ

**仕様書無しさん** · 2014/11/18(火) 02:50:34.55

送り仮名の揺らぎがあるからヤダ。

**仕様書無しさん** · 2014/11/18(火) 07:15:15.38

accessは昔から日本語使えたので日本語の関数しか見たことなかった
便利なんだが全角カッコありの関数名とかどういうことだよ

**仕様書無しさん** · 2014/11/21(金) 08:13:24.87

スペルミス関数使うくらいなら、日本語関数で定義してほしいんですけど

**仕様書無しさん** · 2014/11/22(土) 12:02:06.28

生涯収入３億以下の貧乏人へ
利益少なすぎ商売下手すぎ
分量減らすか収入増やせ

**仕様書無しさん** · 2014/11/22(土) 12:25:24.10

つーか

日本語関数さいきょー！
日本語変数さいきょー！

どーせ日本でしか動かさないソースなんだから日本語さいきょー！

**仕様書無しさん** · 2014/11/23(日) 10:39:09.94

スペツミス関数が御返還関数になるだけ。

**仕様書無しさん** · 2014/11/24(月) 12:54:37.66

doc.gtElmByTgNm

**仕様書無しさん** · 2014/11/24(月) 13:40:15.91

VS

$('#ID') 　　（jQueryの場合）

これだけで実にわかりやすい。圧倒的ですな。

**仕様書無しさん** · 2014/11/24(月) 19:04:31.14

SEに早死にが多い理由
テレビ、パソコンを1日４時間以上利用すると死亡リスクが2倍に!
http://googirl.jp/lifestyle/157terebipc632/

**仕様書無しさん** · 2014/11/26(水) 23:06:01.76

>>47
フロントエンドばっかやってるとこういう単細胞馬鹿になる

**仕様書無しさん** · 2014/11/29(土) 04:22:08.68

その理由を書いてない時点でつかないなこいつ

**KAC** · 2014/12/29(月) 22:27:57.29

>>1
> 複雑な機能の関数しか書けないから、その説明である関数名も長くなる。

そういう訳でもない。

話題に出てる
document.getElementsByTagName()
なんかは、getElements　だけだと複雑になりがちなので
ByTagNameというように特化して機能を単純化してる。

機能を誤解なく伝えるために長い名前にするのはよくあること。

関数の複雑さと関数名の長さにはさほど関係は無いよ。

**仕様書無しさん** · 2015/01/05(月) 22:00:21.85

Microsoftのことですね分かります。

**仕様書無しさん** · 2015/01/25(日) 18:22:47.83

よく使うのは短く。
ほとんど使わないのは、説明するために長くなる。

**仕様書無しさん** · 2015/03/15(日) 16:43:52.10

jQueryというかJavaScriptは
変数名や関数名の長さがパフォーマンスに響くとか聞いたことがある
ホントかは知らない

**仕様書無しさん** · 2015/04/03(金) 22:24:55.53

>>54
スクリプト言語だからな。

**仕様書無しさん** · 2015/04/03(金) 22:26:07.11

>>54
とはいえ、どうでもいいレベルの差だよな。

アホプログラマが言いそうなこと。

**仕様書無しさん** · 2015/04/06(月) 13:37:55.17

>>1は正しいと思う

SRPが守られていれば、クラスやメソッドの名前は
見て思わず射精するくらい、短くなるわな

**仕様書無しさん** · 2015/04/06(月) 22:21:36.79

>>57
関数と言っているのだから、普通はオブジェクト指向言語じゃないだろ。

**仕様書無しさん** · 2015/04/07(火) 20:08:15.54

メソッドの名前で射精するﾎﾓｸﾞﾗﾏｰのちんこ舐めたい

**仕様書無しさん** · 2015/04/10(金) 07:34:49.45

たかだか文系の四則演算程度しか使わないシステムで慌てふためいて残業とか、
お前ら人間として恥ずかしくないのかい?w
オレだったら恥ずかしくて人間を名乗れないなー
「実はオレ、チンパンジーとの雑種なんですw」(だから頭悪いの仕方ないでしょ?勘弁してw)と言うねw

こんな程度の小学生レベルのシステムでてこずってたら、
物理エンジンの開発とかまずもってお手上げだろうなw
光の反射の計算や、それによってオブジェクトの表面がどう変色するかや、光沢の強弱計算など
うんざりするほど数学を駆使しないとできないからねーw

**仕様書無しさん** · 2015/04/10(金) 07:54:08.54

食っていけりゃなんでもいいよ

**仕様書無しさん** · 2015/04/11(土) 01:47:03.80

>>60
四則演算はシステムの中心にないんだよ。
そんなもの実はシステムの中ではどうでもいいことで、
そういう点しか見れてないお前はまだまだあって事さ。

ヒントを言うのなら、100ピースのパズルはたいして難しくないが
1000ピースのパズルはとたんに難しくなるのと同じ
量が10倍に増えたから時間も10倍でできる。
と思ったらそれは大間違い。もっとかかる。

小さなところだけ見て、簡単だって言ってるようじゃ
何もわかってない。

**仕様書無しさん** · 2015/04/11(土) 08:19:27.04

>>62
残業やめろを言いたいだけ

**仕様書無しさん** · 2015/04/11(土) 08:43:04.79

文系の四則演算とは

**仕様書無しさん** · 2015/04/11(土) 08:50:37.12

社員番号から社員名を取得する(引数）
社員名から社員番号一覧を取得する（引数）

と日本語でやる俺最強！

**仕様書無しさん** · 2015/04/11(土) 11:21:55.31

>>63
じゃあ「残業をやめろ」の5文字だけ書けよｗ

**仕様書無しさん** · 2015/04/11(土) 18:08:22.27

長さに文句をつけるとか相当クソみたいな開発環境なんだな

**仕様書無しさん** · 2015/04/11(土) 19:15:31.46

あぁ、君はきっと補完できるからタイピング速度が遅くても
問題ないっていいたいのだろう。
タイピング速度は重要じゃない。

なぜならコードは書くよりも読むことのほうが
何倍も多くて何倍も重要だからだ。

さて聞きたいが、長いコードは読むのに時間が掛かる。
開発環境が優れているとどう読むのが楽になるのかね？

**仕様書無しさん** · 2015/04/11(土) 21:04:47.16

>>68
func_A
func_B
より
>>65の関数名のほうが

あっという的に読みやすい

**仕様書無しさん** · 2015/04/11(土) 22:04:44.69

長いメソッド名はcode smell
ってのは当たり前なんだが
日本だけまたガラパゴスなのか？

**仕様書無しさん** · 2015/04/11(土) 22:51:05.34

>>70
だからメソッドと関数は違うと言ってるだろ？

**仕様書無しさん** · 2015/04/12(日) 03:15:04.40

>>69
> 社員番号から社員名を取得する(引数）
> 社員名から社員番号一覧を取得する（引数）

これって英語に直すと、

employe.get_name_by_id(id)
employe.search_number_by_name(name)

だろ？

employe.get('name', {id => id})
employe.search('number', {name => name})

の方がいいよ。返す項目、条件、それらを引数で指定するから
例えば返して欲しいのが名前じゃなくて住所であっても対応できる
（普通は名前を返すのも住所を返すのも処理の大半は同じ）

で、メソッド名だが、getとsearchで短いわけだが？

こ・れ・が、技術力！（笑）

72 · 2015/04/12(日) 03:16:44.54

>>71
なんか俺にまで違うって言われそうだから
メソッドじゃなくて関数で書き直すわｗ

get_employe_name_by_id(id)
search_employe_number_by_name(name)

get_employe('name', {id => id})
search_employe('number', {name => name})

単の文字を入れ替えただけだがｗ

**仕様書無しさん** · 2015/04/12(日) 04:28:53.61

findで単一、selectで複数がキモチイイ！

**仕様書無しさん** · 2015/04/12(日) 08:18:38.29

employe.get('name', {id => id})

nameと打たないとだめ。
idの変数名がunkoだったら意味わからん。

ところが、関数で
　社員番号から社員名を取得する()
　employe.get_name_by_id()
になってれば名前から処理が推測できる。
よって後者のほうがいい

**仕様書無しさん** · 2015/04/12(日) 08:22:17.46

employeではなく、employeeを使うのが普通。

**仕様書無しさん** · 2015/04/12(日) 08:36:07.49

>>73
employee_number なのか idなのかはっきりしろｗ
無理に英語にしようとするから、統一性がなくなる。

**仕様書無しさん** · 2015/04/12(日) 08:59:55.81

>>72
なんかテキストの一部だけを切り取って覚えたみたいな感じだなｗ
get()、search()、set()
だけで取得や検索、設定をやるとして、同じ取得に関しての処理で処理が違ったら全部引数で判断するのか？ｗ
マニュアル読む側はめんどくせぇｗ

**仕様書無しさん** · 2015/04/12(日) 09:01:00.51

例えば既存関数(XXX)の拡張用に関数増やす場合
関数の末尾にXXXForYYY()って名前はおかしいかな？
関数というかメソッドって英語構文のSVOCとか意識しちゃうんだけど

**仕様書無しさん** · 2015/04/12(日) 12:01:08.55

>>77
この指摘は、極めて重要な指摘。
英語圏の連中ならnumberとidとemployeeIDとemployeeNumberとは、意識せずにきちんと統一された状態で実装してくる。
英語圏でない不慣れなやつが気取って英単語使おうとすると、統一がとれていないことにすら気づかない。
結局、idとは？numberとは？employeeNumberとは？employeeIDとは？それぞれ違うの？？？？？？？という無駄な疑問と調査作業が生まれる。
で、すべて英単語で来るのかと思うと急にローマ字だったり、意地で英単語で実装してくると専門用語は機械翻訳の英単語を使ってくる。
そんなめちゃくちゃなのばっかり。
そういう意味では>>65のように日本語OKな環境ならばアレルギーを抱かず日本語使ったほうが日本人プログラマには極めて有効。
大抵の日本産プログラムなんて外に出ることは無いのだから。

**仕様書無しさん** · 2015/04/12(日) 12:35:43.95

確かに、変な英語メソッド名より長い日本語メソッド名の方がマシだな

**仕様書無しさん** · 2015/04/12(日) 12:40:46.78

日本人なのに英語の関数名をつける奴は技術力が低い

**仕様書無しさん** · 2015/04/12(日) 15:01:02.55

>>80
> この指摘は、極めて重要な指摘。
> 英語圏の連中ならnumberとidとemployeeIDとemployeeNumberとは、意識せずにきちんと統一された状態で実装してくる。

それはIDに相当する日本語がないのが問題。
日本語を使っている限りこの問題は無くならない

**仕様書無しさん** · 2015/04/12(日) 15:02:11.51

つまりドキュメントに「社員番号」って
書かないようにしないとだめってことだな

**仕様書無しさん** · 2015/04/12(日) 15:04:04.06

>>80
> そういう意味では>>65のように日本語OKな環境ならばアレルギーを抱かず日本語使ったほうが日本人プログラマには極めて有効。

つまりデータベースのキーは「番号」ってこと？

idってつけたいけど日本語使うんでしたよね（・∀・）ﾆﾔﾆﾔ

**仕様書無しさん** · 2015/04/12(日) 15:58:50.22

'empl_ID DBキー（empl_NO、empl_NUMも同様）
'empl_CD 従業員コード
'empl_SEQ 並び順
'empl_i ループカウンタ
'empl_NIL ヌル変換用（const '@@@'）
'empl_SYACHO 社長のとき（const '00001'）
'empl_KYOUTU パートさんのとき（共通社員コード const '09000'）
'empl_TAKEDA 武田部長のとき（const '00031')
'empl_ZZZ 新入社員のとき（const '99999'）

な？丁寧やろ？

**仕様書無しさん** · 2015/04/12(日) 17:15:34.39

>>86
冒頭の'って何？

**仕様書無しさん** · 2015/04/12(日) 17:22:35.47

>>85
IDは、100人に聞いて95人くらいは十分日本語で通じますｗ
Employeeは１００人に聞いて40人がいいとこでしょう。
柔軟性の無いバカですねｗ。

**仕様書無しさん** · 2015/04/12(日) 17:41:48.90

IDって日本語に無理に訳すと「識別子」だと長年思ってた

IDに相当する日本語がないという問題をなんとかせねば！

**仕様書無しさん** · 2015/04/12(日) 17:42:31.82

社員識別子

**仕様書無しさん** · 2015/04/12(日) 17:47:39.32

>>89
人定

**仕様書無しさん** · 2015/04/12(日) 17:50:20.75

>こ・れ・が、技術力！（笑）

というか、コレが技術力？　の間違いだろ？？？？？？？？？？？？？？？？？？？？？？？？？？？
どんだけレベルの低いところで小山の大将やってんだ？？？？？？？？？？？？？？？？？？？？？？？

**仕様書無しさん** · 2015/04/12(日) 17:53:45.63

>>92
文句言うだけならだれでも出来るんですよ（笑）

**仕様書無しさん** · 2015/04/12(日) 17:55:08.85

>>72で大漁だなｗ

**仕様書無しさん** · 2015/04/12(日) 18:10:37.70

日本のプログラミングってすぐにSEARCHが出てくる
どんだけSEARCH好きなんだよｗ
たまにSERCHって凶悪なのも

GETも多い
とりあえずなんでもGET

迷ったら「サーチアンドゲット！」って唱えよう

**仕様書無しさん** · 2015/04/12(日) 18:40:26.20

>>95
別に英語でも出てくるけど？

**仕様書無しさん** · 2015/04/12(日) 19:56:13.05

英語圏の翻訳本を読んで技術力を身につけた気になっちゃって世間に披露したけど世間はもっと上を行っていたという盛大なオチ?

**仕様書無しさん** · 2015/04/12(日) 19:57:35.93

>>91正確には人定事項だな

**仕様書無しさん** · 2015/04/12(日) 20:40:32.61

>>73
わっかりづれー
使いたくないAPIだなぁ

**仕様書無しさん** · 2015/04/12(日) 20:48:30.05

などと罵倒するのが精一杯（笑）

**仕様書無しさん** · 2015/04/12(日) 21:18:29.98

>>87
VBのコメント。
てか、変数名の事書いてたわ。関数名はこんな感じ。

'****************************************
'社員別処理関数
'作成：2015/4/1 yaruo
'概要：社員別の処理を行う
'****************************************
Public Sub Syain_Proc_0010(syain_id As String, option_param1 As String)
On Error GoTo error_proc
Dim empl_ID As String 'DBキー（empl_NO、empl_NUMも同様）
Dim empl_CD As String '従業員コード
Dim empl_SEQ As String '並び順
Dim empl_i As String 'ループカウンタ
Dim empl_NIL As String 'ヌル変換用（const '@@@'）
Dim empl_SYACHO As String '社長のとき（const '00001'）
Dim empl_KYOUTU As String 'パートさんのとき（共通社員コード const '09000'）
Dim empl_TAKEDA As String '武田部長のとき（const '00031')
Dim empl_ZZZ As String '新入社員のとき（const '99999'）
If option_param1 = "1" Then
'本社のとき
ElseIf option_param1 = "2" Then
'支店のとき
End If
Exit Sub
error_proc:
End
End Sub

「～_Proc_連番」が最強

**仕様書無しさん** · 2015/04/12(日) 21:23:27.98

ちなみに
関数の中で他の関数を勝手に呼んではならないという縛りがある（ごくまれな例をのぞいて）
このため1つの関数が数千行になる
プログラムの行数が長ければ長いほど仕事を頑張ったと評価される

**仕様書無しさん** · 2015/04/12(日) 21:26:42.88

コードの行数は長いほうが良いけど
変数や関数の名前が長いとNGをもらう
8文字程度、長くて10文字
横方向にコードがモニタからはみでたら好感度-1。

**仕様書無しさん** · 2015/04/12(日) 21:32:56.87

ああ
101の関数名がすでに10文字超えてたわｗ
もううろ覚えだから適当だけど、個ぼらーの上司はこんな感じの規約を作ってたわ
デザパタ本読んで意気込んでたあの頃の俺は馬鹿にしていたが
今では規約を作ってちゃんと守ってるだけよほどマシな人だったと反省している

**仕様書無しさん** · 2015/04/12(日) 23:26:08.45

>>102
冗談としてもつまらんぞ
そんな仕事で金がもらえるのは公務員のお偉いさんに仕える企業だけ

**仕様書無しさん** · 2015/04/13(月) 00:32:17.40

>>102
そこまで来るとバカバカしさを通り越してクールだな

**仕様書無しさん** · 2015/04/13(月) 00:37:13.59

>>96
頻度や登場ｺﾝﾃｷｽﾄのﾊﾅｼです

**仕様書無しさん** · 2015/04/13(月) 00:55:20.50

>>102
階層が浅くなって手続型な書き方になるから普通に悪くないと思うぞ
規模次第ではその方式が良い場合もある

**仕様書無しさん** · 2015/04/13(月) 01:28:56.82

>>108
いやー、それはないわｗ

関数の正しい使い方を知らない人が多いだけって
最近わかった。

関数をつくったら複雑になるのは
コードが長いからまとめるぐらいにしか考えてないから。
役割ってのを全く考えてないんだよね。

**仕様書無しさん** · 2015/04/13(月) 02:33:07.26

分かりやすい名前を付けるという行為は文系チックな能力が必要だから
よくいる理系のプログラマには向いていないんだよなあ。

これはしょうがない

**仕様書無しさん** · 2015/04/13(月) 20:07:59.32

>>109
関数の正しい使い方なんて実務歴１０年以上あるけど未だにわからんよ
考えれば考えるほど分らん

**仕様書無しさん** · 2015/04/13(月) 20:48:58.52

客が要件でなんからの用語を提示してきたら
変数にはその名称と同じにしろ。

例えば、お客様番号だったらCustomerIDじゃなくてそのまま命名するんだ。

**仕様書無しさん** · 2015/04/13(月) 21:03:54.86

日本語もアリっちゃアリ

**仕様書無しさん** · 2015/04/13(月) 22:56:12.19

>>108みたいなことstackoverflowで書いたら、マイナス-10くらい平気で食らいそうｗ

そもそも今時unit testしないのかよ！って怒られるだろうね
>>102で良いとか、日本のプログラミング文化はマジで世界から１０年以上遅れてるわな

**仕様書無しさん** · 2015/04/13(月) 22:57:22.77

20年に訂正しろボケ

**仕様書無しさん** · 2015/04/13(月) 22:57:30.88

マイナス-10じゃすまないな
-100くらい行ってもおかしくないレベル

**仕様書無しさん** · 2015/04/13(月) 23:06:05.99

学生かな？歴戦のブラック戦士からするとそんなの別にどおってことないぞ

**仕様書無しさん** · 2015/04/13(月) 23:12:12.37

何がどおってこと無いんですか。
底辺でもいいじゃないかってことですか？

**仕様書無しさん** · 2015/04/13(月) 23:52:36.80

郷に入ったら郷ひろみと言ってだな
コーディング規約程度でネガるならエンジニアとしての腕が知れているという事
問題の本質はそんなところには無い

**仕様書無しさん** · 2015/04/13(月) 23:56:57.67

コーディング規約って、ツール導入して、
設定するだけだろ。

後はそのツールを流して指摘されたところを直すだけ。
単純な作業なんだが、

まさか、いちいち人間がチェックしてないよね？

**仕様書無しさん** · 2015/04/14(火) 04:53:54.26

>>108
他所の関数呼ばれると読み解くのに時間がかかるって発狂する上司だった
上から下にスクロールしていって1000行でも2000行でも止まることなく１本グソのごとき美しさを持ってないとNG

ここから導き出されるのは
関数やクラスというものは半端な気持ちでポンポン作ってはならないという戒め

2ヶ所以上から呼ばれる、いわゆる「再利用可能部品」が生まれるのは「プロジェクトの一大事件扱い」だった

おもしろいやろ？

**仕様書無しさん** · 2015/04/14(火) 05:17:30.56

まあ、思い出補正入ってるから「作り話」として聞いてくれ。

時代の曲がり角で気持ちよく直進方向に突っ走っていったおっさんだった。
俺ら若い人間はオブジェクト指向まっさかりの時代で育ったから
影で悪口言いながらあいつの流儀をみっちり叩き込まれた。
実際それで仕事が回る。先輩達もそうやって育ったらしく、統制は取れていた。
結果、俺たちの部署のソースコードが一番改修のレスポンスが早かった。

そのプロジェクトの関数の命名規則が、「XXXX_Proc_連番」だったんだ。

これをどう評価するのかはおまいらにまかせる。
俺は部下にすら信念を持って説明できないヘタレだからな。
あのおっさんと違って。

**仕様書無しさん** · 2015/04/14(火) 09:33:43.33

>>122
ま、結果が出ればなんだっていいよね
趣味でやってるわけじゃないんだから

**仕様書無しさん** · 2015/04/14(火) 10:41:59.76

>>112
これはあるね。

**仕様書無しさん** · 2015/04/14(火) 16:31:57.51

うちでもアルファベットから日本語への切り替えは賛否あったけど
数年経ったら、「なんでアルファベットにこだわったんだろう？」って状態になったよ

**仕様書無しさん** · 2015/04/14(火) 19:39:11.28

ある程度の腕になると>>121も>>122も>>125も　どうって事はなくなる
なぜギャーギャー騒ぐのか？坊やだからさ

**仕様書無しさん** · 2015/04/14(火) 19:41:31.90

もっと経験を積め、どんなやり方だろうがそれで会社が回っているならいいんだよ
やり方を変えてもし失敗したら責任自分が持つっていう覚悟なら一石を投じなさい

**仕様書無しさん** · 2015/04/14(火) 22:11:26.61

>>121
一本グソの美しさ・・・ってw

**仕様書無しさん** · 2015/04/15(水) 11:19:40.00

結局>>1が無能だったの？

**仕様書無しさん** · 2015/04/15(水) 12:13:44.99

Egirls_team_Dream();
Egirls_team_Happiness();
Egirls_team_Flower();

**仕様書無しさん** · 2015/04/15(水) 19:36:34.59

>>129
ふつうに無能に見える
こんな小さい事でガーガー言ってるレベルだろ
上を説得できる能力もないし、どんな理不尽な条件でもやっていく順応性もない

**仕様書無しさん** · 2015/04/15(水) 21:46:00.06

>>131
おい、理由が全く書いてないぞｗ

お前の言うことに説得力がないじゃないか

**仕様書無しさん** · 2015/04/16(木) 01:09:27.86

GetElementByName ←レベル低い

**仕様書無しさん** · 2015/04/16(木) 03:48:53.90

GetElementsByName

**仕様書無しさん** · 2015/04/16(木) 06:46:38.57

自分が読んだ本と違っていたら指摘して非難する

という短絡的な思考パターンの人なんだと思う>>1は
非常に社会にとって害

**仕様書無しさん** · 2015/04/16(木) 07:37:01.04

これ>>1を肯定してる書き込みって全部>>1じゃね？

**仕様書無しさん** · 2015/04/16(木) 07:41:04.07

というかこの>>>1は例のバカだから

**仕様書無しさん** · 2015/04/16(木) 21:00:00.28

>>1　
これらの書き込みを見ろ
お前に反論しているやつが大半だ。
わかったか。

**仕様書無しさん** · 2015/04/17(金) 17:43:05.07

スレを立てる度、毎回否定される>>1
(ヽ´ω`)不憫といえば不憫
でも社会に出てこようとしないでね

**仕様書無しさん** · 2015/04/19(日) 10:24:11.49

ズレてるんだよな…理解が
まあ致命的なズレなんだが。

**仕様書無しさん** · 2015/04/19(日) 18:10:00.60

でもいい負かせられないから
ちょっと苛つくよねｗ

**仕様書無しさん** · 2015/04/20(月) 09:02:24.77

>>141
盲信してしまっていて、他人の言うことを素直に受け取れない人は言い負かす云々以前で
措置入院させるべき対象

**仕様書無しさん** · 2015/04/20(月) 12:55:32.65

>>1の古傷に触れるな

**仕様書無しさん** · 2015/04/20(月) 15:39:53.38

>>1に言い返せ！

**仕様書無しさん** · 2015/05/13(水) 18:24:35.76

bool KorehaIntWoBoolNiHenkansuruKansuDesu(int num)

**仕様書無しさん** · 2015/09/03(木) 23:44:59.66

Objective-Cのメソッド名はクソ長いけど、お陰でドキュメントで使用例確認せずに済む。
と思ってたけど、それは名前空間のないObjective-Cの責任かな。

**仕様書無しさん** · 2015/12/10(木) 18:18:49.54

　　　　　　　　　　　　　　【　核テロ　】　原発政策をすべて止めろバカウヨ政権！　【　突然死　】

11.23 「テラスハウス」今井洋介さん心筋梗塞去 31歳…母親が発見　鎌倉在住で、ひまがあれば地元でサーフィンをしていた　千葉にも遠征
今井洋介氏が若くして急死した鎌倉市では、今年に入って死亡数が大幅に上昇
https://twitter.com/tokai amada/status/670895872155234304
11.15　阿藤快心不全 69歳　　一押ししていたすし店『海味』の大将も、今年の9月に死去
https://twitter.com/komatsunotsuma/status/666410144335441923

【川島なお美】自宅でも進んで食べて応援
1年後・肋骨骨折　2年後・眼球から出血　3年後・胆管に腫瘍、血液検査は異状無し　4年後・逝去夫は片目失明、愛犬もがん

2015年に亡くなった著名人
今井雅之54　盛田幸妃45　松来未祐38　泉政行35　宮田紘次34　黒木奈々32　丸山夏鈴21　椎名もた20

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　★★★

　　　　　　　　　　　　　　　　　　　　　　マイトレーヤは原発の閉鎖を助言されます。

　　　　　　　　　　　　　　　　　　日本もさらに多くの原子力発電所を作ろうとしています。
　　　　　　　　　　多くの人々が核の汚染の影響で死んでいるのに、彼らは幻想の中に生きています。

　　　　　　　　　　　　マイトレーヤが公に話し始めるとき、彼はこのことについて話されるでしょう。
　　　　　　　　　　　　　　　　　　　彼はいかなる人間よりもその危険をよくご存じである。
　　　　　　　　　　　　　　　　飛行機なども原子のパターンが妨害されると墜落は必然である。

　　　　　Q　福島県民やその付近のすべての住民（たとえば30km圏内の住民）は永久に避難すべきでしょうか。
　　　　　　　　　　　　　　　　　A　発電所が閉鎖されれば1年か２年で戻って来られるでしょう。

　　　　　　　　　　　　マイトレーヤの唇からますます厳しい警告と重みが発せられることを覚悟しなさい

安倍晋三・自民党の進めている高濃度放射能汚染地への帰還政策は、完全に大量殺人です
https://twitter.com/toka iamada/status/656953860548726784

**仕様書無しさん** · 2015/12/10(木) 21:16:02.97

お茶でも飲みましょう

**仕様書無しさん** · 2015/12/10(木) 21:21:57.99

＞＞
原発こえ-
でもすれちがい

**仕様書無しさん** · 2015/12/10(木) 22:24:34.15

ただの識別子や、無意味に短縮名にするのは、この業界では高齢者だな。

**仕様書無しさん** · 2015/12/10(木) 22:29:02.96

短縮しろって話じゃないぞ。

長い名前＝複数語からなる関数名
短い名前＝単語、もしくは2語程度
短縮=receiveをrcvとかに略すこと

**仕様書無しさん** · 2015/12/12(土) 18:29:24.98

dspとかsrchとか書く奴は糞馬鹿の象徴
そもそもdisplayなんて英単語を使うセンスが異常

**仕様書無しさん** · 2015/12/18(金) 10:01:37.64

「何を」「どうする」だけで組み合わせたなら、英語自体の問題なんで

**仕様書無しさん** · 2015/12/19(土) 11:59:54.93

>>152
日本人しか読まないコードなら、日本人に分かりやすい日本風英語でもかまわない。

**仕様書無しさん** · 2015/12/19(土) 16:33:24.84

>>154
日本人しか読まないなら日本語でかまわない

**仕様書無しさん** · 2015/12/19(土) 16:36:39.35

>>154
だれが読もうが、馬鹿なのは変わらない
馬鹿かそうでないか？
はい馬鹿ですね

そういう英語を書いてはダメ？
べつに好きにすればいい
ダメとは言ってない

**仕様書無しさん** · 2015/12/19(土) 23:53:14.39

IT業界は和製英語がいっぱいあるからな。

和製英語の根絶は難しい。

**仕様書無しさん** · 2015/12/25(金) 19:41:22.61

※SI犯罪対策の拡散歓迎
犯罪者個人に対して告訴状を偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料)　or 司法書士が代筆（料金は5万円ぐらい）
↓
告訴状を【検察の直告班】に郵便局の内容証明付で送付（疎明資料・証拠にはＩＣレコーダー、スマホによる録音が適しています）
↓
審査　→　不受理　→　告訴状再提出または刑法第193条で訴えを起こす
↓
受理　→　告訴事実を認め示談交渉（↓）　→示談成立　　→法廷相場50～100万円の示談金　※示談拒否が良い
↓　　　　　　　　　　　　　　　　↓
事案化　←←←←←←　示談不成立（↓）　→示談外交渉　→犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓　　　　　　　　　　　　　　　　↓
↓　　　　　　　　　　　　　　　起訴　　→公判　　→罰金刑＝前科（起訴事実を認めてるため）→追討ち民事訴訟
↓　　　　　　　　　　　　　　　　　　　　
審査　→　起訴（強制捜査・留置場）→　公判　→　懲役刑などの厳罰（反省が認められないため）→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第３０条（検察審査会へ申し立て）→　起訴　→　起訴後は同上
刑法第193条（公務員職権濫用）で検察事務官を刑事告訴　→　同上

◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約（公正証書・即決和解で秘密保持契約）
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発（刑事訴訟法239条1項）も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。

注意：告訴が受理されない理由
●３年間（※）の時効が過ぎたもの　※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの　※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。

**仕様書無しさん** · 2015/12/27(日) 09:24:08.59

理系の御家族かわいそう
技術ない方が寿命と収入高い

技術下げろ！
収入上げろ！

放送・商社・銀行・公務 > 製造・化学・通信・情報

http://m.finance.yahoo.co.jp/stock/fundamental?code=4676.T

**仕様書無しさん** · 2016/01/01(金) 09:44:19.64

使い捨て早死に貧困の助長SEは大迷惑
偽装請負の従犯は辞めろ！

・5,000円/時間以下の契約は辞めろ
・80万円/月以下の契約は辞めろ
・多重契約は辞めろ
・不利益な現場は辞めろ
・残業見積りは辞めろ
・時間外労働違反は辞めろ
・契約外納期は守るな
・客先指示に従うな
・知的財産を渡するな
・契約時間外に学習しろ
・契約時間外に副業しろ
・被害を訴えろ

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/

**仕様書無しさん** · 2016/01/01(金) 11:44:15.46

ちゃんと適切に変数のスコープを設定しろってことだね

**仕様書無しさん** · 2016/01/04(月) 13:31:31.36

つか、クラス化したら動詞だけで済むやろ。

**仕様書無しさん** · 2016/01/05(火) 02:20:24.18

情報処理検定53回の　大きな6 問4で

=IF(AND(OR(C4>=40,SUM(B4:D4)>=105),E4<=SMALL($E$4:$E$12,COUNT($E$4:$E$12)*2/3)),"◎","")

E4<=SMALL($E$4:$E$12,COUNT($E$4:$E$12)*2/3)),"◎","")

↑の訳がわからなくて
途中までは理解できるんだが

**仕様書無しさん** · 2016/01/05(火) 07:53:50.75

無能実態派遣残業して時間報酬相場下げるな！
【知的財産と契約料金の搾取促進者ばかり】
［生涯損害助長SI受注SEを追放すべき］
偽装請負従犯SEの動機
コミ障人格障害
コンピュータ趣味
文系大卒低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの損害
無償プログラム提供
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
事前面接
低予備工数残業見積
無料追加
労働違反
裁判苦手
学習不足
対人障害健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病
早死

**仕様書無しさん** · 2017/02/19(日) 18:21:47.57

結論だけおせぇて