X
長い関数名をつける奴は技術力が低い [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん
垢版 |
2014/11/08(土) 12:28:11.13
汎用的な関数は短い名前。汎用的じゃない関数名は長くなる。

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

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

※名前空間がない言語で、名前空間的に使わざるを得ない場合は除く。
0002仕様書無しさん
垢版 |
2014/11/08(土) 13:13:31.56
せっかくスレを立てたのに２ゲットすらされない……
そんな悩みを抱えてらっしゃいませんか？
ご安心ください！クソスレ２ゲットサービスです！
0003仕様書無しさん
垢版 |
2014/11/08(土) 15:07:10.23
書いた本人しかわからないような略語を使われるよりは省略しないほうがずっとマシ
0004仕様書無しさん
垢版 |
2014/11/08(土) 15:09:44.52
>>3
誰も省略しろなんて言ってないだろ。

document.getElementsByTagName() みたいな長い名前の話だろ
0006仕様書無しさん
垢版 |
2014/11/08(土) 21:56:32.45
>>4
タグ名をキーとして要素のリストを取得する
何も問題ないだろ…
0007仕様書無しさん
垢版 |
2014/11/08(土) 22:02:28.21
>>6
どんだけ入力遅いんだよｗ

普通はtabで候補を選んでる間に入力してしまうって。
0010仕様書無しさん
垢版 |
2014/11/08(土) 23:54:48.41
jQueryとかで$(セレクタ)みたいなのが流行ってるけど、
もしセレクタで引っ張ってくるというアイデアを思いつかなかったとしたら、
getElements(条件) かな。もしくはfindElementか、単にfindとか。

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

もしくはSQLみたいな簡易言語を作っていたか。
まあセレクタはその簡易言語みたいなものなんだけど。
0011仕様書無しさん
垢版 |
2014/11/09(日) 00:11:45.95
つかjavascriptってメソッドのオーバーロードできるんだっけ。

switch使うとかいうなよ
0012仕様書無しさん
垢版 |
2014/11/09(日) 00:45:49.96
>>11
switch？

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

オーバーライドと間違ってない？
0015仕様書無しさん
垢版 |
2014/11/09(日) 09:35:22.94
>>11
getElements({ tag: 'SPAN' })

>>10は見ての通り、引数に連想配列を取っている。
お判り頂けただろうか。
0016仕様書無しさん
垢版 |
2014/11/09(日) 10:35:51.79
オーバーロードでやろうと思ったら、
引数にSPAN文字列ではなくて、
SPANオブジェクトを渡せって話になるのか？

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

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

オーバーロードでやるとかセンス無いと思うわーｗ
0017仕様書無しさん
垢版 |
2014/11/09(日) 11:04:29.39
>>10はオーバーロードなんて話はしてないよ。
>>11が条件の変化を表現するために、オーバーロードを使うって勘違いしたんだろう。
0018仕様書無しさん
垢版 |
2014/11/09(日) 11:13:12.22
getElements({ tag: 'SPAN' })
getElements({ class: 'email' })
getElements({ name: 'user01' })

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

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

getElements({ tag: 'SPAN', class: 'email' })
getElements({})
0019仕様書無しさん
垢版 |
2014/11/09(日) 11:16:36.01
>>18
特に問題無いと思うけど。
SPANタグでemailクラス持ってるエレメント返せば良いじゃない。
0020仕様書無しさん
垢版 |
2014/11/09(日) 11:32:20.14
Byなんたらにしておけば
そんな必要もないものわざわざ実装しなくて済むのに。
0021仕様書無しさん
垢版 |
2014/11/09(日) 11:36:21.57
tag と class どっちを先に絞り込むつもりなんだろう。
遅い方だとヤだなあ。
0027仕様書無しさん
垢版 |
2014/11/09(日) 12:04:25.59
おい>>1よ、

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

jQueryのセレクタって、複雑だけど関数名短い（ってか無い）じゃねーか。
どういうことだ。
0028仕様書無しさん
垢版 |
2014/11/09(日) 15:43:33.49
>>27
ここでいう複雑っていうのは機能の多さだよ。
jQueryのセレクタは単機能だからシンプル。

一回の呼び出しで、同時に複数の処理を行うことが
複雑ってことなんだ。
0031仕様書無しさん
垢版 |
2014/11/09(日) 21:06:04.28
>>28
> ここでいう複雑っていうのは機能の多さだよ。
だからgetElementsByTagName()よりも機能多いよね
0033仕様書無しさん
垢版 |
2014/11/10(月) 22:52:44.32
必殺技アタマガワルイナー
今日も見る事が出来ました
0034仕様書無しさん
垢版 |
2014/11/10(月) 23:06:04.47
イチガイニハイエナイ
大抵の必殺技を無効にする呪文だ
0036仕様書無しさん
垢版 |
2014/11/11(火) 07:12:32.01
魔法少年ブチドキュン
ツキが変わってオチなしよ
0037仕様書無しさん
垢版 |
2014/11/11(火) 12:38:31.68
>>27
>jQueryのセレクタって、複雑だけど関数名短い（ってか無い）じゃねーか。
$が関数名なんだが。
0038仕様書無しさん
垢版 |
2014/11/11(火) 12:48:48.83
jQueryのセレクタは関数名こそ短いけど、その分引数が複雑になってるから
0039仕様書無しさん
垢版 |
2014/11/17(月) 08:22:21.92
英語にしなくていい
日本語使えるなら日本語関数にしてくれ
0041仕様書無しさん
垢版 |
2014/11/18(火) 07:15:15.38
accessは昔から日本語使えたので日本語の関数しか見たことなかった
便利なんだが全角カッコありの関数名とかどういうことだよ
0042仕様書無しさん
垢版 |
2014/11/21(金) 08:13:24.87
スペルミス関数使うくらいなら、日本語関数で定義してほしいんですけど
0043仕様書無しさん
垢版 |
2014/11/22(土) 12:02:06.28
生涯収入３億以下の貧乏人へ
利益少なすぎ商売下手すぎ
分量減らすか収入増やせ
0044仕様書無しさん
垢版 |
2014/11/22(土) 12:25:24.10
つーか

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

どーせ日本でしか動かさないソースなんだから日本語さいきょー！
0047仕様書無しさん
垢版 |
2014/11/24(月) 13:40:15.91
VS

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

これだけで実にわかりやすい。圧倒的ですな。
0049仕様書無しさん
垢版 |
2014/11/26(水) 23:06:01.76
>>47
フロントエンドばっかやってるとこういう単細胞馬鹿になる
0051KAC
垢版 |
2014/12/29(月) 22:27:57.29
>>1
> 複雑な機能の関数しか書けないから、その説明である関数名も長くなる。

そういう訳でもない。

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

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

関数の複雑さと関数名の長さにはさほど関係は無いよ。
0053仕様書無しさん
垢版 |
2015/01/25(日) 18:22:47.83
よく使うのは短く。
ほとんど使わないのは、説明するために長くなる。
0054仕様書無しさん
垢版 |
2015/03/15(日) 16:43:52.10
jQueryというかJavaScriptは
変数名や関数名の長さがパフォーマンスに響くとか聞いたことがある
ホントかは知らない
0055仕様書無しさん
垢版 |
2015/04/03(金) 22:24:55.53
>>54
スクリプト言語だからな。
0056仕様書無しさん
垢版 |
2015/04/03(金) 22:26:07.11
>>54
とはいえ、どうでもいいレベルの差だよな。

アホプログラマが言いそうなこと。
0057仕様書無しさん
垢版 |
2015/04/06(月) 13:37:55.17
>>1は正しいと思う

SRPが守られていれば、クラスやメソッドの名前は
見て思わず射精するくらい、短くなるわな
0058仕様書無しさん
垢版 |
2015/04/06(月) 22:21:36.79
>>57
関数と言っているのだから、普通はオブジェクト指向言語じゃないだろ。
0059仕様書無しさん
垢版 |
2015/04/07(火) 20:08:15.54
メソッドの名前で射精するﾎﾓｸﾞﾗﾏｰのちんこ舐めたい
0060仕様書無しさん
垢版 |
2015/04/10(金) 07:34:49.45
たかだか文系の四則演算程度しか使わないシステムで慌てふためいて残業とか、
お前ら人間として恥ずかしくないのかい?w
オレだったら恥ずかしくて人間を名乗れないなー
「実はオレ、チンパンジーとの雑種なんですw」(だから頭悪いの仕方ないでしょ?勘弁してw)と言うねw

こんな程度の小学生レベルのシステムでてこずってたら、
物理エンジンの開発とかまずもってお手上げだろうなw
光の反射の計算や、それによってオブジェクトの表面がどう変色するかや、光沢の強弱計算など
うんざりするほど数学を駆使しないとできないからねーw
0062仕様書無しさん
垢版 |
2015/04/11(土) 01:47:03.80
>>60
四則演算はシステムの中心にないんだよ。
そんなもの実はシステムの中ではどうでもいいことで、
そういう点しか見れてないお前はまだまだあって事さ。

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

小さなところだけ見て、簡単だって言ってるようじゃ
何もわかってない。
0063仕様書無しさん
垢版 |
2015/04/11(土) 08:19:27.04
>>62
残業やめろを言いたいだけ
0065仕様書無しさん
垢版 |
2015/04/11(土) 08:50:37.12
社員番号から社員名を取得する(引数）
社員名から社員番号一覧を取得する（引数）

と日本語でやる俺最強！
0067仕様書無しさん
垢版 |
2015/04/11(土) 18:08:22.27
長さに文句をつけるとか相当クソみたいな開発環境なんだな
0068仕様書無しさん
垢版 |
2015/04/11(土) 19:15:31.46
あぁ、君はきっと補完できるからタイピング速度が遅くても
問題ないっていいたいのだろう。
タイピング速度は重要じゃない。

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

さて聞きたいが、長いコードは読むのに時間が掛かる。
開発環境が優れているとどう読むのが楽になるのかね？
0070仕様書無しさん
垢版 |
2015/04/11(土) 22:04:44.69
長いメソッド名はcode smell
ってのは当たり前なんだが
日本だけまたガラパゴスなのか？
0071仕様書無しさん
垢版 |
2015/04/11(土) 22:51:05.34
>>70
だからメソッドと関数は違うと言ってるだろ？
0072仕様書無しさん
垢版 |
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で短いわけだが？

こ・れ・が、技術力！（笑）
007372
垢版 |
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})

単の文字を入れ替えただけだがｗ
0075仕様書無しさん
垢版 |
2015/04/12(日) 08:18:38.29
employe.get('name', {id => id})

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

ところが、関数で
　社員番号から社員名を取得する()
　employe.get_name_by_id()
になってれば名前から処理が推測できる。
よって後者のほうがいい
0077仕様書無しさん
垢版 |
2015/04/12(日) 08:36:07.49
>>73
employee_number なのか idなのかはっきりしろｗ
無理に英語にしようとするから、統一性がなくなる。
0078仕様書無しさん
垢版 |
2015/04/12(日) 08:59:55.81
>>72
なんかテキストの一部だけを切り取って覚えたみたいな感じだなｗ
get()、search()、set()
だけで取得や検索、設定をやるとして、同じ取得に関しての処理で処理が違ったら全部引数で判断するのか？ｗ
マニュアル読む側はめんどくせぇｗ
0079仕様書無しさん
垢版 |
2015/04/12(日) 09:01:00.51
例えば既存関数(XXX)の拡張用に関数増やす場合
関数の末尾にXXXForYYY()って名前はおかしいかな？
関数というかメソッドって英語構文のSVOCとか意識しちゃうんだけど
0080仕様書無しさん
垢版 |
2015/04/12(日) 12:01:08.55
>>77
この指摘は、極めて重要な指摘。
英語圏の連中ならnumberとidとemployeeIDとemployeeNumberとは、意識せずにきちんと統一された状態で実装してくる。
英語圏でない不慣れなやつが気取って英単語使おうとすると、統一がとれていないことにすら気づかない。
結局、idとは？numberとは？employeeNumberとは？employeeIDとは？それぞれ違うの？？？？？？？という無駄な疑問と調査作業が生まれる。
で、すべて英単語で来るのかと思うと急にローマ字だったり、意地で英単語で実装してくると専門用語は機械翻訳の英単語を使ってくる。
そんなめちゃくちゃなのばっかり。
そういう意味では>>65のように日本語OKな環境ならばアレルギーを抱かず日本語使ったほうが日本人プログラマには極めて有効。
大抵の日本産プログラムなんて外に出ることは無いのだから。
0081仕様書無しさん
垢版 |
2015/04/12(日) 12:35:43.95
確かに、変な英語メソッド名より長い日本語メソッド名の方がマシだな
0082仕様書無しさん
垢版 |
2015/04/12(日) 12:40:46.78
日本人なのに英語の関数名をつける奴は技術力が低い
0083仕様書無しさん
垢版 |
2015/04/12(日) 15:01:02.55
>>80
> この指摘は、極めて重要な指摘。
> 英語圏の連中ならnumberとidとemployeeIDとemployeeNumberとは、意識せずにきちんと統一された状態で実装してくる。

それはIDに相当する日本語がないのが問題。
日本語を使っている限りこの問題は無くならない
0084仕様書無しさん
垢版 |
2015/04/12(日) 15:02:11.51
つまりドキュメントに「社員番号」って
書かないようにしないとだめってことだな
0085仕様書無しさん
垢版 |
2015/04/12(日) 15:04:04.06
>>80
> そういう意味では>>65のように日本語OKな環境ならばアレルギーを抱かず日本語使ったほうが日本人プログラマには極めて有効。

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

idってつけたいけど日本語使うんでしたよね（・∀・）ﾆﾔﾆﾔ
0086仕様書無しさん
垢版 |
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'）

な？丁寧やろ？
0088仕様書無しさん
垢版 |
2015/04/12(日) 17:22:35.47
>>85
IDは、100人に聞いて95人くらいは十分日本語で通じますｗ
Employeeは１００人に聞いて40人がいいとこでしょう。
柔軟性の無いバカですねｗ。
0089仕様書無しさん
垢版 |
2015/04/12(日) 17:41:48.90
IDって日本語に無理に訳すと「識別子」だと長年思ってた

IDに相当する日本語がないという問題をなんとかせねば！
0092仕様書無しさん
垢版 |
2015/04/12(日) 17:50:20.75
>こ・れ・が、技術力！（笑）

というか、コレが技術力？　の間違いだろ？？？？？？？？？？？？？？？？？？？？？？？？？？？
どんだけレベルの低いところで小山の大将やってんだ？？？？？？？？？？？？？？？？？？？？？？？
0095仕様書無しさん
垢版 |
2015/04/12(日) 18:10:37.70
日本のプログラミングってすぐにSEARCHが出てくる
どんだけSEARCH好きなんだよｗ
たまにSERCHって凶悪なのも

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

迷ったら「サーチアンドゲット！」って唱えよう
0097仕様書無しさん
垢版 |
2015/04/12(日) 19:56:13.05
英語圏の翻訳本を読んで技術力を身につけた気になっちゃって世間に披露したけど世間はもっと上を行っていたという盛大なオチ?
0101仕様書無しさん
垢版 |
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_連番」が最強
0102仕様書無しさん
垢版 |
2015/04/12(日) 21:23:27.98
ちなみに
関数の中で他の関数を勝手に呼んではならないという縛りがある（ごくまれな例をのぞいて）
このため1つの関数が数千行になる
プログラムの行数が長ければ長いほど仕事を頑張ったと評価される
0103仕様書無しさん
垢版 |
2015/04/12(日) 21:26:42.88
コードの行数は長いほうが良いけど
変数や関数の名前が長いとNGをもらう
8文字程度、長くて10文字
横方向にコードがモニタからはみでたら好感度-1。
0104仕様書無しさん
垢版 |
2015/04/12(日) 21:32:56.87
ああ
101の関数名がすでに10文字超えてたわｗ
もううろ覚えだから適当だけど、個ぼらーの上司はこんな感じの規約を作ってたわ
デザパタ本読んで意気込んでたあの頃の俺は馬鹿にしていたが
今では規約を作ってちゃんと守ってるだけよほどマシな人だったと反省している
0105仕様書無しさん
垢版 |
2015/04/12(日) 23:26:08.45
>>102
冗談としてもつまらんぞ
そんな仕事で金がもらえるのは公務員のお偉いさんに仕える企業だけ
0108仕様書無しさん
垢版 |
2015/04/13(月) 00:55:20.50
>>102
階層が浅くなって手続型な書き方になるから普通に悪くないと思うぞ
規模次第ではその方式が良い場合もある
0109仕様書無しさん
垢版 |
2015/04/13(月) 01:28:56.82
>>108
いやー、それはないわｗ

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

関数をつくったら複雑になるのは
コードが長いからまとめるぐらいにしか考えてないから。
役割ってのを全く考えてないんだよね。
0110仕様書無しさん
垢版 |
2015/04/13(月) 02:33:07.26
分かりやすい名前を付けるという行為は文系チックな能力が必要だから
よくいる理系のプログラマには向いていないんだよなあ。

これはしょうがない
0111仕様書無しさん
垢版 |
2015/04/13(月) 20:07:59.32
>>109
関数の正しい使い方なんて実務歴１０年以上あるけど未だにわからんよ
考えれば考えるほど分らん
0112仕様書無しさん
垢版 |
2015/04/13(月) 20:48:58.52
客が要件でなんからの用語を提示してきたら
変数にはその名称と同じにしろ。

例えば、お客様番号だったらCustomerIDじゃなくてそのまま命名するんだ。
0114仕様書無しさん
垢版 |
2015/04/13(月) 22:56:12.19
>>108みたいなことstackoverflowで書いたら、マイナス-10くらい平気で食らいそうｗ

そもそも今時unit testしないのかよ！って怒られるだろうね
>>102で良いとか、日本のプログラミング文化はマジで世界から１０年以上遅れてるわな
0116仕様書無しさん
垢版 |
2015/04/13(月) 22:57:30.88
マイナス-10じゃすまないな
-100くらい行ってもおかしくないレベル
0117仕様書無しさん
垢版 |
2015/04/13(月) 23:06:05.99
学生かな？歴戦のブラック戦士からするとそんなの別にどおってことないぞ
0118仕様書無しさん
垢版 |
2015/04/13(月) 23:12:12.37
何がどおってこと無いんですか。
底辺でもいいじゃないかってことですか？
0119仕様書無しさん
垢版 |
2015/04/13(月) 23:52:36.80
郷に入ったら郷ひろみと言ってだな
コーディング規約程度でネガるならエンジニアとしての腕が知れているという事
問題の本質はそんなところには無い
0120仕様書無しさん
垢版 |
2015/04/13(月) 23:56:57.67
コーディング規約って、ツール導入して、
設定するだけだろ。

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

まさか、いちいち人間がチェックしてないよね？
0121仕様書無しさん
垢版 |
2015/04/14(火) 04:53:54.26
>>108
他所の関数呼ばれると読み解くのに時間がかかるって発狂する上司だった
上から下にスクロールしていって1000行でも2000行でも止まることなく１本グソのごとき美しさを持ってないとNG

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

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


おもしろいやろ？
0122仕様書無しさん
垢版 |
2015/04/14(火) 05:17:30.56
まあ、思い出補正入ってるから「作り話」として聞いてくれ。

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

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

これをどう評価するのかはおまいらにまかせる。
俺は部下にすら信念を持って説明できないヘタレだからな。
あのおっさんと違って。
0123仕様書無しさん
垢版 |
2015/04/14(火) 09:33:43.33
>>122
ま、結果が出ればなんだっていいよね
趣味でやってるわけじゃないんだから
0124仕様書無しさん
垢版 |
2015/04/14(火) 10:41:59.76
>>112
これはあるね。
0125仕様書無しさん
垢版 |
2015/04/14(火) 16:31:57.51
うちでもアルファベットから日本語への切り替えは賛否あったけど
数年経ったら、「なんでアルファベットにこだわったんだろう？」って状態になったよ
0126仕様書無しさん
垢版 |
2015/04/14(火) 19:39:11.28
ある程度の腕になると>>121も>>122も>>125も　どうって事はなくなる
なぜギャーギャー騒ぐのか？坊やだからさ
0127仕様書無しさん
垢版 |
2015/04/14(火) 19:41:31.90
もっと経験を積め、どんなやり方だろうがそれで会社が回っているならいいんだよ
やり方を変えてもし失敗したら責任自分が持つっていう覚悟なら一石を投じなさい
0129仕様書無しさん
垢版 |
2015/04/15(水) 11:19:40.00
結局>>1が無能だったの？
0130仕様書無しさん
垢版 |
2015/04/15(水) 12:13:44.99
Egirls_team_Dream();
Egirls_team_Happiness();
Egirls_team_Flower();
0131仕様書無しさん
垢版 |
2015/04/15(水) 19:36:34.59
>>129
ふつうに無能に見える
こんな小さい事でガーガー言ってるレベルだろ
上を説得できる能力もないし、どんな理不尽な条件でもやっていく順応性もない
0132仕様書無しさん
垢版 |
2015/04/15(水) 21:46:00.06
>>131
おい、理由が全く書いてないぞｗ

お前の言うことに説得力がないじゃないか
0133仕様書無しさん
垢版 |
2015/04/16(木) 01:09:27.86
GetElementByName ←レベル低い
0135仕様書無しさん
垢版 |
2015/04/16(木) 06:46:38.57
自分が読んだ本と違っていたら指摘して非難する

という短絡的な思考パターンの人なんだと思う>>1は
非常に社会にとって害
0136仕様書無しさん
垢版 |
2015/04/16(木) 07:37:01.04
これ>>1を肯定してる書き込みって全部>>1じゃね？
0137仕様書無しさん
垢版 |
2015/04/16(木) 07:41:04.07
というかこの>>>1は例のバカだから
0138仕様書無しさん
垢版 |
2015/04/16(木) 21:00:00.28
>>1　
これらの書き込みを見ろ
お前に反論しているやつが大半だ。
わかったか。
0139仕様書無しさん
垢版 |
2015/04/17(金) 17:43:05.07
スレを立てる度、毎回否定される>>1
(ヽ´ω`)不憫といえば不憫
でも社会に出てこようとしないでね
0140仕様書無しさん
垢版 |
2015/04/19(日) 10:24:11.49
ズレてるんだよな…理解が
まあ致命的なズレなんだが。
0141仕様書無しさん
垢版 |
2015/04/19(日) 18:10:00.60
でもいい負かせられないから
ちょっと苛つくよねｗ
0142仕様書無しさん
垢版 |
2015/04/20(月) 09:02:24.77
>>141
盲信してしまっていて、他人の言うことを素直に受け取れない人は言い負かす云々以前で
措置入院させるべき対象
0143仕様書無しさん
垢版 |
2015/04/20(月) 12:55:32.65
>>1の古傷に触れるな
0146仕様書無しさん
垢版 |
2015/09/03(木) 23:44:59.66
Objective-Cのメソッド名はクソ長いけど、お陰でドキュメントで使用例確認せずに済む。
と思ってたけど、それは名前空間のないObjective-Cの責任かな。
0147仕様書無しさん
垢版 |
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
0148仕様書無しさん
垢版 |
2015/12/10(木) 21:16:02.97
お茶でも飲みましょう
0149仕様書無しさん
垢版 |
2015/12/10(木) 21:21:57.99
＞＞
原発こえ-
でもすれちがい
0150仕様書無しさん
垢版 |
2015/12/10(木) 22:24:34.15
ただの識別子や、無意味に短縮名にするのは、この業界では高齢者だな。
0151仕様書無しさん
垢版 |
2015/12/10(木) 22:29:02.96
短縮しろって話じゃないぞ。

長い名前＝複数語からなる関数名
短い名前＝単語、もしくは2語程度
短縮=receiveをrcvとかに略すこと
0152仕様書無しさん
垢版 |
2015/12/12(土) 18:29:24.98
dspとかsrchとか書く奴は糞馬鹿の象徴
そもそもdisplayなんて英単語を使うセンスが異常
0153仕様書無しさん
垢版 |
2015/12/18(金) 10:01:37.64
「何を」「どうする」だけで組み合わせたなら、英語自体の問題なんで
0154仕様書無しさん
垢版 |
2015/12/19(土) 11:59:54.93
>>152
日本人しか読まないコードなら、日本人に分かりやすい日本風英語でもかまわない。
0155仕様書無しさん
垢版 |
2015/12/19(土) 16:33:24.84
>>154
日本人しか読まないなら日本語でかまわない
0156仕様書無しさん
垢版 |
2015/12/19(土) 16:36:39.35
>>154
だれが読もうが、馬鹿なのは変わらない
馬鹿かそうでないか？
はい馬鹿ですね

そういう英語を書いてはダメ？
べつに好きにすればいい
ダメとは言ってない
0157仕様書無しさん
垢版 |
2015/12/19(土) 23:53:14.39
IT業界は和製英語がいっぱいあるからな。

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

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

注意：告訴が受理されない理由
●３年間（※）の時効が過ぎたもの　※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの　※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。
0160仕様書無しさん
垢版 |
2016/01/01(金) 09:44:19.64
使い捨て早死に貧困の助長SEは大迷惑
偽装請負の従犯は辞めろ！

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

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/
0161仕様書無しさん
垢版 |
2016/01/01(金) 11:44:15.46
ちゃんと適切に変数のスコープを設定しろってことだね
0162仕様書無しさん
垢版 |
2016/01/04(月) 13:31:31.36
つか、クラス化したら動詞だけで済むやろ。
0163仕様書無しさん
垢版 |
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)),"◎","")

↑の訳がわからなくて
途中までは理解できるんだが
0164仕様書無しさん
垢版 |
2016/01/05(火) 07:53:50.75
無能実態派遣残業して時間報酬相場下げるな！
【知的財産と契約料金の搾取促進者ばかり】
［生涯損害助長SI受注SEを追放すべき］
偽装請負従犯SEの動機
コミ障人格障害
コンピュータ趣味
文系大卒低偏差値大卒
情報処理資格非保有者

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

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病
早死
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況