もう初回コードレビューはずんだもんに任せる時代になった
はじめに Gitのステージングエリアにあるファイルを対象に、レビュー結果をSlackに通知するアプリケーションを作成しました。 開発環境のターミナルで指定したコマンドを実行するだけで、Slackにレビュー結果が送信されます。 ソースコードは以下です。 こんな人におすすめ コードレビューを受ける前に自分で事前チェックをしたい方 一人でコードを書くことが多く、レビュワーがいない方 どうせなら楽しくレビューしてもらいたい、好きなキャラクターにレビューしてもらいたい方 アプリケーションの構成 レビュー依頼の手順と流れ 以下のような手順と流れでレビュー結果を得ることができます。 レビュー対象のファイルをステージングエリアに登録する（複数ファイルの登録が可能です） ローカルのターミナルでaireviewコマンドを実行 Slackに必要な情報が送信される レビュー結果を確認する スレッドにレビュー結果が
"レガシー"と言われないためのJavaScript再入門
追記: 10/11 ハテブでバズっているようで、色々指摘があったので追記 getElement*は動作が早いのでIDやクラス名が自明の場合はgetElement*を使う方がいいと言う意見もあり、また、ページの表示で大量に呼び出されるわけではないからボトルネックにはならないと言う意見もある。 getElement*で返されるオブジェクトは動的な変化に対応しており、querySelector*は動的な変化に対応していないため、場合によってはgetElement*を使うといい。このサイトで遊んでみよう。 https://ja.javascript.info/searching-elements-dom#ref-263 for await ... ofは非推奨なので Promise.allを現代的な書き方にした 顧客先のブラウザが古い場合も考慮して、あえてレガシーな書き方もする場合があるらしい。現
クソコードを見る度に怖くなる
業務で結構な量のコードレビューを毎日してるんだけど 最近マジでクソコードが多い 適当に書き殴ったコードなんじゃなくて とにかく思い付いたところからコーディングして 実際に動作させたら思い通りに行かないから継ぎ接ぎで修正して 最終的に機能を満たしたから完成、PR作成、レビューよろしく、みたいなのが本当に多い 無駄な処理が多数含まれているのなんて当たり前だし 機能を満たせてるように見えるコードも境界値的なところでバグだらけだったり そういうコードが特に最近増えている 問題なのはレビューで指摘した部分が実は今回のPRではなくて既に業務システムに組み込まれてる、とかいうのも多々あって めちゃくちゃヒヤリとするようなコードも多い レビューは数人でやってるんだけど、こういうコードを通してしまう人物に2，3人心当たりがあるし とはいえ人材不足で仕方ないんだろうな、という気がしている 多分だけどソフトウェ
なぜ <div> に onClick がダメなのか？
■ はじめに <div>要素にonClickを渡すべきではない、ということ聞いたことはないでしょうか？ ただ、なぜ渡すべきでないのか？ 理解してなかったので今回調べてみました。 サンプルコード 今回動作確認に利用したサンプルリポジトリのコードはReactで書いています。 ■ 結論：<div>にonClickを定義するのがなぜダメなのか？ ユーザーにとって操作性の低いボタンになってしまうから、です！ 要するに UX が悪くなってしまうから！ その理由を解説していきます！ ■ 操作性の低いボタンになってしまう理由 大きく３つあると考えています。 div要素は focus を持たないから returnキー, spaceキーをonClickに変換しないから スクリーンリーダーが認識しない要素だから ◎ focus を持たないから <div>要素はfocusを持ちません。 なので、tabキーで要素に
米誌「今年の10台」に日本車8台 ブランドランキングも日本勢が1位2位を独占
米消費者情報誌の『コンシューマー・レポート』（以下「CR」）は毎年、「トップ10ピックス」と題し、優れた自動車10台を選定している。今年も傑作揃いのランキングが発表された。10モデル中、8モデルを日本ブランドが占めている。 ◆日産、トヨタ……トップ10の多くを占める 製品カテゴリごとのトップを集めた今年の10台は、以下のような顔ぶれとなった。米フォーブス誌は、「日本ブランドが支配」と報じる。 日産 セントラ（2022年式） 日産 ローグ スポーツ（2022年式） スバル フォレスター ウィルダネス（2022年式） トヨタ プリウス（2022年式） ホンダ アコード ハイブリッド（2021年式） トヨタ RAV4 プライム（2021年式） キア テルライド（2022年式） ホンダ リッジライン（2021年式） レクサス RX450h（2021年式） フォード マスタング マッハE（2022年
オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が
どうしてコードにコメントを書きたがらないプログラマーがいるのでしょう？
回答 (51件中の1件目) めんどくさがって書かないのはダメだと思いますが、プログラマー1年生の時に先輩に質問しに言ったら「ちゃんとコード読めよ！」と何度も言われました。その当時は「教えてくれたっていいだろこの短気ジジイ！」と思っていました。 しかし経験を積んだ今、その先輩が怒っていた意味がよく分かります。だってコメントが無くたってそのコードに意味や意図がしっかりと埋め込まれているのですから。 あとコメントとコードの仕様が一致していない箇所を見つけたときにめっちゃ混乱したしイラっとしたこともあります。 自分は最初の頃やたらめったらコメント書きまくっていたのですが、他の方も書いている...
スターウォーズの話題を耳にするたびヨーダ記法のことを考えてしまうよね？ - Qiita
ちょっとポエムが書きたくなったのでポエム投稿サービスにお邪魔します。シリーズ最終作の『スカイウォーカーの夜明け』が封切られ、スター・ウォーズの話題を耳にすることが多くなりましたね。 このスターウォーズには銀河の様々な種族が登場することはご存知の通りですが、どのキャラクターも当然ですが英語で話します。もちろん、ハリウッド映画ですからね。しかし、さすが国際標準語の英語だけあり、訛りを使い分けることで「なんか国際的な感じ」を表現しているのはそれなりに有名な話です。吹き替え版を観ていては全く分からないと思いますが…。 ベーシック(銀河標準語)訛り対応表 各種族の訛りが英語のどの地域の訛りかの一覧です スペイン訛り ザイゲリアン イタリア訛り ワトー 日本訛り ニモーディアン(ガンレイはタイ) ニュー・ジーランド訛り フェット家&クローン フランス訛り トワイレック ロシア訛り グリーヴァス インド
my_programming_style - Qiita
はじめに これは宗教である。 名前の付け方 「名前は機能とスコープに比例する」 機能に比例させる 機能が単純なら、名前も単純にする。 例えば、オブジェクトの属性などはほぼ無コストで取得できる。こういったものはname()やlength()といった単純な名前にする。単純な名前が処理の単純さを表している。 一方、データを追加したり探したりする操作はある程度のコストがかかる。こういったものはaddX(),findX()等の動詞を使うようにする。 getは使わない。getName()は何も意味が無い。getは「単に取得するだけ」なのか「データベースから時間をかけて探してくる」のか分からない。単に取得するだけならname()、探すのならfindName()などとする。 スコープに比例させる 広いスコープでは意味を明確にし、衝突しないように長い名前にする。また、変に省略しないようにする。狭いスコープで
変数名・関数名の付け方についての個人的ルール - Qiita
はじめに コードを読みやすくする方法としては、コメントを適切につけること、ロジックを単純化すること、機能を分割することなど色々なものがありますが、今回は「名前の付け方」について自分が気をつけていることをまとめてみました。 当たり前すぎるものや、逆にあまり一般的でないものもあるかもしれませんが、「こんな方法もあるんだ」くらいの気持ちで読んでいただけると幸いです。 サンプルコードはPHPで書いていますが、内容は言語に依存するものではありません。 ケースはそれぞれの言語の流儀に従う 多くの場合はキャメルケースもしくはスネークケースだと思いますが、基本的に使用する言語の流儀に合わせています。どちらでも良い場合、個人的にはスネークケースの方が読みやすいと感じますが、とにかく統一だけはしましょう。 $stake_case = "これはスネークケースです。"; $camelCase = "これはキャメル
【追記あり】プログラミング初心者がTwitterで質問したら「スクールではこんなクソコード教えてんのか」とキツい指摘が飛んできた
みりせっく@雌尻ンダー extends Siri @grandcraws ツイ主が勘違いされて傷ついてるようなので、一旦謝罪とこの場でも補足しますが、初学者のコードは普通汚い。初心者はコードが綺麗か汚いかも判断基準がないから。だから教える側がここは綺麗、ここはまずい、普通はこう書く、特殊な書き方はやめよう、という教えをちゃんとやりなさいっていう話です。 2022-08-17 02:49:22 みりせっく@雌尻ンダー extends Siri @grandcraws @manaboru 正論を言うことと相手を傷付けることは無関係で、傷付けるから正論を言わないは間違いだと思いますよ。傷付かないように正論を言うべきで。で、今回はその配慮が足りず誤解させて傷付けてしまったからそこに対して衆人に見える形でリプで直接謝罪してます。それ以上の話として何を求められてますか？ 2022-08-17 12:2
Common Lisp コーディングスタイルについて
一つの文章は、一つ若しくは幾つかの單語から成り立つてゐるのでありますから、 單語の選擇のよしあしが根本であることは、申す迄もありません。そこで、 その選び方についての心得を申しませうなら、 異を樹てようとするな と云ふことに歸着するのであります。それを、もう少し詳しく、 箇條書きにして申しますと、 一 分り易い語を選ぶこと 二 成るべく昔から使ひ馴れた古語を選ぶこと 三 適當な古語が見付からない時に、新語を使ふやうにすること 四 古語も新語も見付からない時でも、造語、─ 自分で勝手に新奇な言葉を拵へることは愼しむべきこと 五 據り所のある言葉でも、耳遠い、むづかしい成語よりは、耳馴れた外來語や俗語の方を選ぶべきこと 等であります。 谷崎潤一郎 『文章讀本』 はじめに 先づ始めにお断りしておきますが、 ここで述べるコーディングスタイルを コーディング規則のやうな馬鹿げたものと同じにしないでも
上司「あのさ、コード書くときコメント一切書かないのやめない？」新入社員「え？なんでですか？」 : 暇人＼(^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 - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT英語スタイルガイド | IT英語スタイルガイド
What are the formal names of operands and results for basic operations?
https://lisphub.jp/doc/google-common-lisp-style-guide/lispguide.xml
早期リターンを禁止されるつらさ