長すぎる関数・メソッド・変数名の是非について

**デフォルトの名無しさん** · 2021/02/24(水) 06:33:14.07

英単語にすらなってないもの（例 abc, f123）・・・ダメ、論外（サンプルは省く）
英単語の省略（例 chdir, concat, char）・・・よく使われる単語ならOK
英単語1～3語・・・OK
英単語4語以上（例 getElementsByClassName）・・・これ

長けりゃいいってもんじゃない、設計からやり直せ
単語が長いと読むのが大変、可読性が悪い
IDE使えば補完される～とかそういう話じゃない
読む方、可読性の話

長い単語を見比べてまちがい探してもしたいのか？
特にローカル変数など小さいすスコープ、少数の名前であれば短い名前で十分。
長い単語のほうが可読性が高いと思い込む思考停止は今すぐやめろ
場合に応じて適切な長さの単語を使え

**デフォルトの名無しさん** · 2021/02/24(水) 12:05:20.67

Javaをディスるな

**デフォルトの名無しさん** · 2021/02/24(水) 12:06:58.49

長い単語はスペルミスが量産される
みんなIDEで間違った単語で補完するから

**デフォルトの名無しさん** · 2021/02/24(水) 14:53:24.44

＞単語が長いと読むのが大変、可読性が悪い

別に発音しにくいとか読み上げろってわけじゃないからいいだろw
意味がわかればおk
Elements を ClassNameでgetってわかればいいじゃんそれがプログラムの可読性

**デフォルトの名無しさん** · 2021/02/24(水) 15:05:27.17

JavaScriptだろ？
getElementBy～はメソッドの挙動に合わせたその通りのネーミングなんだろうけど、もっと良いやり方で短縮する方法は無かったのかな？ってのは思う。

**デフォルトの名無しさん** · 2021/02/24(水) 15:10:59.82

getElementsByClassName
getElementsById
getElementsByTagName

これってAndroid SDK基本機能の話かと思ったw

**デフォルトの名無しさん** · 2021/02/24(水) 15:11:03.76

>>4
この手の名前にはClassNameとIdがあるよなみたいに
慣れてて知っていればそれでもいいが

shouldBreakLineByHyphenatingBeforeCharacterAtIndex()
enterQTKitOnThreadDisablingThreadSafetyProtection()
getLineFragmentInsertionPointsForCharacterAtIndex()
invalidateGlyphsOnLayoutInvalidationForGlyphRange()
glyphRangeForBoundingRectWithoutAdditionalLayout()

こんなの読みたくないだろ？

ネオアームストロングサイクロンジェットアームストロング砲じゃねーんだからさｗ

**デフォルトの名無しさん** · 2021/02/24(水) 21:39:01.95

ここまでcreat()の批判なし

**デフォルトの名無しさん** · 2021/02/24(水) 22:06:58.21

公式のライブラリにある一番長い識別子は何?

**デフォルトの名無しさん** · 2021/02/24(水) 22:19:23.64

>>8

> 英単語にすらなってないもの（例 abc, f123）・・・ダメ、論外（サンプルは省く）
> 英単語の省略（例 chdir, concat, char）・・・よく使われる単語ならOK

すでに批判済み

**デフォルトの名無しさん** · 2021/02/24(水) 22:29:36.38

>>9
C:\Windows内のdllから関数名の長さをまとめたサイトならあった
15-20文字ぐらいが主流？

https://ashutoshmehra.net/blog/2010/02/long-function-names/
https://ashutoshmehra.net/blog/assets/img/funcnames/histogram_large.png

**デフォルトの名無しさん** · 2021/02/25(木) 01:30:49.38

WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10

**デフォルトの名無しさん** · 2021/02/25(木) 18:00:29.77

よし、日本語で行こう

**デフォルトの名無しさん** · 2021/02/25(木) 18:18:32.94

javaなら可能だ！

**デフォルトの名無しさん** · 2021/02/26(金) 02:57:49.67

rubyでも可能だ

**デフォルトの名無しさん** · 2021/02/26(金) 08:52:02.19

>>3
今時のIDEなら修正も容易だろ

**デフォルトの名無しさん** · 2021/02/26(金) 08:56:54.89

>>16
それが出来るのは静的言語だけ

**デフォルトの名無しさん** · 2021/02/26(金) 12:39:28.86

>>17
補完が効くのにリファクタリングできないってどんな言語よ

**デフォルトの名無しさん** · 2021/02/26(金) 15:29:11.71

>>18
JavaScript、Python、Ruby、Perl、PHP、シェルスクリプト
TypeScript、いくらでも見つかるな
すべての言語は補完できるからね

**デフォルトの名無しさん** · 2021/02/26(金) 16:08:44.44

>>19
それってなんでリファクタリングできないの？

**デフォルトの名無しさん** · 2021/02/26(金) 17:07:26.52

補完は多少間違っていても大した問題にならない
リファクタリングを間違ったら既存コードを破壊し重大なバグを生じるので、
IDEを作る側としてはクレームや責任問題になるのが嫌だから絶対確実なものしか世に出したくないというわけ

**デフォルトの名無しさん** · 2021/02/26(金) 18:03:19.79

>>20
IDEを使って修正が容易になるかどうかの話を
リファクタリングが可能か不可能かの話に
すり替えないでください
わざとらしいです

**デフォルトの名無しさん** · 2021/02/26(金) 18:21:54.95

>>21
ツールで変更した後で確認しないの？
そもそもテキトーに認識して補完候補なんて出せるの？

>>22
もしかしてIDEリファクタリング機能知らんの？

**デフォルトの名無しさん** · 2021/02/26(金) 18:58:54.02

>>23
コード補完なんてシグネチャだけ見りゃだいたい出せるんだから結構テキトーだよ
特に動的型の場合はどうせ正確にやるのは原理的に不可能なんだし、ユーザーもそれを承知して使っているから求められる品質は低い
極端な話、スコープや文脈を一切考慮せず既出単語をサジェストするだけでもそれなりには使える

**デフォルトの名無しさん** · 2021/02/26(金) 20:56:04.69

>>19
すべてリファクタリング機能付きのIDEがあるな

**デフォルトの名無しさん** · 2021/02/26(金) 20:59:40.20

>>23
> もしかしてIDEリファクタリング機能知らんの？

> JavaScript、Python、Ruby、Perl、PHP、シェルスクリプト
> TypeScript、いくらでも見つかるな
> すべての言語は補完できるからね

これらの言語のIDEリファクタリング機能で
変数名の書き換えを、安全に行えるものがないのを知らないの？ｗ

**デフォルトの名無しさん** · 2021/02/26(金) 23:30:51.31

>>26
安全の定義は？

**デフォルトの名無しさん** · 2021/02/27(土) 02:35:54.18

>>27
修正が容易にならない場合

16 返信：デフォルトの名無しさん[sage] 投稿日：2021/02/26(金) 08:52:02.19 ID:wRESsqiS [1/2]
>>3
今時のIDEなら修正も容易だろ

**デフォルトの名無しさん** · 2021/02/27(土) 08:04:32.47

具体的には？

**デフォルトの名無しさん** · 2021/02/27(土) 16:47:34.27

英語の場所効率が悪いだけ
漢字で書けばいい
generateと生成なら英語は二倍の場所を取る
欠陥言語による半強制なのでプログラミング言語そのものの問題ではない

全世界がドイツ語化した英語の読みにくさに辟易してるだけだ
表音文字の連結によって齎される不都合が顕在化している
空白と連結ならば、漢字は・でもつかって連結すればいい

プログラミングの問題ではなく、言語的な問題だ

**デフォルトの名無しさん** · 2021/02/27(土) 21:48:56.17

>>30
＞generateと生成なら英語は二倍の場所を取る
？？？

**デフォルトの名無しさん** · 2021/02/28(日) 11:13:55.42

>>7はスペースが無くて読みにくいのが問題なのであって、長さは問題じゃない

shouldBreakLineByHyphenatingBeforeCharacterAtIndex()
should break line by hyphenating before character at index()

普通に単語ごとに空白で区切れるような文芸的プログラミング手法を考え出せば、英語圏的には読みやすくなるし分り易くなる

"should break line by hyphenating before character at index"()
安直な手法は、文章を""で囲んで文字列で関数を宣言できればいい

**デフォルトの名無しさん** · 2021/02/28(日) 11:53:19.37

>>32
読みにくいじゃん

**デフォルトの名無しさん** · 2021/02/28(日) 13:01:13.90

>>32
代替的に空白の代わりにアンダースコアでやる流儀もあるけどたいして読み易くは無いな
should_break_line_by_hyphenating_before_character_at_index()

**デフォルトの名無しさん** · 2021/02/28(日) 16:56:52.11

ネーミングセンスの問題

**デフォルトの名無しさん** · 2021/02/28(日) 17:30:39.99

語彙力と表現力だな

**デフォルトの名無しさん** · 2021/03/01(月) 10:39:57.14

語彙力が問題なら>>6ではHTML操作言語を新たに作ればいい
「バベル‐17」では熱核融合炉の仕組みをたったを14語で言い表す言語が出てくる
取り扱う体系がメインかどうかでそれに関する動詞が少ないから語がかさばる

つまり
getElementsByClassName
getElementsById
getElementsByTagName
この一つ一つに別の動詞を割り当てた新しい自然言語を作るところから始めればいい

これは人間がアホするぎることに起因していて、
基本的な動詞だけで１０万ほどを使い分けるような世界にはヒトは生きてないからだ
なら、もっと超人を考えないと、この長すぎる関数の問題は解決しない

**デフォルトの名無しさん** · 2021/03/01(月) 11:40:36.20

getElementsByIdじゃなくてgetElementByIdな
今となっては用済みの関数たち

**デフォルトの名無しさん** · 2021/03/01(月) 11:47:48.89

getAllElements(class='hoge')
getAllElements(tag='input')
getElement(id='hage')

動詞・目的語と条件指定を利便性を考えて分ければいい
allやelementも条件として引数にすることもできる

**デフォルトの名無しさん** · 2021/03/01(月) 19:19:35.32

>>7 shouldBreakLineByHyphenatingBeforeCharacterAtIndex()
> enterQTKitOnThreadDisablingThreadSafetyProtection()
> getLineFragmentInsertionPointsForCharacterAtIndex()
> invalidateGlyphsOnLayoutInvalidationForGlyphRange()
> glyphRangeForBoundingRectWithoutAdditionalLayout()

ネーミングの問題というよりは、設計の問題もある気がする

samurai.NeoArmstrongCycloneJetArmstrongCanon()

だったらどうだ？少しは見やすく...いや、無理があるか？
でも、他の例よりは読めるとは思う

**デフォルトの名無しさん** · 2021/03/01(月) 22:36:13.59

重要なのはコンテキストから明らかな場合は
単語を省略できること

**デフォルトの名無しさん** · 2021/04/13(火) 20:15:49.50

GetElemBy にしてればずいぶん違ったんだろうなｗ

**デフォルトの名無しさん** · 2021/04/15(木) 20:48:46.58

「長すぎる～」って地の文で悪意のある表現使うのってゲスゴミの常套手段なのな。

**デフォルトの名無しさん** · 2021/04/21(水) 07:28:27.76

API仕様を見なくても動作が連想できるのなら長くてもメリットがある。
てかいっそのことAPI仕様に書かれている文を全部そのまま関数名にしてみたら面白いかもしれない。

**デフォルトの名無しさん** · 2021/05/09(日) 14:54:07.15

長い名前は、優先度の高い改修対象だな

**デフォルトの名無しさん** · 2021/05/18(火) 06:40:45.92

１クラス内にメソッドが多過ぎるから
区別のための名前が長大化する予感が

**デフォルトの名無しさん** · 2021/05/19(水) 21:07:33.39

深い階層がラビリンスを生んだ悪夢があるから。多分。

**デフォルトの名無しさん** · 2022/03/05(土) 06:50:13.18

長いのも悪くないな。
hwndって何だよwwwとか思うしな。

**デフォルトの名無しさん** · 2022/03/11(金) 23:07:31.12

昔はhWndとか割と普通に使ってたけど
まぁ、Win32API使う場合は良く出てくるしあんまり変と思わなかったなぁ
hWindowとかフルに書く方が慣れなのか違和感があるなｗ
でもインスタンスはhInstの場合もあるけどhInstanceって書いてあったりとか
統一性が当時でも無かった気はするｗ
hDCとかも慣れでhDeviceContextとか書いている奴は流石にいなかったｗ

**デフォルトの名無しさん** · 2022/03/13(日) 02:31:20.54

ここら辺で日本語の良さでも見直すか?

**デフォルトの名無しさん** · 2022/08/03(水) 10:53:14.05

completeをcomplateで色々作ってしまった。
セクハラで訴えらるかなぁ、、、

**デフォルトの名無しさん** · 2023/06/12(月) 19:49:45.00

(-。-)y-゜゜゜