X
長すぎる関数・メソッド・変数名の是非について
0001デフォルトの名無しさん
垢版 |
2021/02/24(水) 06:33:14.07ID:IL+ryHZw
英単語にすらなってないもの（例 abc, f123）・・・ダメ、論外（サンプルは省く）
英単語の省略（例 chdir, concat, char）・・・よく使われる単語ならOK
英単語1〜3語・・・OK
英単語4語以上（例 getElementsByClassName）・・・これ


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

長い単語を見比べてまちがい探してもしたいのか？
特にローカル変数など小さいすスコープ、少数の名前であれば短い名前で十分。
長い単語のほうが可読性が高いと思い込む思考停止は今すぐやめろ
場合に応じて適切な長さの単語を使え
0002デフォルトの名無しさん
垢版 |
2021/02/24(水) 12:05:20.67ID:o/ofUPeK
Javaをディスるな
0003デフォルトの名無しさん
垢版 |
2021/02/24(水) 12:06:58.49ID:aaBs9O4Y
長い単語はスペルミスが量産される
みんなIDEで間違った単語で補完するから
0004デフォルトの名無しさん
垢版 |
2021/02/24(水) 14:53:24.44ID:xofLogOY
＞単語が長いと読むのが大変、可読性が悪い

別に発音しにくいとか読み上げろってわけじゃないからいいだろw
意味がわかればおk
Elements を ClassNameでgetってわかればいいじゃんそれがプログラムの可読性
0005デフォルトの名無しさん
垢版 |
2021/02/24(水) 15:05:27.17ID:hRk0CrMt
JavaScriptだろ？
getElementBy〜はメソッドの挙動に合わせたその通りのネーミングなんだろうけど、もっと良いやり方で短縮する方法は無かったのかな？ってのは思う。
0006デフォルトの名無しさん
垢版 |
2021/02/24(水) 15:10:59.82ID:FKCMCStr
getElementsByClassName
getElementsById
getElementsByTagName

これってAndroid SDK基本機能の話かと思ったw
0007デフォルトの名無しさん
垢版 |
2021/02/24(水) 15:11:03.76ID:aaBs9O4Y
>>4
この手の名前にはClassNameとIdがあるよなみたいに
慣れてて知っていればそれでもいいが

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

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

ネオアームストロングサイクロンジェットアームストロング砲じゃねーんだからさｗ
0010デフォルトの名無しさん
垢版 |
2021/02/24(水) 22:19:23.64ID:aaBs9O4Y
>>8

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

すでに批判済み
0012デフォルトの名無しさん
垢版 |
2021/02/25(木) 01:30:49.38ID:HJ9YlmBf
WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10
0019デフォルトの名無しさん
垢版 |
2021/02/26(金) 15:29:11.71ID:MVwmWMo6
>>18
JavaScript、Python、Ruby、Perl、PHP、シェルスクリプト
TypeScript、いくらでも見つかるな
すべての言語は補完できるからね
0021デフォルトの名無しさん
垢版 |
2021/02/26(金) 17:07:26.52ID:0iUIeSnK
補完は多少間違っていても大した問題にならない
リファクタリングを間違ったら既存コードを破壊し重大なバグを生じるので、
IDEを作る側としてはクレームや責任問題になるのが嫌だから絶対確実なものしか世に出したくないというわけ
0022デフォルトの名無しさん
垢版 |
2021/02/26(金) 18:03:19.79ID:MVwmWMo6
>>20
IDEを使って修正が容易になるかどうかの話を
リファクタリングが可能か不可能かの話に
すり替えないでください
わざとらしいです
0023デフォルトの名無しさん
垢版 |
2021/02/26(金) 18:21:54.95ID:y/9ce84r
>>21
ツールで変更した後で確認しないの？
そもそもテキトーに認識して補完候補なんて出せるの？

>>22
もしかしてIDEリファクタリング機能知らんの？
0024デフォルトの名無しさん
垢版 |
2021/02/26(金) 18:58:54.02ID:qMNv54aM
>>23
コード補完なんてシグネチャだけ見りゃだいたい出せるんだから結構テキトーだよ
特に動的型の場合はどうせ正確にやるのは原理的に不可能なんだし、ユーザーもそれを承知して使っているから求められる品質は低い
極端な話、スコープや文脈を一切考慮せず既出単語をサジェストするだけでもそれなりには使える
0026デフォルトの名無しさん
垢版 |
2021/02/26(金) 20:59:40.20ID:MVwmWMo6
>>23
> もしかしてIDEリファクタリング機能知らんの？

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

これらの言語のIDEリファクタリング機能で
変数名の書き換えを、安全に行えるものがないのを知らないの？ｗ
0028デフォルトの名無しさん
垢版 |
2021/02/27(土) 02:35:54.18ID:dWUrH1vP
>>27
修正が容易にならない場合


16 返信：デフォルトの名無しさん[sage] 投稿日：2021/02/26(金) 08:52:02.19 ID:wRESsqiS [1/2]
>>3
今時のIDEなら修正も容易だろ
0030デフォルトの名無しさん
垢版 |
2021/02/27(土) 16:47:34.27ID:nZVzeDc8
英語の場所効率が悪いだけ
漢字で書けばいい
generateと生成なら英語は二倍の場所を取る
欠陥言語による半強制なのでプログラミング言語そのものの問題ではない

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

プログラミングの問題ではなく、言語的な問題だ
0032デフォルトの名無しさん
垢版 |
2021/02/28(日) 11:13:55.42ID:07qK9f/t
>>7はスペースが無くて読みにくいのが問題なのであって、長さは問題じゃない

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

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

"should break line by hyphenating before character at index"()
安直な手法は、文章を""で囲んで文字列で関数を宣言できればいい
0034デフォルトの名無しさん
垢版 |
2021/02/28(日) 13:01:13.90ID:71c+GuaM
>>32
代替的に空白の代わりにアンダースコアでやる流儀もあるけどたいして読み易くは無いな
should_break_line_by_hyphenating_before_character_at_index()
0037デフォルトの名無しさん
垢版 |
2021/03/01(月) 10:39:57.14ID:EM0+nfQL
語彙力が問題なら>>6ではHTML操作言語を新たに作ればいい
「バベル‐17」では熱核融合炉の仕組みをたったを14語で言い表す言語が出てくる
取り扱う体系がメインかどうかでそれに関する動詞が少ないから語がかさばる

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

これは人間がアホするぎることに起因していて、
基本的な動詞だけで１０万ほどを使い分けるような世界にはヒトは生きてないからだ
なら、もっと超人を考えないと、この長すぎる関数の問題は解決しない
0039デフォルトの名無しさん
垢版 |
2021/03/01(月) 11:47:48.89ID:v3S1R6o9
getAllElements(class='hoge')
getAllElements(tag='input')
getElement(id='hage')

動詞・目的語と条件指定を利便性を考えて分ければいい
allやelementも条件として引数にすることもできる
0040デフォルトの名無しさん
垢版 |
2021/03/01(月) 19:19:35.32ID:tOZ4aduB
>>7 shouldBreakLineByHyphenatingBeforeCharacterAtIndex()
> enterQTKitOnThreadDisablingThreadSafetyProtection()
> getLineFragmentInsertionPointsForCharacterAtIndex()
> invalidateGlyphsOnLayoutInvalidationForGlyphRange()
> glyphRangeForBoundingRectWithoutAdditionalLayout()

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

samurai.NeoArmstrongCycloneJetArmstrongCanon()

だったらどうだ？少しは見やすく...いや、無理があるか？
でも、他の例よりは読めるとは思う
0043デフォルトの名無しさん
垢版 |
2021/04/15(木) 20:48:46.58ID:r6v89LTx
「長すぎる〜」って地の文で悪意のある表現使うのってゲスゴミの常套手段なのな。
0044デフォルトの名無しさん
垢版 |
2021/04/21(水) 07:28:27.76ID:h4pA+hC5
API仕様を見なくても動作が連想できるのなら長くてもメリットがある。
てかいっそのことAPI仕様に書かれている文を全部そのまま関数名にしてみたら面白いかもしれない。
0046デフォルトの名無しさん
垢版 |
2021/05/18(火) 06:40:45.92ID:20CreZYT
１クラス内にメソッドが多過ぎるから
区別のための名前が長大化する予感が
0049デフォルトの名無しさん
垢版 |
2022/03/11(金) 23:07:31.12ID:yjG2Gpx9
昔はhWndとか割と普通に使ってたけど
まぁ、Win32API使う場合は良く出てくるしあんまり変と思わなかったなぁ
hWindowとかフルに書く方が慣れなのか違和感があるなｗ
でもインスタンスはhInstの場合もあるけどhInstanceって書いてあったりとか
統一性が当時でも無かった気はするｗ
hDCとかも慣れでhDeviceContextとか書いている奴は流石にいなかったｗ
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況