Skip to content

Instantly share code, notes, and snippets.

@mizchi
Created June 15, 2011 11:16
Show Gist options
  • Save mizchi/1026897 to your computer and use it in GitHub Desktop.
Save mizchi/1026897 to your computer and use it in GitHub Desktop.
原稿
目的を達するためのコーディングに必要なこと
------------------------------------------------------------------------------
最初に言ってしまうと、流行ってる言語は、ぶっちゃけどの言語も似ている
だから、言語にこだわるのは滑稽
言語の癖、とか、コードの臭い、みたいなものはその都度押さえる
なにか1つ手足にように使える言語を持っておけばそれ以外の理解は速い
入門書を一冊読め!
====================
Amazonで (言語) 入門、で検索して☆4.5以上の中から、レビュー読んで肌にあいそうなもの
技術書を買ってレビューするようなエンジニアは非常に素直なので信頼できる
いきなり目的のものに取り組んでも挫折する可能性が高い
最初に網羅的に押さえて、それから取り組んでも遅くはない
※一般に、オライリー(動物の表紙)の入門書は評価が高いのが多いのだけど、脱初心者~他言語経験者向けなので最初は辛いかも
変わることがないプログラミングの最小単位
==================================
- 四則演算
- 条件分岐
- 繰り返し
書き方は色々あれど、「方言」程度の問題
たとえば…
C/Java
for( int i=0;i<10,i++ ){ ... }
Python
for i in range(10): ...
Ruby
(0..9).each { |i| .... }
どれも動作としては同じ(もちろん厳密には異なるのだが、目的を達するのに必要な動作をするという点で同じ)
どうせ覚えてられないから、その都度ぐぐればいい。
〇〇基礎文法最速マスター、を読みましょう(ちょっと前に、ブログでそういうのを書くのが流行った)
現代的なプログラミングのパラダイムを掴む
================================
- オブジェクト志向
- 動的型 静的型
- マルチスレッド( 重い処理をやる人 )
- 正規表現 (テキスト処理をする人)
- W3C 標準 (ウェブをやる人)
◆ オブジェクト指向
構造体がわかる人に説明するなら、構造体に関数がついたもの
クラスは設計図、クラスから呼ばれて、実際に使えるようにしたのがインスタンス
インスタンスを組み立てるのに、一番最初に呼ばれるメソッドを、特にコンストラクタという
◆ Javaはオブジェクト指向を強制する言語
メソッド名、というのは説明的
プログラミングというのは、言語設計者、ライブラリ設計者との擬似対話と捉えてよい
class MyApp{
public static void main(String args){
System.out.println("Hello!");
}
}
MyAppというクラス名で
public(公開された)
static(静的な)
void(返り値のない)
main(main、一番最初に呼ばれることを示す名前のメソッドが)
String[] args ( Stringの配列のargs、オーギュメント、引数を持つ )
System というオブジェクトの
out 外部出力モジュールで
println テキストを貼り付けて(print)改行するln(line)
Javaは非常に説明的な言語 => 他人のコードを読みやすい
Javaで説明したが、他の言語でも同様
動的型 | 静的型
=======================
型、というのはデータの在り方
整数か、小数か、文字列か、たくさんの要素を梱包したものか
クラスもデータの在り方の1つ
◆静的型(C/Java)
int x;
x=3;
「xを整数として宣言し、xは3とする」
型が簡潔で、デバッグが容易。エディタの支援を受けやすい
◆動的型(PHP| Ruby | Python| Perl)
x=3
◆メリット
型は代入時に決定 =>前もって型を宣言する必要なし
Javaのように型をimportする必要がないので、基本的にコーディングが速い
◆デメリット
その変数が何か?は暗黙の了解 xは文字列か?整数か?
動的型の言語ほど、強く型を意識する必要がある!
現在の型から、目的の型へ、いくつもの操作によってデータ型を遷移させながら、目的の結果を導く
それがプログラミング
コーディング規約
============================
言語仕様ではないが、習慣的に重要なもの
コードを読ませたり、他人のコードを円滑に理解するために必要
「一週間前にコードを書いた自分は、別人だと思え」
◆定数(const)は 全て大文字
const double PI = 3.14;
◆クラス名は大文字からはじめる名詞句
class Point{
public int x;
public int y;
}
◆関数名は動詞+目的語or目的動作
public static Point getX(){
return x;
}
よく使われる動詞は get , set (ゲッター、セッターなどと呼ばれる)
英語に関しては、変に色気を出さないほうが読みやすいコードになる
◆関数名はキャメルケースor スネークケース
キャメルケース : 小文字からはじめて、単語の頭を大文字にする
getSomeValues
スネークケース:単語同士を _ で繋ぐ
get_some_values
どっちでもいいが、統一しておかないと余計な混乱を招く
実際には、言語で推奨されるケースは異なる。 Javaは伝統的に キャメルケース
◆ プライベート変数の前に _ を(Python等)
class Point{
public int _x;
public int _y;
}
ソースコード中で一時的変数と区別しやすくする
Eclipse等、エディタの補助があるなら不要なのかも
◆ 変数名の付け方
外部から参照されるものに無意味な名前をつけない a, b, x, t, tmp, buf, data
一時的なものには構わない(という派閥もあるし、そうではないという派閥があるのだが…)
特に、foo , bar , hoge, huga はメタ構文変数と呼ばれ、無意味なものを示す。サンプルコードで頻出。
コメント
=========================
大事なのは「嘘を書かない」こと
メソッド名が効用を充分に表すときは、余計なコメントは不要
個人的には、ちょっと小難しいテクニックを使ったときに、参考元が明記してあると助かる、程度
というのは個人で書く場合で、大規模プロジェクトの場合は、この限りではない
最小要素で書け
=========================
新しいことを一度に1つ以上やらない
バグの箇所がいつでも特定できるようにする
サンドボックス環境を容易
とにかく書き散らして実行するだけの環境を作る
「テストコードを書き散らして、テストを通ったものを本番コードに混ぜる、を繰り返す」
便利な最小ユニットはスニペットとして保存しておく。技術ブログに書いてもいい。(そのようにしてコミュニティに貢献できる)
今までに書いてきたコードは、あなたの資源なので大切にしよう
対話インタプリタが付いてる言語ならインタプリタで最小テスト通すのを推奨(Python|Ruby)
上達のコツはトライアンドエラー
===========================
まずはコピペ
動作確認
エラーが出たら、どこが間違っているか?環境構築に失敗してないか?を確認
エラー文でぐぐる
初心者が間違える程度のことは、とっくに解説しつくされている
字句的にコードを読む。
コピペしてからの部分改変。自分の意図通りに動くかを確認。
デバッグ
===============================
最初はprint デバッグでいい
- エラー起きるている箇所の直前にprintだか何だか(変化が確認できるコードなら可)を挿入
print 文が実行されることで、それ以前のコードが正常に動いてることを保証(非同期、マルチスレッドだと保証されないことに注意)
- エラーに関わる変数をprint
本当に自分の意図通りの値になっているかを確認
ほとんどはこの時点でバグが判明する
メソッド名でぐぐって使い方を確認する
たまにモジュール本体がバグっているので、代替案を探す でも安易にバグとか叫んじゃいけない そういう初心者はコミュニティ全体へ迷惑
デバッグは奥が深いので、以下の単語をググッてください
(言語名) ロガー
(言語名) デバッガ
ユニットテスト
テスト駆動開発
バージョン管理システム
==================================
◆…の前に
副作用のある変更をする場合、あとでバージョン管理システムで管理するにしても、変更前コードを一時的にコメントアウトして作業することを推奨
元コードと見比べながら書くことで、改変後の副作用を最小にすることができる
◆バージョン管理システムの利点
ソースコードの変更履歴を管理する。
互換性がない変更を気軽に行える。
共同開発時に互換性がない箇所を検出できる(コンフリクト)
Git , SubVersion、Mercual、Bazzar
最近の風潮としてはGit一択。Gitを使いましょう。
初心者用チュートリアルを読んで、それから入門Gitを読んでください
ググり方
=========================
一番大事なのは「想像力」
想像力の裏付けに必要なのが「経験」
技術記事だとしても日本語の言語特性に引きづられる
最近戸惑ったもの:Android and (外のリソース|外部リソース| 外部資源)
一番「バズってる」ワードに辿り着くためには?
あなたがそれをブログに書くとしたら、どんなタイトルを付ける?という想像力、センスが必要
◆エラー文を読む。
なにが自分のソースコードに依存してるか?
自分で名付けた変数名、呼び出し元はググっても引っかかるわけない
英語がわかれば直感的にバグの理由がわかる(こともある)
でも「直感」を身につけるには数が必要
トライアンドエラー。短いコードをなんども書く。
技術英語は非常に簡潔
StackOverflow などが引っかかってもちゃんと読みましょう
解説文よりもソースコードの方でわかりあえたりする
◆Google ソースコード検索
公開Github等からのソースコードを検索できる
メソッド名でぐぐれば使用サンプルが出てくる可能性
マイナーなライブラリは、言語本体のソースコードが引っかかることが多いのだけど...
自分が目的とするコード、そこに含まれるであろうモジュールを想像しろ
◆ ドキュメントを読む
内部の動作が充分に理解できるようになったら、ドキュメントを読む。
ドキュメントは非常に抽象的に書かれてることが多いので、言語をちゃんと理解していないと読めないことが多い。
小さなライブラリなら、ソースコードを読んでしまってもいい。
小さな、というのはコードの読解力によるけど、だいたい1000行未満のもの。
質問の仕方
=============================
以上のことをぐぐって、本を読んで、わかることと、わからないことを明確にして、その時に初めて質問するようにしてください
あなたのはまりこんでいる箇所に、質問先の人が精通していることは滅多にないので、内部の動きを説明できるようになってください。
抽象的に「わかりません」「うごきません」では相手をしてもらえません。
以上、それでは楽しいコーディングを!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment