[B! code] kiyo_hikoのブックマーク

もう初回コードレビューはずんだもんに任せる時代になった

はじめにGitのステージングエリアにあるファイルを対象に、レビュー結果をSlackに通知するアプリケーションを作成しました。開発環境のターミナルで指定したコマンドを実行するだけで、Slackにレビュー結果が送信されます。ソースコードは以下です。こんな人におすすめコードレビューを受ける前に自分で事前チェックをしたい方一人でコードを書くことが多く、レビュワーがいない方どうせなら楽しくレビューしてもらいたい、好きなキャラクターにレビューしてもらいたい方アプリケーションの構成レビュー依頼の手順と流れ以下のような手順と流れでレビュー結果を得ることができます。レビュー対象のファイルをステージングエリアに登録する︵複数ファイルの登録が可能です︶ローカルのターミナルでaireviewコマンドを実行 Slackに必要な情報が送信されるレビュー結果を確認するスレッドにレビュー結果が

kiyo_hiko 2023/11/05

つよい

リンク

画像対応ChatGPTで設計図からコードの世界が実現しててやばい - きしだのHatena

アマチュア驚き屋のきしだです。 ChatGPTが画像入力に対応するよという話があって、来週くらいに使えるようになるかなーと思ったら、もう使えるようになってました。で、写真から﹁カレー食べてる男の人です﹂くらいを言えるイメージで試してたら、なんかふつうに画面設計やクラス図からコードを書いていてびっくりしてしまいました。まあ、起きたらこういうのが来てたわけですね。で、まあ試してみて﹁あぁ、いままでのマルチモーダルよりちゃんと画像認識してるなー﹂くらいに思ったわけです。で、NetBeansでの画面設計を読ませてみたらこう。こういうコードが生成されました。 import javax.swing.*; import java.awt.*; public class SimpleForm {public static void main(String[] args) { JFrame fr

kiyo_hiko 2023/09/28

つよい

リンク

クソコードを見る度に怖くなる

業務で結構な量のコードレビューを毎日してるんだけど最近マジでクソコードが多い適当に書き殴ったコードなんじゃなくてとにかく思い付いたところからコーディングして実際に動作させたら思い通りに行かないから継ぎ接ぎで修正して最終的に機能を満たしたから完成、PR作成、レビューよろしく、みたいなのが本当に多い無駄な処理が多数含まれているのなんて当たり前だし機能を満たせてるように見えるコードも境界値的なところでバグだらけだったりそういうコードが特に最近増えている問題なのはレビューで指摘した部分が実は今回のPRではなくて既に業務システムに組み込まれてる、とかいうのも多々あってめちゃくちゃヒヤリとするようなコードも多いレビューは数人でやってるんだけど、こういうコードを通してしまう人物に2，3人心当たりがあるしとはいえ人材不足で仕方ないんだろうな、という気がしている多分だけどソフトウェ

kiyo_hiko 2023/07/05

現場からはいいスタイルはあまり真似されないのにハンガリアンやヨーダ条件式がよく真似されてるのを見るが何だろう。自然言語に反する記法が逆にツウっぽく見えてるのかな高級言語は大抵自然言語に寄せたものなのに

リンク

怖い（不気味な）印象を与えるコード進行のご紹介全10パターンホラーなサウンドを表現したいときに使える

﹁怖い﹂﹁不気味﹂などのテーマでコード進行を考えるにあたり、何よりも先に思いつくのがディミニッシュコードを活用するやり方です。 ▼関連ページ 2023.10.04ディミニッシュコード概要と使い方などの解説・パッシングディミニッシュ・セブンス置換そもそもこのコードは特殊な構成音によって成り立つため、単体で鳴らしただけでもそこから不穏なムードが感じられます。こちらでご紹介しているのは、それら二つをルート半音程でつなぎあわせて繰り返しただけのコード進行ですが、怪しい響きが連続することでその怖い雰囲気は増幅します。また、同じような観点から、例えば

kiyo_hiko 2023/04/10

code
作曲

リンク

What are the formal names of operands and results for basic operations?

kiyo_hiko 2023/03/10

ありがたい…

リンク

オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena

「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。オブジェクト同士の連携としてプログラムを組む単一責務の原則インタフェースと実装の分離まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。ダイクストラ先生が

kiyo_hiko 2023/02/25

リンク

どうしてコードにコメントを書きたがらないプログラマーがいるのでしょう？

回答 (51件中の1件目) めんどくさがって書かないのはダメだと思いますが、プログラマー1年生の時に先輩に質問しに言ったら﹁ちゃんとコード読めよ！﹂と何度も言われました。その当時は﹁教えてくれたっていいだろこの短気ジジイ！﹂と思っていました。しかし経験を積んだ今、その先輩が怒っていた意味がよく分かります。だってコメントが無くたってそのコードに意味や意図がしっかりと埋め込まれているのですから。あとコメントとコードの仕様が一致していない箇所を見つけたときにめっちゃ混乱したしイラっとしたこともあります。自分は最初の頃やたらめったらコメント書きまくっていたのですが、他の方も書いている...

kiyo_hiko 2023/01/06

わかるコード書いてりゃ要らんし。最近見たのだとif (TRUE == nanchara) { doKanchara(); }でif前に「もしなんちゃらなら、かんちゃらする」doKanchara右に「かんちゃらする」て同じ事を3度読まされて業腹だった。剰えヨーダ+真値比較

code
style

リンク

スターウォーズの話題を耳にするたびヨーダ記法のことを考えてしまうよね？ - Qiita

ちょっとポエムが書きたくなったのでポエム投稿サービスにお邪魔します。シリーズ最終作の﹃スカイウォーカーの夜明け﹄が封切られ、スター・ウォーズの話題を耳にすることが多くなりましたね。このスターウォーズには銀河の様々な種族が登場することはご存知の通りですが、どのキャラクターも当然ですが英語で話します。もちろん、ハリウッド映画ですからね。しかし、さすが国際標準語の英語だけあり、訛りを使い分けることで﹁なんか国際的な感じ﹂を表現しているのはそれなりに有名な話です。吹き替え版を観ていては全く分からないと思いますが…。ベーシック(銀河標準語)訛り対応表各種族の訛りが英語のどの地域の訛りかの一覧ですスペイン訛りザイゲリアンイタリア訛りワトー日本訛りニモーディアン(ガンレイはタイ) ニュー・ジーランド訛りフェット家&クローンフランス訛りトワイレックロシア訛りグリーヴァスインド

kiyo_hiko 2022/12/27

"Yoda Style, Disable We Must!" 笑った。ヨーダ記法は高級プログラミング言語が英語に近づけることを意図して設計されたことを理解できてない人達の作法でありよくないと思う。

リンク

変数名・関数名の付け方についての個人的ルール - Qiita

はじめにコードを読みやすくする方法としては、コメントを適切につけること、ロジックを単純化すること、機能を分割することなど色々なものがありますが、今回は「名前の付け方」について自分が気をつけていることをまとめてみました。当たり前すぎるものや、逆にあまり一般的でないものもあるかもしれませんが、「こんな方法もあるんだ」くらいの気持ちで読んでいただけると幸いです。サンプルコードはPHPで書いていますが、内容は言語に依存するものではありません。ケースはそれぞれの言語の流儀に従う多くの場合はキャメルケースもしくはスネークケースだと思いますが、基本的に使用する言語の流儀に合わせています。どちらでも良い場合、個人的にはスネークケースの方が読みやすいと感じますが、とにかく統一だけはしましょう。 $stake_case = "これはスネークケースです。"; $camelCase = "これはキャメル

kiyo_hiko 2022/10/12

うーん…俺はこう：①大した事無い処理=短い名前で。名前空間切る：create_url_from_relative_path→Url.rel2absて書くと思う②理解を助けない中間変数置かないget_new_books_listとnew_book_list意味同じ。例えばtodays_等付くなら解るが…

リンク

他人の書いたコードがわからない - Qiita

すでにある程度完成しているプロダクトの開発にたずさわるとき、たいていは﹁コードを書く﹂ではなく﹁コードを読む﹂から仕事を始めることになります。このとき﹁コードが読めない﹂﹁コードがいい感じに理解できない﹂と悩むのは、それほど珍しくないでしょう。この記事では、コードが読めないときにどう対応すればよいかを考えてみました。コードの美しさは気にしないまず重要なのは、コードがどれだけキレイに書かれていようが読めないものは読めない、と割り切ることです。とくにエンジニアになりたての人や自分を責めやすい人にとっては、この考えが大切だと感じます。コードがどれだけ美しくても、自分で書いていないコードは必然的に理解しづらいものです。1というのは、あるコード︵文章︶をただ読むだけで理解するのは難しいからです。社会の教科書を一度読むだけですべてを記憶できた人はいないはずです。︵この理論が正しいことを前提

kiyo_hiko 2022/08/26

今丁度他人の糞ソースを引継いで全然わからん。1ファイル1000個近い変数がありフラグ変数が約130個(何々_flagと、何々_fragとやらが半々)、単発30分岐超のif-else、5重ループなどある。reduceとかガンガン使って直し℡がつらい ●code ●読書術

リンク

【追記あり】プログラミング初心者がTwitterで質問したら「スクールではこんなクソコード教えてんのか」とキツい指摘が飛んできた

みりせっく@雌尻ンダー extends Siri @grandcrawsツイ主が勘違いされて傷ついてるようなので、一旦謝罪とこの場でも補足しますが、初学者のコードは普通汚い。初心者はコードが綺麗か汚いかも判断基準がないから。だから教える側がここは綺麗、ここはまずい、普通はこう書く、特殊な書き方はやめよう、という教えをちゃんとやりなさいっていう話です。 2022-08-17 02:49:22 みりせっく@雌尻ンダー extends Siri @grandcraws @manaboru 正論を言うことと相手を傷付けることは無関係で、傷付けるから正論を言わないは間違いだと思いますよ。傷付かないように正論を言うべきで。で、今回はその配慮が足りず誤解させて傷付けてしまったからそこに対して衆人に見える形でリプで直接謝罪してます。それ以上の話として何を求められてますか？ 2022-08-17 12:2

kiyo_hiko 2022/08/18

何がやりたいコードなのか全然わからん

code
style

リンク

上司「あのさ、コード書くときコメント一切書かないのやめない？」新入社員「え？なんでですか？」 : 暇人＼(^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さん、やっぱりセ○クス

kiyo_hiko 2022/05/10

ウザコメは読み始めにだいたい置換で消してしまうかな。%s/#[\s\d\.\/-]*$//g (日付だけの糞コメ退治) その他で。1日数千〜1万行ぐらいの糞コードを解析しても苦にしない糞コード鉄人になりたい

リンク

個人的にコーディングで心掛けていること - Qiita

3行クソコードは無知から生まれる個人的にコーディングのときに心掛けていることのまとめここに書いてあるのが全て正しいわけではないので参考程度に、という保険クソコードを滅ぼしたいおはようございます。デブです。早速タイトルと趣旨が食い違っているような気がします。さて「クソコード」という言葉があるようにコードにもピンキリがあります。因みにピンキリの語源はポルトガル語のpintaとcruzらしいです(諸説あります)。時としてクソコードは見た者の精神を破壊します。私の場合は、年上で先輩で異性であんまり話したことのない方のコードをレビューしろと言われたときに「今まで何やってきたの？」という感情を常識と礼節でねじ伏せて柔らかく表現しようと言葉を選びまくったときが一番精神にキました。虚空に口汚く文句叫ぶのが一番冷静になれる方法だと学びました。リモートワークで丁度叫びやすいので毎日叫んで

kiyo_hiko 2022/05/10

一部嗜好が合わない(leap_yearはA && (B || C)の形が一番わかりやすい)が、書かれてる内容は概ね賛成できるものだった

リンク

早期リターンを禁止されるつらさ

転職した会社で早期リターンが禁止されている。正確に言うと、misraCを踏襲し、関数内ではreturnは末尾に1つだけ、という制約が設けられている。この他にも関数ポインタが禁止等も色々あるが、早期リターンを禁止されるのは本当に困る。早期リターンによってどれだけ気持ちよくコーディングできるか分かっていない。もうこの後の行は読まなくていいんだ、という精神的安堵感。これをもうこの会社では得られない。関数のポインタ引数のconst禁止程の破壊力がある。地獄のような10重以上のネスト地獄・・・。律儀に守ることによる可読性の低下の方が問題ではなかろうか。

kiyo_hiko 2022/04/23

ガードの事かな？https://qiita.com/kouyan/items/7b8b456b626447a1e24e 俺は禁止されたら `goto <一番後ろ>;` 使う。gotoかわいいよgoto。ちなみにMISRA-CじゃなくてCERT C読むとgotoは一部の状況(08.MEM)で推奨すらされている。割と増田の状況向き ●PG ●code ●style ●c

リンク

ソース修正時にコメント文に残しておきたい項目（参考例付き） - 株式会社キーシステム

新規でシステムを納品して、保守をしていくことになれば、どこかで既存システムに修正を加える必要性が出てくることもあります。それはバグ対応かもしれないし、新規機能の追加かもしれないし、機能カスタマイズかもしれません。そうしたときは、納品時のバージョンからの差分が分かるように、修正箇所には必ずコメントを残しておきましょう。そしてコメントの内容にも気を配るようにしてください。コメントを残す理由まずは修正を加えた際に、コメントを残しておくべき理由から。コメントが活躍するのは修正を行った後になります。再度カスタマイズなどで手が入れることになれば、コメントが残っていることで、その経緯を追いやすくなります。さらにコメントが残っているおかげで、せっかく修正した箇所をつぶしてしまうリスクもなくなります。コメントを残す行為は面倒かもしれませんが、ソース修正時のお約束事とでも言うのか、鉄則だと思ってもら

kiyo_hiko 2022/04/21

さすがにネタだよね？ / 過去に20万行の中規模アプリの保守したとき10万行は履歴コメントでしたってのあったがあんなの二度とやりたくないぞ…。全部「'hist:」とかあればVimでg/'hist:/dして読むがそういう救済措置もない

リンク

Java：if文が多すぎるコードを改善したい

kiyo_hiko 2022/04/12

めんどくさい過ぎてさっぱりわからん…Prologなら多分事実で書けるが。fightMath(0,1,0). fightMath(0,2,1). ...

code
sample

リンク

予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022

PHPerKaigi2022 2022/04/10 10:40〜 Track A レギュラートーク︵40分︶ PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり﹁予防﹂の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 Agenda - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務

kiyo_hiko 2022/04/10

"正しく使用する方が操作ミスをするより簡単" 覚えときたい

code
style

リンク

オオバ@UIエンジニア on Twitter: "仕様変更に強い命名は大事だ。ボタンを﹁OKボタン﹂や﹁Noボタン﹂と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤﹁OKボタンの色を使ってキャンセルボタンを作りたい﹂というケースもある。結論、用途ではなく機械的… https://t.co/6nwzoBNKWR"

● 431 users ● twitter.com/ohbashunsuke ●テクノロジー

仕様変更に強い命名は大事だ。ボタンを﹁OKボタン﹂や﹁Noボタン﹂と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤﹁OKボタンの色を使ってキャンセルボタンを作りたい﹂というケースもある。結論、用途ではなく機械的… https://t.co/6nwzoBNKWR

オオバ@UIエンジニア on Twitter: "仕様変更に強い命名は大事だ。ボタンを「OKボタン」や「Noボタン」と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤「OKボタンの色を使ってキャンセルボタンを作りたい」というケースもある。結論、用途ではなく機械的… https://t.co/6nwzoBNKWR"

kiyo_hiko 2022/02/23

そもそもOK/いいえ、はい/キャンセルの対応が気持ち悪い。OK/キャンセル、はい/いいえでは。vbなどでMessageBoxに渡す列挙子はvbOkOnly、vbOkCancel、vbOkRetryCancel、vbYesNoみたいになってる ●ところで ●antonym ●code ●style

リンク

あなたの「コード読解力」はどれくらい？ | スラド

奈良先端科学技術大学院大学の森崎助教らによると、ソースコードの読解力は個人差が大きく、実験では同じソースコードを理解するための時間に6倍もの差があることが確認できているそうだ︵﹁2,000行のJavaソースコードを読むのに何分かかりますか？﹂︶。といっても、自分の﹁ソースコード読解速度﹂が速いのかそれとも遅いのか、なかなか立ち位置を知るのは難しい。そこで森崎助教らは、研究の一環としてオンラインでのソースコード読解ハンズオンを公開した。これにより自分のソースコード読解能力が他人と比べてどの程度なのかをチェックできるとのこと。また、集計されたデータは個人情報を除去した上で公開されるほか、ソースコードの差分︵パッチ︶とその理解に必要な時間︵コスト︶との関係を明らかにする研究の題材にもなるそうだ。

kiyo_hiko 2021/04/27

かなり苦手だ。ループや分岐が5段越えたあたりで読めなくなる

code
reading

リンク

コードの共通化を原則とするのはアンチプラクティス〜現代のプログラミング原則

(Last Updated On: 2020年1月27日) 同じ処理を行うコードの共通化は、基本的には、ベストプラクティスです。しかし、アンチプラクティスとなる場合もあります。コードの共通化︵モジュール化︶が原則とされた時代もあったコードの共通化︵モジュール化︶とは、同じ／同類の処理を関数などに定義し、同じ処理を繰り返し書かない様にすることです。先に書いた通り、コードの共通化、は基本的にはベストプラクティスです。このため、大昔は”プログラミングの基本原則”として扱われていた時代もありました。しかし、現代では”プログラミングの基本原則”とは考えられていません。コードの共通化︵モジュール化︶とは、同じ／同類の処理を関数などに定義し、同じ処理を繰り返し書かない様にすることは当然の事で絶対にしなければならないことでは？なぜアンチプラクティスになるのか？と思ったかも知れません。 TL;DR;

kiyo_hiko 2021/03/23

あえて共通化を崩しているコードやレポジトリの具体例があるとわかりやすかった

リンク

はてなブックマーク

タグ

関連タグで絞り込む (145)

codeに関するkiyo_hikoのブックマーク (115)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

今週のはてなブックマーク数ランキング（2024年7月第1週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス