もう初回コードレビューはずんだもんに任せる時代になった
はじめに Gitのステージングエリアにあるファイルを対象に、レビュー結果をSlackに通知するアプリケーションを作成しました。 開発環境のターミナルで指定したコマンドを実行するだけで、Slackにレビュー結果が送信されます。 ソースコードは以下です。 こんな人におすすめ コードレビューを受ける前に自分で事前チェックをしたい方 一人でコードを書くことが多く、レビュワーがいない方 どうせなら楽しくレビューしてもらいたい、好きなキャラクターにレビューしてもらいたい方 アプリケーションの構成 レビュー依頼の手順と流れ 以下のような手順と流れでレビュー結果を得ることができます。 レビュー対象のファイルをステージングエリアに登録する（複数ファイルの登録が可能です） ローカルのターミナルでaireviewコマンドを実行 Slackに必要な情報が送信される レビュー結果を確認する スレッドにレビュー結果が
画像対応ChatGPTで設計図からコードの世界が実現しててやばい - きしだのHatena
アマチュア驚き屋のきしだです。 ChatGPTが画像入力に対応するよという話があって、来週くらいに使えるようになるかなーと思ったら、もう使えるようになってました。 で、写真から「カレー食べてる男の人です」くらいを言えるイメージで試してたら、なんかふつうに画面設計やクラス図からコードを書いていてびっくりしてしまいました。 まあ、起きたらこういうのが来てたわけですね。 で、まあ試してみて「あぁ、いままでのマルチモーダルよりちゃんと画像認識してるなー」くらいに思ったわけです。 で、NetBeansでの画面設計を読ませてみたらこう。 こういうコードが生成されました。 import javax.swing.*; import java.awt.*; public class SimpleForm { public static void main(String[] args) { JFrame fr
クソコードを見る度に怖くなる
業務で結構な量のコードレビューを毎日してるんだけど 最近マジでクソコードが多い 適当に書き殴ったコードなんじゃなくて とにかく思い付いたところからコーディングして 実際に動作させたら思い通りに行かないから継ぎ接ぎで修正して 最終的に機能を満たしたから完成、PR作成、レビューよろしく、みたいなのが本当に多い 無駄な処理が多数含まれているのなんて当たり前だし 機能を満たせてるように見えるコードも境界値的なところでバグだらけだったり そういうコードが特に最近増えている 問題なのはレビューで指摘した部分が実は今回のPRではなくて既に業務システムに組み込まれてる、とかいうのも多々あって めちゃくちゃヒヤリとするようなコードも多い レビューは数人でやってるんだけど、こういうコードを通してしまう人物に2，3人心当たりがあるし とはいえ人材不足で仕方ないんだろうな、という気がしている 多分だけどソフトウェ
怖い（不気味な）印象を与えるコード進行のご紹介 全10パターン ホラーなサウンドを表現したいときに使える
「怖い」「不気味」などのテーマでコード進行を考えるにあたり、何よりも先に思いつくのがディミニッシュコードを活用するやり方です。 ▼関連ページ 2023.10.04ディミニッシュコード 概要と使い方などの解説・パッシングディミニッシュ・セブンス置換 そもそもこのコードは特殊な構成音によって成り立つため、単体で鳴らしただけでもそこから不穏なムードが感じられます。 こちらでご紹介しているのは、それら二つをルート半音程でつなぎあわせて繰り返しただけのコード進行ですが、怪しい響きが連続することでその怖い雰囲気は増幅します。 また、同じような観点から、例えば
オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が
どうしてコードにコメントを書きたがらないプログラマーがいるのでしょう？
回答 (51件中の1件目) めんどくさがって書かないのはダメだと思いますが、プログラマー1年生の時に先輩に質問しに言ったら「ちゃんとコード読めよ！」と何度も言われました。その当時は「教えてくれたっていいだろこの短気ジジイ！」と思っていました。 しかし経験を積んだ今、その先輩が怒っていた意味がよく分かります。だってコメントが無くたってそのコードに意味や意図がしっかりと埋め込まれているのですから。 あとコメントとコードの仕様が一致していない箇所を見つけたときにめっちゃ混乱したしイラっとしたこともあります。 自分は最初の頃やたらめったらコメント書きまくっていたのですが、他の方も書いている...
スターウォーズの話題を耳にするたびヨーダ記法のことを考えてしまうよね？ - Qiita
ちょっとポエムが書きたくなったのでポエム投稿サービスにお邪魔します。シリーズ最終作の『スカイウォーカーの夜明け』が封切られ、スター・ウォーズの話題を耳にすることが多くなりましたね。 このスターウォーズには銀河の様々な種族が登場することはご存知の通りですが、どのキャラクターも当然ですが英語で話します。もちろん、ハリウッド映画ですからね。しかし、さすが国際標準語の英語だけあり、訛りを使い分けることで「なんか国際的な感じ」を表現しているのはそれなりに有名な話です。吹き替え版を観ていては全く分からないと思いますが…。 ベーシック(銀河標準語)訛り対応表 各種族の訛りが英語のどの地域の訛りかの一覧です スペイン訛り ザイゲリアン イタリア訛り ワトー 日本訛り ニモーディアン(ガンレイはタイ) ニュー・ジーランド訛り フェット家&クローン フランス訛り トワイレック ロシア訛り グリーヴァス インド
変数名・関数名の付け方についての個人的ルール - Qiita
はじめに コードを読みやすくする方法としては、コメントを適切につけること、ロジックを単純化すること、機能を分割することなど色々なものがありますが、今回は「名前の付け方」について自分が気をつけていることをまとめてみました。 当たり前すぎるものや、逆にあまり一般的でないものもあるかもしれませんが、「こんな方法もあるんだ」くらいの気持ちで読んでいただけると幸いです。 サンプルコードはPHPで書いていますが、内容は言語に依存するものではありません。 ケースはそれぞれの言語の流儀に従う 多くの場合はキャメルケースもしくはスネークケースだと思いますが、基本的に使用する言語の流儀に合わせています。どちらでも良い場合、個人的にはスネークケースの方が読みやすいと感じますが、とにかく統一だけはしましょう。 $stake_case = "これはスネークケースです。"; $camelCase = "これはキャメル
他人の書いたコードがわからない - Qiita
すでにある程度完成しているプロダクトの開発にたずさわるとき、たいていは「コードを書く」ではなく「コードを読む」から仕事を始めることになります。 このとき「コードが読めない」「コードがいい感じに理解できない」と悩むのは、それほど珍しくないでしょう。 この記事では、コードが読めないときにどう対応すればよいかを考えてみました。 コードの美しさは気にしない まず重要なのは、コードがどれだけキレイに書かれていようが読めないものは読めない、と割り切ることです。とくにエンジニアになりたての人や自分を責めやすい人にとっては、この考えが大切だと感じます。 コードがどれだけ美しくても、自分で書いていないコードは必然的に理解しづらいものです。1 というのは、あるコード（文章）をただ読むだけで理解するのは難しいからです。社会の教科書を一度読むだけですべてを記憶できた人はいないはずです。（この理論が正しいことを前提
【追記あり】プログラミング初心者がTwitterで質問したら「スクールではこんなクソコード教えてんのか」とキツい指摘が飛んできた
みりせっく@雌尻ンダー extends Siri @grandcraws ツイ主が勘違いされて傷ついてるようなので、一旦謝罪とこの場でも補足しますが、初学者のコードは普通汚い。初心者はコードが綺麗か汚いかも判断基準がないから。だから教える側がここは綺麗、ここはまずい、普通はこう書く、特殊な書き方はやめよう、という教えをちゃんとやりなさいっていう話です。 2022-08-17 02:49:22 みりせっく@雌尻ンダー extends Siri @grandcraws @manaboru 正論を言うことと相手を傷付けることは無関係で、傷付けるから正論を言わないは間違いだと思いますよ。傷付かないように正論を言うべきで。で、今回はその配慮が足りず誤解させて傷付けてしまったからそこに対して衆人に見える形でリプで直接謝罪してます。それ以上の話として何を求められてますか？ 2022-08-17 12:2
上司「あのさ、コード書くときコメント一切書かないのやめない？」新入社員「え？なんでですか？」 : 暇人＼(^o^)／速報
上司「あのさ、コード書くときコメント一切書かないのやめない？」新入社員「え？なんでですか？」 Tweet 1: 以下、？ちゃんねるからVIPがお送りします 2021/06/18(金) 12:54:03.530 ID:Qcns98Vpd.net 仕事なめてんの？ 3: 以下、？ちゃんねるからVIPがお送りします 2021/06/18(金) 12:54:37.867 ID:qtc0Smbhp.net 答えてあげろよ 5: 以下、？ちゃんねるからVIPがお送りします 2021/06/18(金) 12:55:18.370 ID:NCJ/91nx0.net ちゃんと新人教育しろよ 仕事舐めてるの？ 7: 以下、？ちゃんねるからVIPがお送りします 2021/06/18(金) 12:56:22.771 ID:ERxcY2PQ0.net おまえ誰だよ 【おすすめ記事】 ◆パパ活JKさん、やっぱりセ○クス
個人的にコーディングで心掛けていること - Qiita
3行 クソコードは無知から生まれる 個人的にコーディングのときに心掛けていることのまとめ ここに書いてあるのが全て正しいわけではないので参考程度に、という保険 クソコードを滅ぼしたい おはようございます。デブです。 早速タイトルと趣旨が食い違っているような気がします。 さて「クソコード」という言葉があるようにコードにもピンキリがあります。 因みにピンキリの語源はポルトガル語のpintaとcruzらしいです(諸説あります)。 時としてクソコードは見た者の精神を破壊します。 私の場合は、年上で先輩で異性であんまり話したことのない方のコードをレビューしろと言われたときに「今まで何やってきたの？」という感情を常識と礼節でねじ伏せて柔らかく表現しようと言葉を選びまくったときが一番精神にキました。 虚空に口汚く文句叫ぶのが一番冷静になれる方法だと学びました。リモートワークで丁度叫びやすいので毎日叫んで
ソース修正時にコメント文に残しておきたい項目（参考例付き） - 株式会社キーシステム
新規でシステムを納品して、保守をしていくことになれば、どこかで既存システムに修正を加える必要性が出てくることもあります。それはバグ対応かもしれないし、新規機能の追加かもしれないし、機能カスタマイズかもしれません。 そうしたときは、納品時のバージョンからの差分が分かるように、修正箇所には必ずコメントを残しておきましょう。そしてコメントの内容にも気を配るようにしてください。 コメントを残す理由 まずは修正を加えた際に、コメントを残しておくべき理由から。 コメントが活躍するのは修正を行った後になります。再度カスタマイズなどで手が入れることになれば、コメントが残っていることで、その経緯を追いやすくなります。さらにコメントが残っているおかげで、せっかく修正した箇所をつぶしてしまうリスクもなくなります。 コメントを残す行為は面倒かもしれませんが、ソース修正時のお約束事とでも言うのか、鉄則だと思ってもら
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク（40分） PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 Agenda - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務
オオバ@UIエンジニア on Twitter: "仕様変更に強い命名は大事だ。ボタンを「OKボタン」や「Noボタン」と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤「OKボタンの色を使ってキャンセルボタンを作りたい」というケースもある。結論、用途ではなく機械的… https://t.co/6nwzoBNKWR"
仕様変更に強い命名は大事だ。ボタンを「OKボタン」や「Noボタン」と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤「OKボタンの色を使ってキャンセルボタンを作りたい」というケースもある。結論、用途ではなく機械的… https://t.co/6nwzoBNKWR
あなたの「コード読解力」はどれくらい？ | スラド
奈良先端科学技術大学院大学の森崎助教らによると、ソースコードの読解力は個人差が大きく、実験では同じソースコードを理解するための時間に6倍もの差があることが確認できているそうだ（「2,000行のJavaソースコードを読むのに何分かかりますか？」）。 といっても、自分の「ソースコード読解速度」が速いのかそれとも遅いのか、なかなか立ち位置を知るのは難しい。そこで森崎助教らは、研究の一環としてオンラインでのソースコード読解ハンズオンを公開した。これにより自分のソースコード読解能力が他人と比べてどの程度なのかをチェックできるとのこと。また、集計されたデータは個人情報を除去した上で公開されるほか、ソースコードの差分（パッチ）とその理解に必要な時間（コスト）との関係を明らかにする研究の題材にもなるそうだ。
コードの共通化を原則とするのはアンチプラクティス 〜 現代のプログラミング原則
(Last Updated On: 2020年1月27日) 同じ処理を行うコードの共通化は、基本的には、ベストプラクティスです。しかし、アンチプラクティスとなる場合もあります。 コードの共通化（モジュール化）が原則とされた時代もあった コードの共通化（モジュール化）とは、同じ／同類の処理を関数などに定義し、同じ処理を繰り返し書かない様にすることです。 先に書いた通り、コードの共通化、は基本的にはベストプラクティスです。このため、大昔は”プログラミングの基本原則”として扱われていた時代もありました。しかし、現代では”プログラミングの基本原則”とは考えられていません。 コードの共通化（モジュール化）とは、同じ／同類の処理を関数などに定義し、同じ処理を繰り返し書かない様にすることは当然の事で絶対にしなければならないことでは？なぜアンチプラクティスになるのか？と思ったかも知れません。 TL;DR;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What are the formal names of operands and results for basic operations?
早期リターンを禁止されるつらさ
Java：if文が多すぎるコードを改善したい