neue cc - .NET Core時代のT4によるC#のテキストテンプレート術
C# Advent Calendar 2019用の記事となります。C# Advent Calendar 2019はその2もあって、そちらも埋まってるので大変めでたい。 さて、今回のテーマはT4で、この場合にやりたいのはソースコードジェネレートです。つまるところC#でC#を作る、ということをやりたい！そのためのツールがテンプレートエンジンです。.NETにおいてメジャーなテンプレートエンジンといえばRazorなわけですが、アレはASP.NET MVCのHTML用のViewのためのテンプレートエンジンなため、文法が全くソースコード生成に向いていません、完全にHTML特化なのです。また、利用のためのパイプラインもソースコード生成に全く向いていない（無理やりなんとか使おうとするRazorEngineといったプロジェクトもありますが……)ので、やめておいたほうが無難です。 では何を使えばいいのか、の答
コードの可読性についてのプレゼンテーション紹介 vol. 1: "導入と原則" 編
はじめに こんにちは。コミュニケーションアプリ「LINE」の Android クライアントチームの石川です。 先日、コードの可読性についてのプレゼンテーション (https://speakerdeck.com/munetoshi/code-readability) を公開しました。 今後、このプレゼンテーションについてのちょっとした解説を、本ブログ上で不定期に連載していきます。 今回は、このプレゼンテーションの概要と、最初の章 "導入と原則" についての解説を行います。 このプレゼンテーションについて このプレゼンテーションは、コードの可読性を向上するためのアイディアをまとめたもので、以下の8つの章からなります。 導入と原則: 可読性の高いコードの重要性、プログラミング原則 命名: 名前の示す内容、文法、語の選択 コメント: ドキュメンテーション、インラインコメント 状態: 状態遷移の管理
Game programming patterns in Unity with C# | Habrador
Introduction This tutorial is outdated, you can find the latest version here: GitHub In this tutorial you will learn everything about programming patterns in Unity with C# code. This is how Wikipedia defines programming patterns: In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a f
AbemaTV コードの品質への取り組み
現在AbemaTVでiOSアプリ開発を担当してます、shoheiyokoyamaです。 本記事では、AbemaTVでの「コードの品質について」チームでの考え方や取り組みについて紹介していきたいと思います。 AbemaTV AbemaTVは、オリジナルの生放送コンテンツや、ニュース、音楽、スポーツなど多彩なジャンルのコンテンツを見れるインターネットテレビでiOS、Android、PCなどで利用できます。 チームにジョインした当初は私を含め5人体制でiOSの開発を進めていましたが、現在は倍の10人体制で開発を進めています。チーム増員に伴い、開発スピードは上がりますがその分コードの品質を維持し続けることが難しくなります。 早い開発スピードを長期的に継続していくためには、高品質なコードを維持することが重要です。そのため、早い開発サイクルの中でも高品質なコードを維持する取り組みが必要となってきます。
Go Web Examples - Learn Web Programming in Go by Examples
I'd like to tell you, that my platform Go Web Examples Courses just launched. Enjoy easy to follow video courses about web devlopment in Go. Make sure to check out the special offer I have for early supporters. We'll see us over there! :) About the Go programming language Go is an open source programming language designed for building simple, fast, and reliable software. Take a look here which gre
私的アンリーダブルコード―他人を発狂させるための 9 のテクニック
コードはたいてい一度しか書かれませんが、何度も何人も読むことになります。 普段何気なく書いているコードが他人の時間と精神を削っているかもしれません。 そんなわけで、個人的に辛いなと思うことを 9 つ挙げてみました。共感してもらえるものもいくつかあるんじゃないかと思います。 実体にそぐわない変数名 見分けの付かない配列とハッシュの変数名 呼び出し元で true/false を指定するだけの引数 暗黙の実行順序 [] メソッドの定義・Array の継承 ハッシュの乱用 密結合した mixin 過剰な nil guard 条件によって異なる返り値の型 推薦図書 静的型付き言語を使うことで解消される問題もありますが、その選択肢はひとまずなしということで。 Ruby 前提になっていますが、他の言語にも言えることも多いと思います。 実体にそぐわない変数名 例えば Vehicle というクラスが定義され
GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します（またはソースコードを丹念に調べます）。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか？ 「誰かが既にこの問題を解決しているはずだ！では、なぜこの問題に対する答えがStack Overflowにないのだろうか？」 そのとおりです。恐らく誰かは既にそれを解決
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try
はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな
私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
シンプルでわかりやすいコードを書くためにあなたがすべきこと - give IT a try
はじめに 先日、とある知りあいのRubyプログラマからこんな相談を受けました。（内容はちょっとボカしてます） 社内のコードレビューでもっときれいなコードを書けるようになった方がいい、と言われました。 「きれいなコードを書けるようになれ」と言われても、具体的にどうすればいいかわかりません。 伊藤さんのアドバイスを聞きたいです。 この内容だけだとどんな問題があるのかわからないので、実際に指摘を受けたRailsアプリのコードを見せてもらいましたが、確かに「もうちょっと頑張りましょう」と思うような点がチラホラありました。 ただ、具体的にどうすればいいの、という答えは一言では言えません。 というわけで、今回のエントリではこの悩みを解決するのに参考になりそうな話をあれこれ書いてみようと思います。 （その前に）もくじ かなり長い記事になってしまったので、先に目次を載せておきます。 はじめに （その前に）
C/C++の静的解析ツール・事例まとめ - 簡潔なQ
C/C++の静的解析は、どう考えても大変なんだけどどう考えても需要が高いので、やはり色々なソフトウェアや事例があるようだ。まとまった情報が欲しいけど見つからなかったので自分の調べた範囲でまとめることにした。 他にも耳寄りな情報があったら教えてほしい。 静的解析を行うことができるソフトウェア 調べてみると結構たくさんある。それぞれの特徴とかあまりよくわからない。 (個人的には、とりわけ網羅的な形式的検証ができるツールの性能に興味があるので、それを中心に集めていたが、やはり網羅的とは限らないで探すともっとたくさん見つかるようだ。もちろん網羅性にはトレードオフがある) Frama-C …… C言語に形式手法を適用するための汎用のフレームワークで、静的検証のためのプラグインも多数(WPとかValueとか)存在する。網羅的な検証から発見的な手法、動的な手法まで様々ある。研究で使うのに便利そう Ast
ソースコードの減らし方 - 基本的な考え方と10個の方法 - クラウドワークス エンジニアブログ
ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね！ 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ
CLI から Wandbox を利用してソースファイルを実行する gem をつくった - Secret Garden(Instrumental)
Web からプログラミングのソースコードを実行できる Wandbox というサイトがあるんですが、それの API を利用してプログラミング環境がなくても CLI からソースファイルを実行する事ができる CLI ツールをつくりました。 インストール $ gem install wandbox ソースコード osyo-manga/gem-wandbox 使い方 wandbox コマンドを使用してソースファイルを実行したりします。 ソースファイルを実行する wandbox run <filename> で <filename> を Wandbox で実行する事ができます。 $ cat test.rb 5.times.each { |n| puts n } $ wandbox run test.rb 0 1 2 3 4 使用するコンパイラを指定する --compiler= オプションで使用するコン
【C++】なぜヘッダと実装はわけるべきなのでしょうか（.hに実装を書くことは邪道か）
私はC++歴3年の学生趣味プログラマーです。 「C++はなぜヘッダと実装を分けなくてはならないのか/そもそも本当に分けなければならないのか」という質問です。 C++といえば、ヘッダー部と実装部を.hファイルと.cppファイルに分けることが一般的とされている言語ですが、 これは同じオブジェクト指向言語のC#やJavaにはない特徴です。 そのせいでC++使いたちは今日もcppファイルとhファイルを行ったり来たりしながらコーディングする羽目になっています。（そしてVS使いはF12とCtrl+-を得意気に連打しています。） 私にとってもそれが当たり前になって久しいですが、 時々C++を学び始めたばかりの後輩から「なぜヘッダファイルに実装を書いてはならないのか」「なぜC++は二度も同じコードを書くことを強いるのか」と質問を受けます。 私はそのたびに「実装の隠蔽化」とか「循環参照の危険が云々」とか「そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C++ Insights
Simple Easing Functions in Javascript - see https://github.com/gre/bezier-easing
GitHub - keon/algorithms: Minimal examples of data structures and algorithms in Python
GitHub - yamafaktory/shrimpit: Shrimpit 🍤 is a small CLI analysis tool for checking unused JavaScript, JSX & Vue templates ES6 exports in your project.
クソコードの測り方
