morimorihogeです。ちょっと色々忙しくて死んでますが、深夜の勢いで書いてみます。 ことの起こり Twitterにてこんな発言を見かけました この2017年の記事だと、RoRのテーブルのdatetime型にはatをdate型にはonを付けようと書いてあるけど、APIでカラムのデータを返す場合、フロント側としてはdateというサフィックスが付いていた方がやりやすいという意見があって、この辺のベストな感じが気になったhttps://t.co/8MMMHlFvGx — yotuba@Railsエンジニア (@yotuba_eng) July 1, 2021 元記事（翻訳）はこちら Rails: 日付や時刻のカラム名を命名規則に合わせよう（翻訳） 本件について、Twitterではreplyしてみたのですが、文字数の都合で詳細に書きづらいということもあり、一度自分の意見をまとめてみようという
はじめに 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走らせろっていうのが今風なのかもしれませんが、キニシナイキ
むかし同じチームだったひとに、JavaScript のセミコロンを省略する派のひとがいて、他の人と「もう日本語かくとき句読点も省略すればいいじゃないの」とか、散々いっていた。でも実は GitHub も省略派らしい。 GitHub の JavaScript Styleguide は、まず最初の「新しい JS は CoffeScript で書け」にびっくりするのだけど、さらに読み進めていくと、既存の JavaScript について「なるだけセミコロンは使うな」とある。 Do your best to never use a semicolon. This means avoiding them at line breaks and avoiding multi-statement lines. For more info, read Mislav's blog post. 出来る限りセミコロン
目次 自動セミコロン挿入(Automatic Semilocon Insertion) Restricted Production ASIの害 セミコロンにまつわる論争 で、どっちがいいの? JavaScriptには、 自動セミコロン挿入 という機能があり、行末でセミコロンを省略しても、多くの場合文法的に問題ありません。 しかしながら、 JavaScript: The Good Parts などで指摘されているように、自動セミコロン挿入は有害な機能であるため、JavaScriptのステートメント末尾には必ずセミコロンを付与するというのがフロントエンドエンジニアの共通認識だと思っていました。1 ところが、 Bootstrap に含まれるJavaScriptコードを見てみると、基本的にセミコロンが使用されていません。 調べてみると、どうも世の中にはJavaScriptのステートメント末尾にセミ
node.jsアプリケーションのスタイルを支配する公的な文章はありません。このガイドはあなたが美しく、一貫したソフトウェアを作れるようになる教訓を与えようとする私の独断の試みです。 このガイドはあなたがnode.jsのみを対象にしていると仮定しています。もしあなたのコードをブラウザなど他の環境でも動かす必要があるのなら、いくつかのガイドは無視してください。 様々なパッケージだけではなくnode.jsもまた、それぞれ自体のスタイルを持っています。なので何かのパッケージの開発に貢献することに興味があるのならば、それぞれのルールに従ってコーディングを楽しんでください。 Tab vs Spaces まずはこの宗教的な問題の話をしましょう。私達の慈悲深い独裁者様はnodeのコアに2スペースのインデントを選択なさったので、彼の秩序に従うのが賢明でしょう。 セミコロン あなたからセミコロンを奪おうとする
gistfile1.md if式 / if文 の条件節で、左辺に定数を書くべき言語はあるか？ @ajiyoshi.gist twitterからながれてきたこの話題。昔のCコンパイラは、if文の条件節で代入を書いても文句を言わなかったので、このようなコードに何の警告も出なかった。 #include<stdio.h> int main() { int x = 0; /* おそらく意図と違う。 x == 1 と書くべきであった これでは常に実行されてしまう */ if ( x = 1 ) { puts("残念"); } } 「これをこのように書けば、コンパイルエラーになり、ある種の誤りをコンパイラに見つけさせることができる」というのが、「老害」とされる人の主張である。 /* これはコンパイルエラーになる */ if ( 1 = x ) { puts("残念"); } もし使っている環境が「コンパ
はじめに Swiftのコードは多様な記述の仕方ができるので柔軟でかつ表現力もありますが、チームで開発を行うとどうしても記述の仕方が統一できず可読性も上がりません。弊社（Wantedly）でSwiftのアプリを開発した経験をもとにアプリ開発におけるコーディングスタイルガイドを作成しました。このコーディング規約がベストプラクティスだというわけではなく、Swiftもまだまだ手探りなところもあるので、参考情報としてご参照ください。また、規約の範疇ではないですがエラーになりやすい記述も合わせてフォローしています。 バージョン v0.3 改版履歴は文末を参照ください。 コーディング規約の必要性について Swiftはプログラマがリスクを取ることによってより簡素に端的に記述ができたり、型推論が強力なので型の明記を省略して記述ができます。チームでSwift開発を行う場合は、詳細に記述するのか、省略して記述す
CSSはどちらかと言えばやさしく、雑にコードを書いてもなんとかなってしまう言語です。 しかし、雑にコードを書いてしまうと、昨日書いたこのコードなんだっけ？ とか、新しくスタイルを増やすと別のスタイルがおかしくなってしまうことはありませんか？ 大規模なプロジェクト、長期に渡るプロジェクト、複数のメンバーが関わるプロジェクト、そして明日の自分も一年後の自分も使える、メンテナンス性に優れた一覧性のある美しいCSSを書くのに役立つガイドラインを紹介します。 CSS Guidelines 2 CSS WizardryのHigh-level guidelinesの最新版（2014年8月リリース）。 大規模で長期に渡るプロジェクト向けのメンテナンス性に重点をおいたスタイルシートのガイドラインです。スキルの異なる制作者、新規で加わる制作者などでも、統一されたコードでの制作が可能になるのを目的としています。
HTMLシンタックス インデントには半角スペース2個分のソフトタブを使用すること。これが全ての環境で全く同じように見せる唯一の方法。 ネストされた要素はかならず1段階だけインデント(半角スペース2個)すること。 いつもダブルクォートを使うこと。属性値に対してシングルクォートを使わないこと。 閉じタグの無い要素に対して、末尾のスラッシュは省く事。HTML5仕様に省略して良いと書いてある。 省略できる閉じタグを省略しないこと。(例えば</li>とか</body>)。 <!DOCTYPE html> <html> <head> <title>Page title</title> </head> <body> <img src="images/company-logo.png" alt="Company"> <h1 class="hello-world">Hello, world!</h1> </
■□■リダイレクトしています。■□■ しばらくしても移動しない場合はこちらをクリックしてください。
知っている人は知っている「Airbnb」の JavaScript スタイルガイドを翻訳しました。 急に上司から「Javascript のスタイルガイドないの？」って言われて困ったら思い出してください。 このエントリでお伝えしたいこと。 ネタがなくて困ってたら使ってください。 困ってなくても、イイなと思ったら使ってください。 良かったら Airbnb も使ってください。 Airbnb とは Airbnb とはアメリカのサンフランシスコにある、個性的な宿を扱うスタートアップ企業です。詳細は下の記事を読んでください。 旅行のソーシャル化は「現実世界の Facebook」、AirBnB CEO に聞いた。 Airbnb（JP） 去年の秋くらいに、サイバーエージェントさん主催の Frontrend で名前を聞いた（ような気がする・・・）辺りからチェックしていました。 このたび勉強のついでに翻訳してみ
JavaScriptの書き方はJavaScript自体がある程度自由なためいろいろな書き方ができますが、一貫性を持って書いた方がバグなども発生しにくくなるため、コーディングルールを定めておくのはよいことだと思います(特に複数人の開発の場合) 有名な企業やライブラリはコーディングルールも公開している事が多いので適当にまとめてみました JavaScript style guide – MDC Docs Mozilla/Firefox向けのものなので、一部ECMAScriptの範囲を超えたものも含まれています。 多くの人が見ていると思うので、見たことない人は一度読んでみるといいです。 jscsにこのコーディングルールをチェックするプリセットが用意されています。 Google JavaScript Style Guide Google JavaScript Style Guide 和訳 — Goo
「CSS の ID 名や CLASS 名の単語の連結にハイフンを使うべき、キャメルケースとかアンダーバーとかダメ」的な主張を去年ぐらいにどこかで読んだ記憶があるのですが(うろおぼえ)、 /* たしか… これがオススメのスタイルで */ .hoge-huga-piyo {...} /* これとか… */ .hoge_huga_piyo {...} /* これはイケてない(らしい) */ .hogeHugaPiyo {...} 個人的には「ちょっとそれ CSS に寄り過ぎてて、視野せまくないかー」という考えをもっていたので、つらつらと書いてみます。 E:first-child や E[key|="value"] などのハイフンを前提とした構文に関してはもちろんありですよ。ここで取り上げてるのは、属性セレクタや擬似クラスセレクタについてではなく、IDセレクタ と CLASSセレクタ についてです
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く