経年劣化に耐える ReactComponent の書き方 - Qiita
「経年劣化に耐えるコード」というのは、だれもが目指すものでしょう。「そもそもフロントエンドのコードは、今ある技術で最良のものを書き捨てるべき」という意見も理解できますが「備えあれば憂いなし」ということもありますので、ここにメモを残します。あくまで、私なりのベストプラクティスですのでご了承ください。 5層に別れた SFC 私はレイヤーによる技術の分離で、ReactComponent の経年劣化に備えています。ここでいうSFCとは「Stateless Functional Component」の略称ではありません。Vue.js の文脈にある「Single File Component」を指します。 // (1) import層 import React from 'react' import styled from 'styled-components' // (2) Types層 type
「美しい」にモヤったら「認知負荷が小さい」と言いかえよう - Qiita
プログラミング業界では定期的に「美しいコード」が話題になり、そのたびに炎上が発生します: コードの美しさは実務には関係ない 美しくても動かなければ意味がない 「美しさ」は主観的で、プログラマーの自己満足に過ぎない 汚くたって俺は読める。読めないお前が悪い などなど・・・ 私もコードは美しくあれかしとは思いつつも、 「確かに『美しい』って曖昧だよな」とか、 「どうして = の位置がそろっているのを『美しい』というのだろう？『整然としている』なら分かるけど」とか、 「『可読性が高い』でもいいけど、今一つ『美しい』との違いが判らん」 「そもそも、どうして美しいコードの方が読みやすいと言えるんだ？」 と、割り切れなく思っていました。 ところで、最近の心理学・脳科学ではこんな説があるようです（本当かどうかは知らないよ）： 中野：（中略）美人の顔って対称性が高いって言われますよね。あれは別に体が健康だ
プログラマが持つべき心構え (The Zen of Python) - Qiita
はじめに この記事はstackoverflowのThe Zen of Pythonに関する質問と解答(CC BY-SA3.0 ライセンス)を訳したものです。 The Zen of Pythonの日本語訳は"我々は「Python」に何を求めているのか?"を参考にしました。 The Zen of Pythonとは The Zen of Pythonとは、Pythonプログラマが持つべき心構えを簡潔にまとめたものです。 Pythonを書かないプログラマにとっても、これは大いに役に立つはずです。 ちなみに、"Zen"は日本語の「禅」です。 最初から全文を読もうとする必要はありません。この記事にざっと目を通してみて、気になった部分を読むことをおすすめします。 全文はPythonインタプリタ上で The Zen of Python, by Tim Peters Beautiful is better
perltidy - Perlソースコード整形ツール - Qiita
About Perlのソースコードを統一したルールで整形してくれる。 チームでコーディングするとき、特に有用。 CPAN Perltidy How to install. $ cpanm Perl::Tidy which perltidyでInstall成功を確認 Setting $HOME/.perltidyrcに以下のように書く(Perl best practicesより) -l=78 # Max line width is 78 cols -i=4 # Indent level is 4 cols -ci=4 # Continuation indent is 4 cols #-st # Output to STDOUT -se # Errors to STDERR -vt=2 # Maximal vertical tightness -cti=0 # No extra indenta
Elixirでは行の最大長をいくつにするべきか - Qiita
(2018-08-02 19:55:00 JST 追記)最近のcredoはデフォルトの行の長さを120としているようだ https://github.com/rrrene/credo/commit/06c6a07d2e68b513660382f51e68fcdb81355b8c もう120でいいな…… プログラマにとっての読みやすさを維持するため，またプログラムの構造の歪さが行の長さとして現れることがあるため，Linterで行の長さを制限することがよくある． ElixirでメジャーなLinterであるcredoのデフォルトでは行の最大長を80と定めている．80というのはデファクトスタンダードであったVT100というターミナルが表示できる行の最大長が80だったことに由来するようだ．これは妥当な設定である．しかし現代のプログラミングにおいて80は少し短すぎることもある．例えばURLが80文字以
GoogleのWebAPI設計とWebAPI設計のベストプラクティスを比較してみる
RESTful な URL にしよう 元記事 GET /tickets - チケットのリストを取得する GET /tickets/12 - 指定したチケットの情報を取得する POST /tickets - 新しいチケットを作成する PUT /tickets/12 - チケット #12 を更新する PATCH /tickets/12 - チケット #12 を部分的に更新する DELETE /tickets/12 - チケット #12 を削除する Google GET /events - 予定のリストを取得する GET /events/12 - 指定した予定の情報を取得する POST /events - 新しい予定を作成する PUT /events/12 - 予定 #12 を更新する PATCH /events/12 - 予定 #12 を部分的に更新する DELETE /events/12 -
CSSfmtをつくった話、もしくは本質的な問題解決とは - Qiita
CSSfmtという、CSSとSCSSのコードを自動整形するツールをつくった。 使い方はREADMEを見たらわかると思う。Atom, Sublime Text, Vim, Emacs用のプラグインがあるので、エディタで使うのがおすすめ。コマンドラインからも使える。 atom-cssfmt sublime-cssfmt vim-cssfmt cssfmt.el AtomでCSSfmtが動いている様子： なぜつくったのか チーム開発において、コードのフォーマットが統一されていないことがある。 フォーマットの小さな違いはわざわざ指摘するのもめんどうだし、指摘されても嫌な気分になる。なので、コードをあるルールに従って自動で整形するツールの導入は必須だと思う。 CSSコードの整形ツールはいくつかある。CSS BeautifyやCSScomb、stylelintでも可能だ。 これらのツールとCSSfmt
Angular2 DOC GUIDEを翻訳する[STYLE GUIDE] - Qiita
トピック Angular2 CORE DOCUMENTATIONのGUIDEの翻訳です。 DOCUMENTATION OVERVIEW - ドキュメント概要 - ARCHITECTURE OVERVIEW - 構文概要 - DISPLAYING DATA - データ表示 - USER INPUT - ユーザー入力 - FORMS - フォーム - DEPENDENCY INJECTION - 依存性注入 - STYLE GUIDE - スタイルガイド - 注意1）ここに掲載されていない項目は、Angular2 CORE DOCUMENTATIONのGUIDEを直接参照してください。 注意2）2016年12月12日時点の翻訳です。翻訳者はTOEICで700点くらいの英語力なので、英訳が間違っている可能性があります。しかもかなり意訳している箇所もあります。もし意訳を通り越して、誤訳になっている
![Angular2 DOC GUIDEを翻訳する[STYLE GUIDE] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/c46c7f3618cb13d1e2a694bdef2ca65c5a6cea8b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9QW5ndWxhcjIlMjBET0MlMjBHVUlERSVFMyU4MiU5MiVFNyVCRiVCQiVFOCVBOCVCMyVFMyU4MSU5OSVFMyU4MiU4QiU1QlNUWUxFJTIwR1VJREUlNUQmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTNkYjA5ZmRmNjJhZGQ2M2NkMTU2MzFiNjVmOTRlMjBk%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwWWFtYW1vdG8wNTI1JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00Y2I5NTAwMWU5YzRiYjI3MDk3NjUyNWI5YWQ2YTEzNA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D437c3bb08564c5bfde6339fac320d15b)
Googleの肩に乗ってShellコーディングしちゃおう - Qiita
はじめに GoogleさんがShellスタイルガイドを共有していたので、いくつか気になった点をピックアップしました。 自分のShellスタイルはかなり我流なので、自省の意味も込めてコメントも併記します。 Googleスタイルガイドの元ネタ （Python/C++/Java/Rとかだけでなくdocumentガイドなど色々あります） https://github.com/google/styleguide Shellスタイルガイド （今回はこちら） http://google.github.io/styleguide/shell.xml 本当は人間がチェックするのではなくcpplintのためXML定義なのかもですが、気にしない気にしない。 （見たところcpplintはc++だけだと思ってます） commitフックでshell系のlint走らせろっていうのが今風なのかもしれませんが、キニシナイキ
2018年のCommon Lispのコーディングスタイルはこれだ! - Qiita
Tutorial on Good Lisp Programming Style(これがおすすめだ!) http://norvig.com/luv-slides.ps (Lisp Users and Venders Conference 1993でのPeter Norvig氏の発表) 日本語訳 https://sites.google.com/site/okshirai/home/tutorial-on-good-lisp-programming-style-ja.txt こちらも有用で有名なガイドです。こっちの方がgoogleのものより知られているかも。 一度は目を通しておきましょう。 Google Common Lisp スタイルガイド (これもおすすめだ!) Google Common Lisp スタイルガイド 日本語訳 というかこれとNorvig&Pitman氏のもの位しかないです。
PhanでPHPのコーディング規約を自動チェックしよう - Qiita
再演: 「PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計」 + αという勉強会で、「assertぐらいでエバルんじゃねえ！」というふざけたタイトルで発表してきました。 資料はこちら。 PHP7では内部的にASTを作るようになりまして、それをPHP側から使えるようにするphp-astというC拡張があります。これを使って型推論つきの静的解析をするツールがPhanです。 Phanでは未定義変数や型に関する間違いを警告してくれるのですが、そういう明らかなバグの他にも自前のプラグインを作ってエラーをチェックすることができます。 スライドの趣旨としては、assertの話から入るものの、assertのことが主題ではなく、Phanを使ってコードの自動チェックを充実させようという内容です。 Phanプラグインの作り方 Phanプラグインの書き方は一応ドキュメントがあるのですが
[翻訳] The Elixir Style Guide - Qiita
プログラマの仕事はコードを書くことよりも、むしろ問題解決の方法について別のプログラマに伝えることです。これが技術者としての成熟の最終段階です。 — What a Programmer Does, 1967 Table of Contents コードレイアウト シンタックス 命名 コメント モジュール 正規表現 例外 コードレイアウト インデントはスペース2つ。ハードタブは使わないこと。[link] 一行につき式は一つ。命令や式を区切るのに;を使ってはいけない。[link] - バイナリオペレータの前後、カンマ、コロン、セミコロンの後にはスペースを入れてください。 []の{}の間にはスペースを入れないでください。 Elixirの処理系にとって空白にほとんど意味はありませんが、コードを読みやすくするためには重要です。 [link] sum = 1 + 2 [first | rest] = 't
![[翻訳] The Elixir Style Guide - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/c178b77d2b01e129229a4eef677fc60cda502b7a/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-f625e957b80c4bd8dd47b724be996090.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwVGhlJTIwRWxpeGlyJTIwU3R5bGUlMjBHdWlkZSVFMyU4MCU4MCZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDbWlkZGxlJnM9Zjc4MWQwNzlmZjNhYzUyNDg2MWY1NmU1MDRjNzZhMWM%26mark-x%3D142%26mark-y%3D151%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwa2VuaWNoaXJvdyZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MTVlMWU3YjRiYTI3MGE3Mzk0ZTNhYmYzYWNmYjQ0MzE%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D8361a9490fa0483e1b1a8311a597262c)
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
リーダブルコードを読んだので、殴り書き - Qiita
俺の名はケンヤ。難事件をいくつも迷宮入りさせたニート。しかし ある時謎の組織に入社し薬を飲まされ身体が縮んで Braian になっちゃった。 「面白いコードと読みやすいコードは違う」 「コードは理解しやすくなければいけない」 「コードは他人が最短で理解できるコードでなければならない」 「コードは短い方がいいが、"理解するまでにかかる時間"を短くするほうが大切」 名前に情報を詰め込む 明確な単語を選ぶ 例えばGetではなく、状況に応じてFetchやDownloadなどを使う. tmpやretvarなどの汎用的な名前をさける ただし、明確な理由があれば話は別。 具体的な名前を使って、物事を詳細に説明する ServerCanStart()よりもCanListenOnPort()のほうが明確だ。 変数名に大切な情報を追加する ミリ秒を表す変数名には、後ろにmsをつける。これからエスケープが必要な変
ruby-style-guideの翻訳をだいぶなおした - Qiita
まあ細かいことは向こうに書いたので、もうちょっと一般的に言えることを: 訳者は、たとえ英語力がミジンコレベルだったとしても、日本語は読めるはずだからこそ翻訳をやっているわけで、したがって、訳文が日本語として成立しているかは判定可能のはず。訳があっているかどうか以前の問題として、拙文を上梓して読者のお目汚しを願わんとする以上は、 最低でも日本語 を書くというのは矜恃とかそういう問題だと思う。翻訳したらまず読み返すべし。 英単語がよく訳せないなら、度胸一発ハッタリかまして適当訳するくらいなら ルー語 にしてくれたほうがむしろありがたいので、無理に訳そうとするな。 英語にない文型を独自に編み出さないこと。どんなに複雑なように見える文でもかならず英文は5文型のどれかでできているので、よくわかんないからといって 第六第七の文型 を編み出すべからず。 まず動詞を発見せよ。その文の動詞はどれか。動詞が見
Angular.jsのディレクトリ構成のベストプラクティスを探る - Qiita
Angular.jsのアドベントカレンダー6日目です。(遅れてすみません汗) 今日は泥臭い?感じの話になります。 この記事は言及している人達の記事やスタイルガイドのまとめという感じなのですが、これからディレクトリ構成を考える初学者の方や，ディレクトリ構成に悩んでるかたの参考になれば幸いです Angular.jsのディレクトリ構成パターン紹介と、利用して感じた考察などのことを書きます。 はじめに LIG主催のAngular.js勉強会 #ng-curry にて、登壇したときの発表内容をまとめようと思っていたのですが、今回のAdvent Calenderを機会に勉強会で話した内容をまとめてみます。 元スライドはこちら -> http://slides.com/sugawararyousuke/ng-curry-2 まとめ疲れたので スライドの前半部分だけの話をまとめます。 このテーマで話そうと
初心者のうちに知っておきたかったScalaのこと - Qiita
自分は今年に業務でScalaを使い始めて本格的にはじめたのですが、入門した時に早めに知っておきたかったScalaのTipsを紹介しようと思います。 これらを早く知っていれば今後の負債を減らせるかもしれませんよ。 コード規約系 Scalaに限らずソースコードは書いた人の癖が非常に出やすいのでif(){}の{}位置など比較的どうでもいいことでチーム開発では揉めてしまいことがあります。 Scalariform コーディング規約を設定ファイルに書き込むとコンパイルするたびにオートフォーマットしてくれます。 導入もsbtのライブラリを追加するだけで非常に簡単なのでおすすめです 依存性 scalaのobjectは便利だけど、テストが大変です… 弊社のアプリケーションはslickのDAOが全部objectで構成されていてビジネスロジックばりばり書いてあったのでモックを差し替えることができずにテストの際に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ケバブケース（kebab-case）について調べた - Qiita
SMACSSを参考にしたCSSコーディング規約 - Qiita