同僚の書く酷いコード、どうやって気づかせる？ | スラド デベロッパー
私の同僚は非常に頭がよく、ソフトウェアの知識も豊富だが、想像を絶するほどひどいコードを書く。たとえば、 すべてのプログラムは1つの関数に詰め込まれ、際限ない繰り返しのせいで無駄に引き伸ばされている 変数名やクラス名から得られる情報は泣きたくなるほど少ない コードを短く、読みやすくするための基本的な言語機能は無視されている オブジェクト指向プログラミングの虐待は吐き気を催すほどで、戦争犯罪レベルといえる しかし、彼は私が生まれる前からプログラミングをしており、非常に頭が良いことで、人の意見に耳を貸そうとしない。そのため、「この関数をこのように書いたら良くなると思いませんか」といった簡単な提案は受け入れられないだろう。彼に事実を伝え、良いコードと悪いコードの区別をわかってもらうにはどうすればいいだろうか。
キミのコードが汚い理由 ― ＠IT情報マネジメント
リスト1は、同じ処理を繰り返すようなコードで初心者プログラマーがよく使う幼稚なスタイルで書かれている。必ずしも複雑ではないが、筆者には散らかっていて効率が悪く見える。リスト2の方が複雑な条件になっているが、Javaを理解していれば、かなり読みやすい。唯一疑問を抱くかもしれないとしたら、最後の「else if」の中にある条件の最初の部分だけだ。このクローズに来るということは、どちらかのプレーヤーが勝ったことを意味する。 いずれのインプリメンテーションも間違ってはいない。実際、これらはどちらも非常に小さく、つまらない例にすぎないので、これらのリストでコードがいかにクリーンか論ずるのはあまり有益ではない。ただ、何をもってインプリメンテーションがクリーンなのかについて読者の興味を深めることはできるだろう。 クリーンなコードについて扱った記事、Webサイト、書籍は多数存在する。何をもってコードをクリ
非エンジニアに無念コードがなぜダメなのかを説明するメタファー - Yamashiro0217の日記
非エンジニアに無念コードがなぜダメなのかを説明するメタファーを考えてみた。 目的は、無念コード・設計・環境・フローがあると、 いかに生産性が落ち、ビジネスがうまくいかないか、 プログラマーの心が病むかを、 なるべくエンジニアリングの用語を使わないで説明すること。 他にいいメタファーあったら、ブクマやらコメントやら、ブログ別書くなどして、 世界を幸せにしてもらいたい。 メタファー エンジニアリングとは部屋の掃除と一緒である ストーリー導入 あなたは、ある日、引越しを決意しシェアハウスに引越しました。 引越した先のシェアハウスのリビングは、 それはもう汚い。 散らかり放題、生ゴミ、壁の汚れ。 さぁ。どうしましょう。 さらに引っ越すという手段もありますが、 あなたは、リビングの掃除を試みるのでした。 ストーリー2 片付けをしていたある日、あなたは、 「リビングの中に、俺の鍵（機能や、コードなど）
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
会社員の立場と実力は運が7割、選択が1割、残りは努力 - 感謝のプログラミング
悪い意味での典型的なSIエンジニアの口癖は、 「なんで○○なの？」 だ。 なんでそうなるのかを興味があるのではなく、否定するためになぜなぜ聞いてくるのだ。 説明できなければ、「×」。 こういう人とは建設的な議論にならない。 そういう人と話していても、話は広がらない。 雰囲気が悪くなるし、とりあえず否定しようと構えている人とやる仕事に良いアイデアは降ってこない。そのうち案も出なくなる。 それが続くと、無難なことしか言わない非イノベーティブなSIエンジニアの出来上がりだ。 一方で、(悪い意味での)典型的SIエンジニアには、 「これはこうだから、こうした方がいいんじゃない？」 という人は少ない。 対案を出すだけの技術的な素養はないからだ。 技術的な裏付けはなくても否定はできる。 プロ野球の観戦者や国の政策を否定するオバサンと同じで、 否定するのは実はすごく簡単なのだ。 そもそもどのような場合も完
ソースコードを読むためのツール : Mazn.net
2009年01月26日00:35 ソースコードを読むためのツール カテゴリIT技術oss CodeReadingWikiを改造してみました → こちら 現在多くのアプリケーションのソースコードがネット上に公開されています。他人のソースコードを読むのは結構骨の折れる作業で、これを手助けしてくれるツールがいくつかあります。特にブラウザ上でHTMLのリングを用いてソースを追っかけるツール、Code Reading(コードリーディング)やCode Viewer(コードビューア)、Code Brower(コードブラウザ)、もっと広い範疇ではソースコードタグシステムとか呼ばれているものです。 私は個人的にLXRを使っていました。また、gonzuiやGNU Globalも似たソフトウェアです。これらのソフトウェアを利用することで、関数や変数の定義場所、使用されている場所等がマウスクリックで追いかけら
エンジニアが稼げるコードナレッジ共有ツールCodeLibrary
6. 「俺ぜんぜんコード読まないw」 親友A 知人B 彼女C どうりで 彼氏がコード おまえ、 人間の屑だと 読まないエンジニア うんこだな 思った だった。別れたい... 2012年3月29日木曜日
ifとreturnの使い方 - 2012-03-28 - ククログ
はじめに わかりやすいコードを書くことはソフトウェア開発において大切なことです。では、具体的にわかりやすいコードとはどんなものでしょうか？その観点はいろいろなものがあります。その中で今回はifとreturnの使い方に注目します。 ifとreturn プログラミング言語とは、コンピューターの作業の処理手順を書くためにあります。その処理手順は複数にわかれています。その複数の処理手順を順番に実行していくことでコンピューターは作業をこなしていきます。 プログラミング言語にはいろいろな処理手順を書くためにifとreturnと呼ばれる機能があります。ある処理手順をある時だけ実行したい場合には、ifを使います。その時以外はその処理手順は実行しません。また、続きの処理手順があるがその時点で実行を中断したい場合には、returnを使います。続きの処理手順は実行しません。ifとreturnと組み合わせることで
自分のコード綺麗って思ってんの？ - ✘╹◡╹✘
guideline.gem https://github.com/r7kamura/guideline 恐怖体験があって、震え上がり、少しでも綺麗なコードが書けるようなGemつくってる。複雑過ぎるメソッドや、使われていないメソッドが定義されていないかとか、長過ぎる行を書いてないかとか、簡単なチェックを自動化できる。こういうコードは綺麗ではないみたいなことがふわっと言われているよりは、綺麗ではないコードというのがコードで表現されている方が安心感があると思った。もしコーディングルールとして文書化したのでみんな守ろうみたいな感じにしても、コードを書くときに常にそれを覚えていなければ意味がないし、常にそういうことを気にしながら、ずっと緊張しながらコードを書かないといけない。そういう風に常に何かに気を配りながら作業するというのは、意識は高いけど、疲れるから極力やりたくないし、そもそも新しくその文化に
nakano_neko, 画像の右側が外注さんに頼んだソースコード。左側が僕が書きなおしたソースコード。...
画像の右側が外注さんに頼んだソースコード。左側が僕が書きなおしたソースコード。 仕事をお願いしたのに、自分で修正するのって本当にバカバカしい。 そういうプログラムにお金を払うって本当にバカバカしくて涙がでてくる。 facebookに書いた文章なんだけど、ちょっと加筆して、tumblrに公開してみる。 外注さんを探す時の参考にしてもらえれば幸い。 作業が重なると自分のトコだけで捌けなくなる時が時々あるので、外注さんを増やす努力をしてる。 んで、先日･･･ ネット上で「プログラム組みます」的なセールスをしていた個人に仕事をお願いした。 ただ、最初から雲行きが怪しかった… 屋号を名乗るだけで個人名は開示しない、 こちらの名前は間違えたまま、指摘しても謝罪も無し･･･ ちょっと怪しい臭いはしたんだけど、技術には自信があるようなので簡単な仕事をお願いすることに。 まず、お見積りをお願いする。 お見積
［Prolog］[Tips] 美しいPrologのコードの書き方(1) - negationの日記
Prologのコードを美しく書くにはどうしたらいいか？。少々ボリュームがあるので、根気のある人だけ読んでくださいw。でもきっとためになります。 まずPrologを書くに当たって、重要なことは「引数の性質が何であるか」と言うことです。 Prologの引数には3つの性質があります。 定数としての引数。これはhoge(+bar)とSWI-Prologのhelpに書かれています。 処理した後に値を返すための引数。hoge(-bar)。 上記どちらでも良い引数。hoge(?bar)。 たとえば、times(X,Y,Z)という述語を考えてみます。これは「X*Y=Z」という意味としましょう。このコードは以下のようになります。 times(X,Y,Z):- Z is X * Y. あ、「｀*’使ってたら意味ないじゃん」というつっこみは無しでw。例ですからw。このときもし ?- times(X,Y,3).
![［Prolog］[Tips] 美しいPrologのコードの書き方(1) - negationの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/bbfea157608b38a61d2a061b70f3c8e35d62a7b1/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127137911909%2F17680117127137923834%2F1558077720)
CodeBlocks - OpenCV Wiki
Code::Blocks is an GPL based and cross-platform IDE. This is the tutorials using Code::Blocks with OpenCV. Create a simple console project. We can use project wizard to create a simple console project. Here is the steps Give this project name of "test_opencv" Then copy the sample code to main.cpp Configure the OpenCV include path and libs Right click on the project manager and open the "Build Op
ハッカーは Lisp/Perl/Ruby/Python で書こうが Java/C++/C# で書こうが、良いコードを書く
Prev / Next / /home/pochi/ChangeLog ハッカーは Lisp/Perl/Ruby/Python で書こうが Java/C++/C# で書こうが、良いコードを書く[computer] http://tokuhirom.dnsalias.org/~tokuhirom/inamode4/1317.html まったくそのとおり。 重要なのは、言語じゃなくて、センス。 じゃあ、その、センス、って何って言われると、 なかなか難しい。 センスが良い悪いは多分に主観的な物で人によって おそらくぶれがある。 なので、センスがある、と言われるようになるためには 人に合わせる、という能力が必要な気がする。 良い考え方を真似る能力というかパクる能力というか。 ただそのセンスってものは、あくまで各人の主観的なもので、 そんなもので計られちゃかなわん、という意見もまあわかる。 でもねえ
if文 - Wikipedia
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2024年2月） 独自研究が含まれているおそれがあります。（2024年2月） 出典検索?: "If文" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL if文（イフぶん、英: if statement）は、プログラミング言語において、真理値に従って「もし条件Cが満たされるならば、Xを実行せよ」というような条件付き実行の「文」で、制御構造のひとつである。一般的にif文は「もし条件Cが満たされるならば、Xを実行せよ、さもなくばYを実行せよ」というように条件が満たされなかった場合の分岐もオプション（省略可能）として同時にサポートすることが多く、if-
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
再利用の罠
再利用の罠2003-02-21再利用再利用と声高に叫んだプロジェクトほど失敗します。再利用しようとしてはいけません。手段が目的になってしまわないようにしましょう。 ソフトウェア開発では「再利用」というのがスローガンになることがよくあり ます。「常に再利用を考えよう」「再利用可能な設計をしよう」と。ソフトウェ ア開発関連の本の多くは「再利用のための」とか「再利用できる」といった言 葉が帯や表紙に並んでいます。しかしここできっぱりと言っておきます。「再 利用」は「罠」です。再利用をしようとしてはいけません。再利用再利用と声 高に叫んだプロジェクトほど失敗します。 問題なことに、世間では「オブジェクト指向」と「再利用」が切っても切れな い関係として認識されています。オブジェクト指向技術は再利用のためにあり、 再利用を推し進めるにはオブジェクト指向技術を取り入れるのがいい、と。そ して再利用を重視
変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々
2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ゲストブック閉鎖
Code Golf | Home
コメント書うんたの詳細情報 : Vector ソフトを探す！