ES modulesのexport defaultは使わないほうがよい - Islands in the byte stream
ES modulesにexport defaultってのがあるんですが、default exportのexport対象に名前が必須でないため、IDEによるコード補完と相性が悪いです。 他のところはどうしてるのかなと思って調べてみると、GoogleのTypeScript Style Guide では禁止されてました(v1.0.0, 2019/07 現在）。 https://github.com/google/gts/blob/v1.0.0/tslint.json#L40 ("no-default-export": true) TypeScript compiler coding guidelineには特に言及はないみたいですね。 https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines そもそもexport defaultは
RuboCop 0.51.0 のCHANGELOGを読む - pockestrap
RuboCop のバージョン 0.51.0 がリリースされました。 https://github.com/bbatsov/rubocop/releases/tag/v0.51.0 CHANGELOG から変更を見ていこうと思います。 破壊的変更 古い Ruby のサポート終了 https://github.com/bbatsov/rubocop/pull/4789 https://github.com/bbatsov/rubocop/pull/4787 RuboCop 0.51.0 から、古いバージョンのRubyのサポートが終了しました。 RuboCopに関係するRubyのバージョンには、2つの概念があります。 一つは、RuboCopを実行するのに使うRubyのバージョンです。これは、rubocopコマンドを実行した時に走るRubyインタプリタのバージョンになります。 もう一つは、Rubo
Javaコーディング規約追補 - torutkのブログ
最近GoogleがJavaコーディング規約を公開したとニュースで知り、目を通してみたメモを書きます。 また、以前Javaのコーディング規約について調べたメモを次のURLに書きましたが、それ以降に公開されたJavaコーディング規約を探してみました。 http://www.alles.or.jp/~torutk/oojava/codingStandard/ Googleが策定・公開したJavaコーディング規約 先月、InfoQの日本語訳の記事で、Googleが最近Javaコーディング規約を公開したことを知りました。 InfoQの記事（日本語訳）GoogleのJavaコーディング規約 （Google）http://google-styleguide.googlecode.com/svn/trunk/javaguide.html さらっと目を通してみたメモを箇条書きで列挙します。 ファイルのエンコ
Popular Coding Convention on Github
Dec 27, 2014I made this project about a year ago. At that time, I just started it for The GitHub Data Challenge II. So, it was very simple and concise implementaion for proof of concept. I've been aggregated convention data for a year. However, It is not analyze conventions of our codes deeply. I think therefore it's meaningless to keep aggregating more data. Finally, I decided to stop aggregating
キャメルケースよりスネークケースで。 - 偏見プログラマの語り！
プログラムを書くとき、たいていは何らかの命名規則に従って識別子を書くわけですが、その種類はだいたい 2 つじゃないかと思います。 ・スネークケース：スペースをアンダースコアに置き換えた表現。( chocolate_pie, candle_cake, ... ) ・キャメルケース：スペースを詰めて次の語を大文字から始める表現。( chocolatePie, CandleCake, ... ) プログラムってのは名前が 8 割とか言うひともいますけども、なんだかんだと複合語を記述する場面は死ぬほどありますし、しかも多くのプログラミング言語がスペースをトークンの区切りとしている以上、何かルールを設けないといけないんですよね。そうしないと「複合語の中にあるスペース」と「トークン区切りとしてのスペース」を区別できない。区別できないっていうかプログラム書けない。 で、どういうルールで書くかっていうと標
Sandi Metz' Rules For Developers
Back in January, Sandi Metz introduced her rules for developers in a Ruby Rogues podcast episode episode. Around the time Sandi’s rules were published, the team I am on was starting a new project. This post details the experience of that team applying Sandi’s rules to the new application. The rules There are four rules. Here are the rules: Classes can be no longer than one hundred lines of code. M
綺麗な設計を身に付けるためのSandi Metzルール
Webアプリやモバイルアプリの受託開発やコンサルティングを行うthoughtbot社のブログにて、Sandi MetzルールというRubyプログラマ向けのルールが紹介されていました。 Sandi Metz’ rules for developers このルールは、プログラマーでありPractical Object-Oriented Design in Rubyという書籍も執筆しているSandi MetzさんがRuby Roguesポッドキャストに出演した際に紹介していたものです。 そのルールは以下の通りです。 クラス内のコードが100行を超えてはならない メソッド内のコードが5行を超えてはならない 4つより多い引数をメソッドに渡すようにしてはならない（ハッシュによるオプションもパラメーターとみなす） コントローラーではただ1つのオブジェクトだけをインスタンス変数化できる ビューは1つのイン
Python の Coding Style あれこれ - Study08.net 対シンバシ殲滅用人型機動兵器
唐突ですが、Python の Coding Style について参考になりそうなものをまとめてみるテスト。 主にベースとなるPEP8の他に、僕が見聞きしたWebフレームワークのCoding Styleを列挙しています。 PEP 8 Style Guide for Python Code http://www.python.org/dev/peps/pep-0008/ (和訳) http://oldriver.org/python/pep-0008j.html PEP 8 は Pythonを書く上で大体みんなが参考にするCoding Styleです。以下にあげる Coding Style達は、PEP8 に従い、その中で独自のCoding Styleを定義しているものがほとんどです。 PEP が初耳という人は、下記エントリーが参考になるでしょう。 http://www.oreilly.co.j
Google JavaScript Style Guide
Revision 2.2 Aaron Whyte Bob Jervis Dan Pupius Eric Arvidsson Fritz Schneider Robby Walker This style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which you see here on your left. Click it now. You should see "Hooray" appear below. Hooray! Now you know you can expand points to get more details. Alternatively, there's a "toggle all" at
Windows - Soft Famous
You can use Excel,Word, Access, Outlook, PowerPoint and others
holidays-l開発ブログ - Perl::Criticでコーディングスタイルを統一
Perl::Critic - Critique Perl source code for best-practices. - metacpan.orgをコーディングスタイルを統一するために使っています。 （実際には字面としてのコーディングスタイル（コードレイアウト？）はPerl::Tidy - metacpan.orgが担当しているわけですけども、ここでは「use strictを入れる」「PODを付ける」なども含めてコーディングスタイルと言ってます） コーディングスタイルに唯一絶対的に正しいなんてものはないわけで（だから宗教論争にもなるわけで）、機械的に統一することで揉め事はなくなります。 しかしその時に.perlcriticrcなんかを使ってコーディングスタイルをデフォルトから変更してしまうと元も子もありません。 .perlcriticrcに何を設定するかで揉めますし、例えその時に揉めな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - bevacqua/js: :art: A JavaScript Quality Guide
styleguide/ruby.ja.md at master · cookpad/styleguide
Preview the new Google Groups - Google Groups
Primer
https://oldriver.org/python/pep-0008j.html
Perl::Critic