その変数名だけはやめろ：頼むから analysis を anal と略さないでください
Linux には /tmp という一時ファイル用のディレクトリがあるので tmp は許容範囲である。というか日本語読みなので英語圏にこのネタは通じない。cng, mng, unk も同様である。cnt は英語圏でも普通に使われる変数名のようで、ass や anal ほどの忌避感はないようである。 最悪な変数名は anal_check や anal_insert である。from anal import * も芸術点が高い[1]。 叩いた回数の累積などを cumshot（「射精」のスラング）にするのも割と最悪みがあるようだが、日本人にはあまり伝わらないという意味でそこまででもない。 以下、改善案。 変数名 改善案 理由
プログラミングの原則：構造化テキストを文字列結合で作らない、置換でいじらない - Uzabase for Engineers
こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 先日から『Ghost of Tsushima』の開発者が書いた『ルールズ・オブ・プログラミング』という本をちょっとずつ読み進めていて、プログラミング熱が高まっています。この本は大きな指針を示すだけで具体の話をするものではないのですが、読み物として面白いので私も似たようなことをやってみたくなりました。 何年もこういう仕事をしているとバグが入るパターンというのが見えてきます。そしてだいたいどこに行っても何の仕事でも似たようなことをすることになるのですが、今回の話もその一つです。 構造化テキストを文字列結合で作らない、置換でいじらないというのはこれだけみると何のことか分かりづらいかも知れませんがSaaS Product Team セキュアコーディングの啓蒙 第2回 （SQL インジェクション編）の内容とある面では同じ話です。
きれいなコードを書けという話について - Software Transactional Memo
前回のブログから90日以上経ってしまったので広告が載ってしまったから短文でもアウトプットしておく。 プログラマとして仕事をしているとコードと向き合っている時間の9割以上は既存のコードを読んでいる、だから読みやすさは重要である、という言説は耳にタコができるほど誰もが言っている。 仕事で書かれるコードが誰のレビューも通ること無くマージされている現場は凄惨だが、自分より明らかに経験を積んだ人たちが何度もレビューを重ねたコードが読みやすいかというとそうとは限らない。良いコードが守るべきルールをすべて守っていても不可解なコードはあるし、どんなに読みやすいコードでも数千行の規模になってくるとやはり脳内からこぼれて一度に覚えておける範囲からはみ出る。 変数名や関数名をわかりやすくするとか不必要な技巧を凝らさないとかわかりやすい設計にするとか主観的な事を偉そうに語る本は山ほどあり、それらの本を崇める事は悪
Javaでプログラムを書く際に意識しておきたいこと - 覚えたら書く
以下、個人的にJavaでプログラムを書く際に意識しておきたいことです。 ただし、学術的な裏付けなどがある内容でありません。あくまで私の経験に由来する内容となっています。 そもそもコンテキストによってはそぐわない内容もあると思いますので、その辺はうまいことスルーしてもらえたらと思います。 Collection 空のList メソッドの戻り値として空（size==0）のListを返却する場面がありますが、その場合はCollections.emptyListを使うのが良いです。 new ArrayList()でListを生成してreturnするよりも、処理も早くコードの意味も分かりやすくなります。 ただし、このメソッドで返されるListはImmutable（不変）であることを理解しておく必要があります。 Collectionsクラスには、空Setや空Mapを返すメソッドも用意されています。 大量
バリューオブジェクト - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/ValueObject.html プログラミングをする時、物事を複合物として表現すると便利だと思うことがよくあります。 例えば、2次元座標はx軸とy軸で構成されます。お金の額面は数値と通貨で構成されます。日付の範囲は開始日と終了日で構成されます。日付は年、月、日で構成されることもあります。 これを実践してみると、2つの複合オブジェクトが同じものであるかどうかという疑問が湧いてきます。 例として、2つの点オブジェクトを考えてみましょう。それらは両方とも(2,3)のデカルト座標を示しています。この2つの点オブジェクトを等価として扱うことは理にかなっています。 プロパティの値が同じであるオブジェクト（この場合のプロパティはx座標とy座標）はバリューオブジェクトと呼ばれます。 しかしながら注意してプログラミングしないと、意図した動作になら
プログラムは思った通りには動かない。書いたとおりに動くのだ
プログラムは思った通りには動かない。書いたとおりに動くのだ Any code doesn't run as you thought, run as it wrote 2015.06.17 Updated by Ryo Shimizu on June 17, 2015, 10:13 am JST
ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try
はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな
【Java】ジェネリックス型の不変、共変、反変とは何か - The King's Museum
今回はジェネリックスの不変、共変、反変について書いてみた。 本当は Effective Java 「項目２５：配列よりリストを使う」の予定だったんだけど、不変、共変、反変あたりの話がでてきて、 ここらへんは以前からまとめておきたかったし、ちょうどよいと思って記事にした。 不変、共変、反変 不変、共変、反変とはそれぞれ、ジェネリクスの性質を指す用語です。 話を具体的にするため、例として List<E> と、Object、String を使って説明します。 Java の Object、String には以下のような関係があります。 Object は String のスーパータイプである この時、Object と String に対してパラメータ化された型である List<Object> と List<String> の関係性はどうなるでしょうか？ 可能性として、以下のような組み合わせを考えるこ
また初心者にプログラミングを教える機会があった
プログラミングでわからないところがあるので教えてほしいと以下のようなことを聞かれた。 こういうJavaScriptの関数がある。 // valuesは配列 // elementはvaluesの要素型の値 // 配列valuesに値elementと等しい要素があるならばそのインデックスを返す。 // それ以外の場合、-1を返す function find_index( values, element ) { for ( let i = 0 ; i !== values.length ; ++i ) { if ( values[i] === element ) return i ; } return -1 ; } 質問は、「なぜreturn -1にelseはいらないのか」というものであった。 似たような問題に、昔遭遇した気がするが、別人だ。 まずここにelseを書くべき文法はJavaScrip
プログラミング言語はひとつマスターすれば他もできる？ - t-hom’s diary
プログラミングでは、ひとつの言語をマスターすれば、どんな言語でも使えると言われている。 この言説には賛否あるけど、ある意味正しくて、ある意味間違いだと思う。 より正確に言えば、新しく学ぶ言語と既にマスターしている言語に共通する概念についてはスムーズに移行できるということだ。 たとえば変数・分岐・繰り返し・比較演算なんかは、大半の言語が備えている共通概念である。言語によって作法やスタイルが異なるだけで考え方は同じなので、新しく学習する言語でこれらを使いこなすのは難しくない。 仮にVBAを100%マスターしているなら、Pythonの学習範囲はPython特有の部分だけで済む。 まあそうは言ってもなかなか一つの言語をマスターするのは難しい。 VBAの学習割合が少なければ、Pythonをマスターするための学習範囲はより広くなる。 じゃあまずはVBAを極めよう！と考えるかもしれないがそれも早計である
Fixed-point arithmetic - Wikipedia
This article is about fixed-precision fractions. For the invariant points of a function, see Fixed point (mathematics). This article possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (September 2019) (Learn how and when to remove this message) In computing, fixed-point
"call by reference"ではない動作を「参照渡し」と言っている記事まとめ - Qiita
C++、C#、PHP等には"call by reference"という機能があります。ですが、この"call by reference"ではない動作を「参照渡し」と言っている記事をまとめました。対象には表記揺れにすぎない「参照呼び」や「参照呼び出し」も含めています。 他にもある、とか、実は否定しているとかあればコメントや修正依頼をください。ただし、追記や脚注など目立たない形で「実はそうは言わない」などと補足があったり、コメント等でそのような指摘があっても、全ての読者がそこまで細かく見るとは限らないため、除外しません。つまり、厳密には違うとか、機能ではなく動作のことを言っているとか色々言い訳を付けていても、表面だけ読んでいると「『参照渡し』と言っても良い」と読み手が感じられそうであれば、対象としています。 "call by reference"な動作とは？ 定義や詳しい動作の解説はここではし
数値計算屋にはFortranは捨てなくても良いけどソフトウェアエンジニアリングを学んでほしい - HPCメモ
twitterでこちらの記事をみかけたので、Fortran完全に理解したエンジニアの一人として便乗記事を書いときます。 qhapaq.hatenablog.com ちなみに、私は学生時代からかれこれ20年近く数値計算屋をやってますが、メインの言語はC、C++、Pythonときて今は主にJavascriptを使ってます。とはいえ、就職してからは基本的にチューニング屋なので、普通の数値計算屋さんの数倍は他人の(主にFortran)コードを読み書きしてきたと思っています。その中で日頃感じていたもやもやをこの機会にまとめてみました。 元記事には3つFortranを捨てるべき理由が挙げられていますが、個々の内容に対しては概ねその通りだと思います。(細かいところで異論は色々とあるんですが、そこは本筋ではないので省略します) ところが、残念ながらFortranを捨てても何も解決しないのです。 私が今まで
お前は絶望的にプログラミングに向いてないから諦めて刺身にタンポポ乗せる仕事でもやってろ｜古都こと｜note
刺身にタンポポ乗せる仕事ってきょうび言わねーな……。 プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…！」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。 近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。 開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のもの
適切に抽象化されたコードとはなにかって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
適切に抽象化されたコードを書く、というのはまさに言うは易し行うは難しだ。 最近私が心がけていることのうちのひとつに、「未来を予測しない」というのがあって、「ここはあとから変更とか追加があるかもしれない」と思って抽象化しておくみたいなことはやめようと思ってる。ひとことで言うと、よくYAGNIとか言われるアレです。 そもそも、なんのために抽象化するのかというということを考えると、ひとつは「一塊の手続きに名前を付けて隠蔽して外から中を意識しないで済むようにする」ってことと、その副産物として「交換可能性が高まる」っていうのがある。 抽象化して実装を隠蔽することで、 コードが理解しやすくなる インターフェイスさえ合ってれば交換可能な部品として扱えるようになる という利点があるから、わたしたちは抽象化を行うわけだ(だからこそ「名前重要」なわけですね)。 この後者の利点に注目すると、ついつい「あっあとか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ロベールのＣ＋＋教室 - 第５６章 クロスキャスト -
DRY原則と直交性について | h19e
RAII - Wikiwand
ケバブケース（kebab-case）について調べた - Qiita
コメント内の TODO, FIXME, XXX の意味とか。 - public class Monry extends Dairy implements Hatena
