読みやすいコードを書くために - Qiita
この記事は、社内向けに書いた資料を公開の許可を得て加筆修正したものです。 記事中の具体例やサンプルコードはJavaScript/TypeScriptで書かれていますが、内容自体は言語にかかわらず使えます。 同僚の @shisama にも手伝っていただきました。 はじめに 命名について 条件式について 関数について 変数・定数について コメントについて 2020/11/02 ついに完結！ はじめに 読みやすいコードは、コメントがなくても文章を読むように理解できます。 逆に、読みにくいコードはコメントがあってもさっぱり意味がわかりません。 文章を読むように理解できるコードを書くために普段気をつけていることや、コードレビューの際に重点的に見ているところをまとめました。 普段から読みやすいコードを心がけている方にとっては何も目新しい物はなく、当たり前に意識しているであろうことばかりです。 特にプロ
悩んでるポイントはみんな同じ！？「Rubyistのためのテストコード相談会」の質疑応答まとめ - give IT a try
はじめに 先週の土曜日（2015年5月16日）に西脇.rb＆神戸.rbで「Rubyistのためのテストコード相談会 ～テストの書き方に悩んでいませんか？～」という勉強会を開催しました。 この勉強会は「テストコードに関する疑問や悩みをみんなで持ち寄り、みんなで解決すること」を目的にした勉強会です。 勉強会中はいろいろと興味深い議論が出たので、今回のエントリではその内容を簡単にまとめてみます。 勉強会で挙がった質疑応答 よく使うフレームワークは？ RSpecが大多数、Minitestが若干名。 gemを開発するときはMinitest、RailsはRSpec、というように開発内容によってフレームワークを使い分ける、という人もいた。 Minitestってどうなの？ 導入が簡単。assertメソッドだけ知っていればなんとかなる。 Railsにも対応している。Capybaraも使える。 RSpecのs
rspecのテストでカバレッジが計測できるgem、SimpleCovを導入する - まえとうしろ
テストを書くならカバレッジ計測と行単位で通った・通ってないの確認ができたらいいな、と思っていたら @tmtms さんより「SimpleCov」を教えていただきました。 GitHub - colszowka/simplecov: Code coverage for Ruby 1.9+ with a powerful configuration library and automatic merging of coverage across test suites 導入手順 Gemfileに「simplecov」を追加 group :development, :test do # Call 'byebug' anywhere in the code to stop execution and get a debugger console gem 'byebug' gem 'rspec-rail
Rails/Ruby - テストカバレッジを調べる simplecov - そういうことだったんですね
自分の書いたテストが、全体コードの何割を占めているかを示す指標をテストカバレッジといいます。数値化されるのでテストの妥当性の検証に役立ちます。 今回はそのカバレッジを調べるRubyライブラリ simplecov を調べてみました。 インストール gemパッケージですので次の通りインストールします。 $ gem install simplecov rails で使う場合は、Gemfile に次のように追加してbundle します。 gem 'simplecov', :require=>false, :group=>true テストで計測の時に require するのでここでは読み込まないようします 使い方 ヘルパメソッドに追加(初回のみ) test/test_helper.rb (RSpecの場合は spec/spec_helper)の一番最初に次の行を追加しまう require 'simp
rails + RSpec + CircleCI + codecov でテストカバレッジを可視化してみた - Qiita
環境 ruby 2.2.6 rails 4.2.0 rspec-rails 3.5.2 simplecov 0.13.0 codecov 0.1.9 事前準備 CircleCIの登録 codecovの登録→リポジトリ登録 特につまづくとこはないと思う。 CircleCI導入はいろんな人が書いてるのでそちらにお任せして割愛。 「カバレッジ出力＋codecovへのアップロード」するための修正 group :test do gem 'simplecov', :require => false gem 'codecov', :require => false end require 'simplecov' # save to CircleCI's artifacts directory if we're on CircleCI if ENV['CIRCLE_ARTIFACTS'] dir = Fi
SimpleCovのカバレッジ(網羅率) - Qiita
SimpleCov gemのカバレッジが上記のうち、どれにあたるかというと、厳密にはどれにも該当していないというのが、正しいと思います。 例として、次のコードのカバレッジを計測してみます。 このコードはgithubにもおいてあるので、結果のhtmlなどは、そちらを参考にしてください。 require "simplecov_sample/version" module SimplecovSample class Sample def initialize(name = "") @name = name end [:test1, :test2, :test3].each do |method_name| class_eval <<-RUBY_EVAL, __FILE__, __LINE__ + 1 def #{method_name}() # def test1() "#{method_nam
Rubocopを使ってコーディングルールへの準拠チェックを自動化 - Qiita
はじめに チーム内でコーディング規約を作っても，ついクセで違う書き方をしたり気にしない人がいたりして形骸化しがちだと思います．またレビュー時に細かい違いを指摘するのも面倒です．そんなときはrubocopを入れましょう インストール これでrubocopコマンドがインストールされ，rubocop foo.rbとするとチェックできます． コマンドラインからいちいち実行したくないので，各エディタのプラグインをインストール．すると，以下のようにコーディングルールに合わない箇所を指摘してくれます． ここでは「bodyが1行のときは後置ifか，&&や||を使え」と言われています． 設定 rubocopが準拠するコーディング規約は同じ開発者が提案しているものですが，.rubocop.ymlファイルを編集することで自分達に合った形に変更することができます． うちではチームで話し合い，10箇所ぐらい変更しま
【Java】パッケージ名の付け方＆作成方法
一覧として出してみましたが、この中で予約語として該当するものはクラスとして作成することが出来ません。パッケージで宣言してもこれは同じ事です。 試しに「byte.java」を作りコンパイルしてみましたが、「identifierがありません」と表示されさらにmainメソッドの定義も含めて全てがエラーとなってしまいます。どうしても予約語を使いたいという場合は先頭の文字を大文字にするなどします。 また同一ファイル名を複数作成するには、パッケージに含める必要があります。 パッケージとして宣言すれば・・ 「パッケージ名.クラスファイル名」 「パッケージ名・パッケージ名2.クラスファイル名」 などといった名前空間が与えられるので名前同士が衝突することなく利用することができるのです。 デフォルトパッケージ Javaのクラスファイル (.class) はその性質上、必ずパッケージ内に納める必要があります。
Javaの道：パッケージ（２．パッケージの作成）
パッケージの作成は以下の枠内のフォーマットにより構成されます。パッケージに含めたいクラス・インタフェースが定義されているソースファイルの先頭でpackage文を宣言します。パッケージのスコープはソースファイル全体になります。そのため、ソースファイルにクラス・インタフェースが複数書かれている場合はそれらすべてがパッケージに含まれます。 例１ //クラスExPackageをパッケージPackageAに含めます。 package PackageA; public class ExPackage { public void showName() { System.out.println("PackageAに属します。"); } } ソースファイル作成時、packageを宣言しない場合、そのソースファイルで宣言されたクラス・インタフェースはデフォルトパッケージに含まれます。デフォルトパッケージとは名
Javaのコーディングルール
私自身、Javaで仕事をするようになってから3ヶ月ちょっとがたちました。 もともとPHPで仕事はしていましたが、我流でやっていたこともあり、コーディングのルールとかがいい加減だったんですよね・・ ボス(社長)はガチのJavaエンジニアなのでその点を見てもらえるのがすごくありがたいです。 またオフィスにもEffective Javaなど著名な雑誌があります。 ここではJavaの基本的なルールについて振り返ってみたいと思います。 命名系 クラス名、メソッド名、変数名の基礎 基本全てキャメルケース。 こういうとこも意外といい加減でした。速く直したいですね・・ またクラス名は役割をあらわす名前にすることです。 社長には職業といわれました。生徒情報だったらStudent,顧客情報だったらCustomerみたいなつけ方ですね。 抽象クラスの名称はabstract こうしないと探すときに大変です。 似た
第15話 コーディング規約は必要か？：ソフトウェア開発に幸せな未来はあるのか：エンジニアライフ
少しご無沙汰しています。 今回からまた新しいシリーズです。ソフトウェアに関係する事柄のあれこれについて書いてみたいと思います。3回程度の予定です。 今回はコーディング規約についてです。コーディング規約がどんなものかはプログラマやSEなどを経験していれば知らない人はまずいないと思います。会社としてきちんとドキュメントになっているところもあれば、部や課、プロジェクト単位で適用している所もあるようです。 ただ、わたしの経験では、なぜか、なかったところの方が多かった気がします（気がするというのは実際はあったが見たことがなかっただけかもしれないので。もっともそれじゃないのと同じですが）。 現在のわたしの状況に関しては、「なかった」ので、わたしが作ってメンバーに周知しています。わたしが作るコーディング規約に関しては基本的にA4用紙に1枚程度の量で、そんなにきつく縛っていません（たぶん）昔ほどコーディン
ベストなコーディング規約の作り方
ベストなコーディング規約の作り方 投稿日 2014/12/31 更新 2015/02/23 [Home] このサイトは Amazon Web Service (クラウド) で構築しています。 AWS に関する記事 コーディング規約とは 「コーディング規約」は多数のプログラマが参加するプロジェクトにおいて、プログラミング品質を均等にするために定める文書です。 内容は変数などの命名規則、禁止事項 (例えば goto 文はダメとか)、コメントの付け方とか、いろいろプロジェクトの特性やその会社の文化などで変わります。 コーディング規約のメリット・デメリット コーディング規約のメリットはプログラマの個性を殺して均質なプログラムを作ること、過去の知識や経験から得られたバグの発生源となりやすいコーディングの防止、インデントやコメントの基準を決めて見やすさ保守性の高さを求める・・・等々です。 一
Javaコーディング規約 | Future Enterprise Coding Standards
※ Sun Microsystems の規約は Java 草創期から一応の標準という位置づけだったが、オブジェクト指向、及び、その開発環境の普及・発展によって、設計やコーディングにおいて、直接的に有用な知識や豊富な指針を含むような優れた規約や、ツールなどによる機械的な準拠チェックと連携する規約が普及してきている。 # 規約の重要性 標準としての規約を定義し、遵守することの重要性を以下に示す。 ソフトウェアメンテナンスにおける、可読性・保守性・拡張性の向上 問題を起こしやすい実装を未然に回避することによる、品質・生産性の向上 標準規約を通して得られる一般的な実装知識やノウハウ（＝学習効果） # コーディングの心得 長いプログラムを記述すること（ステップ数）によって生産性が評価されたのは、過去の時代の出来事である。現在は、クラスやメソッドの役割が明確で、ロジックが読みやすく、保守性に優れたプロ
Google Java Style Guide (非公式和訳)
Tip: ただ何かのプログラムが非ASCII文字を正しく処理しないという危惧だけでコードを読みにくくしてはならない。もしそのような事が起こる場合はそのプログラムが 壊れている のであってそちらが 修正 されるべきである。 3 ソースファイル構造 ソースファイルの内容は 以下の順序 であること。 1. ライセンスあるいはコピーライトの情報（もしあるならば） 2. package文 3. import文 4. ただ1個のトップレベルクラス。 ソースに書かれている内容それぞれの分離には ただ1行の空行 を使うこと。 3.1 ライセンスあるいはコピーライトの情報（もしあるならば） もしファイルにライセンスあるいはコピーライトの情報があるならばここに入る。 3.2 パッケージ文 パッケージ文は 改行してはならない。 文字数制限（4.4節 文字数制限は100文字 ）はパッケージ文には適用されない。 3
システム屋さんがうれしいJava8対応のコーディング規約を公開します！！ | フューチャー技術ブログ
はじめにこんにちは。星です。 弊社では、お客様の基幹システム構築をする際、Java言語を採用することが多いのですが、2015年4月末にJava7のサポート切れになったことを受けて、昨年よりJava8で開発をしています。 弊社でもそれなりの規模の案件になると、社員やパートナーの皆様を合わせて、数百人が同時に開発することも珍しくありませんので、私の所属する技術部隊でコーディング規約をはじめとして、開発をするにあたってのガイドラインの整備やEclipse等の開発環境の整備などのタスクを実施して、標準化とクオリティの担保を推進しています。 さて、Java8においては、Java7において実装見送りとなったStream APIやラムダ式といった大きな機能追加がありました。とはいえ、これらの機能を使ったとして、性能的に大丈夫なのかとか、どういったコーディングスタイルが良いのか？など、エンタープライズ領域
最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
作り直し - hitode909の日記
ソフトウェアを作ってて、作り直したり、書き直したりするべきかどうかという話をすることがある。 大きな規模だと、ソフトウェアを作り直す、というところから、小さな規模だと、込み入った機能を書き直す、くらいまであるけど、作り直すとうまくいくのは、次の二つのうちどちらかではないか。 最初に作ったときより世の中の技術が発展したとき 昔のコンピュータでは収まらなかったとか、昔は良いライブラリがなかったけど、今はある、というとき。 単に今ありふれた技術で作り直すと、よいものができそう。 最初に作ったときよりはコンピュータのスペックが上がったので、そのつもりで、並列度倍に上げても止まらないし、より速く動かせる、とか。 昔はバッチで計算しないといけなかったけど、今ならリアルタイムに返せる、とか。 昔は依存管理のよいライブラリがなかったけど、今ならこれ入れたら簡単、とか。 最初に作ったときより人間の技術が発展
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SimpleCovを利用してコードのカバレッジを計測する。 - Qiita
RSpecのカバレッジ計測「SimpleCov」