You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Common Lisp コーディングスタイルについて 一つの文章は、一つ若しくは幾つかの單語から成り立つてゐるのでありますから、 單語の選擇のよしあしが根本であることは、申す迄もありません。そこで、 その選び方についての心得を申しませうなら、 異を樹てようとするな と云ふことに歸着するのであります。それを、もう少し詳しく、 箇條書きにして申しますと、 一 分り易い語を選ぶこと 二 成るべく昔から使ひ馴れた古語を選ぶこと 三 適當な古語が見付からない時に、新語を使ふやうにすること 四 古語も新語も見付からない時でも、造語、─ 自分で勝手に新奇な言葉を拵へることは愼しむべきこと 五 據り所のある言葉でも、耳遠い、むづかしい成語よりは、耳馴れた外來語や俗語の方を選ぶべきこと 等であります。 谷崎潤一郎 『文章讀本』 先づ始めにお断りしておきますが、 ここで述べるコーディングスタイルを コーディン
This phrase, or the phrase "SHALL NOT", means that the guideline is an absolute prohibition. You must ask permission to violate a MUST NOT. This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore the demands of the guideline, but the full implications must be understood and carefully weighed before choosing a different course. You m
I think EmacsLisp is getting to be a great application base, a really good language and environment to write programs in, not just a fancy editor. A number of people seem to agree and are trying it out. Here's some tips and tricks distilled from my 15 years of using EmacsLisp to help budding Lisp hackers in Emacs. Do use a modern Emacs The latest version of Emacs is 24. It's not added to a whole l
Revision 2.1 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 the top of this document. This document defines formatting and style rules for HTML
Effective Scala Marius Eriksen, Twitter Inc. marius@twitter.com (@marius) Table of Contents Introduction Formatting: Whitespace, Naming, Imports, Braces, Pattern matching, Comments Types and Generics: Return type annotations, Variance, Type aliases, Implicits Collections: Hierarchy, Use, Style, Performance, Java Collections Concurrency: Futures, Collections Control structures: Recursion, Returns,
The essence of pretty code is that one can infer much about the code's structure from a glance, without completely reading it. I call this "visual parsing": discerning the flow and relative importance of code from its shape. Engineering such code requires a certain amount of artifice to transform otherwise working code into working, readable code, making the extra step to leave visual cues for the
Naming : - only lower case letters separated by hyphens except types and protocols should be named in camelcase - predicates ends with ? - destructive functions ends with ! - variables that are meant for be re-binding should have earmuffs - use “_” for names that will be ignored by the code Code Structure : - when there is only “then” clause in a conditional statement use “when” instead of “if
この和訳について¶ この文章は Google JavaScript Style Guide を非公式に和訳したものです. 内容の正確性は保証しません. ライセンスは原文と同じく CC-By 3.0 とします. フィードバックは Issue への登録 , あるいは Kosei Moriyama (@cou929 または cou929 at gmail.com) へ直接お願いします. この和訳のリポジトリは こちら です.
Lisp Users and Vendors Conference August 10, 1993 Tutorial on Good Lisp Programming Style Peter Norvig Sun Microsystems Labs Inc. Kent Pitman Harlequin, Inc. Portions copyright (c) 1992, 1993 Peter Norvig. Portions copyright (c) 1992, 1993 Kent M. Pitman. All Rights Reserved. アウトライン 1. 良いスタイルとは何か? 2. 組み込みの機能に関するヒント 3. ほぼ標準のツールに関するヒント 4. 抽象化の種類 5. 大規模なプログラミング 6. その他 1. 良いスタイルとは何か? 良いLispプログラミングスタイル
前エントリ clojure.lib コーディング規約・訳 から1週間以上がすぎました。 Google Groupsでのディスカッションで合意されたコーディング規約をStuがまとめてアップしてくれました。 Clojure Library Coding Standards | Clojure | Assembla さっそく和訳してみました。 間違いがあればご指摘ねがいます。 ⇒ @manjilab 【和訳ここから】 免責事項: 規則は破られるためにあります。この規約に倣うも絶対のものとして扱わないこと。 規約: 名前と使用法はよく考えて書くこと。RichはJavaにおける既存のコードとの互換性の維持を尊重しています。練習用のコードであればいつまでもいじってられますが、ひとたび名前と使用法が公開されればそうはいきません。(具体的な実装に興味がなく名前と用法だけを見ている利用者が多いですから) コ
Clojure Dev Google groupsで盛り上がっているトピックがあります。 “clojure.lib coding standards: initial draft brain dump Options” Programming Clojure の著者、Stuart Halloway氏が音頭を取ってclojure.lib用のコーディング規約をみんなで決めようというものです。 興味深かったのでStuの提案したルールを和訳してみました。 思いっきり意訳です。間違いがあればご指摘ねがいます。 ⇒ @manjilab (掲示板の流れに合わせていくつかの項目を追加・削除しています) 【和訳ここから】 これは公式でも最終版でもない。議論を誘発するための叩き台です。もし致命的に間違っている項目が含まれていなければ私の手抜きです :-) ルールは破られるためにある。よってどのような規約も絶
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message CLOJURE.LIB CODING STANDARDSDisclaimers and Random Observations: * This is not an official or final list -- intended as provocation for discussion. If some of them aren't dead wrong then I didn't try hard enough. :-) * Rules are made to be broken, so whatever stan
Lisp系はあまりなじみがないので変なクセがつく前に Clojure流のコーディングのガイドラインを調べました。 あまり資料が見つからなかったのですが、 Mark Volkmann氏のページより Clojure Coding Guidelines を和訳してみます。 インデントはスペース2個分。 関数名と変数名は良く考えること。良く使われる略語は避ける。一文字変数名は次の場合だけ:インデックスの i 、デカルト座標系の x, y, z 真偽値を返す関数名は ? で終わる。 コメントを書くよりもコードが明瞭になるように書き直す。コメントはそれができなかったときに残すもの。 一行に登場する関数は5つまで。 関数定義の際のネストは4段階まで。これを守るためにはローカル変数で中間値を保持したり、別の関数に分割する必要もでてくるだろう。 匿名関数は1行で収まる簡単な定義のみに使う。それ以外はプライベ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く