タグ

commentに関するxai1981のブックマーク (11)

  • SQLのコメントを削除する | ymda blog

    やたらめったらコメントが入ったSQLを読む機会があったので、SQL中のコメントを削除するコマンドをメモしておく。 ––コメントを削除 :%s/--.*$/ /* */コメントを削除 :%s/¥/.*¥/ ついでにタブをスペースに変換 :%s/¥t/ /g ついでに空行の削除 :g/^$/d

    SQLのコメントを削除する | ymda blog
  • MySQLのコメント構文 - Qiita

    と記述すると、他のSQL文同様に実行されます。 この記述は!の後に「32302」のようにバージョンを記載すると、 指定したバージョン未満のMySQLでは無視されます。 32302の場合は、MySQL 3.23.02以降でなければ無視されるわけです。 また、MySQL以外のDBでこの構文を使うとコメントとして解釈されるため、 MySQL特有の構文を除外するために使用できます。 例:/**!40101 SET NAMES utf8 */; mysqldumpで生成されたダンプファイルがよいサンプルとなるかと思います。 (実際私はそこで気になって調べました。) mysqldumpのダンプファイルを見るたびに、 気になっていましたが調べてみたらすっきりしました。 参考URL: http://dev.mysql.com/doc/refman/5.1/ja/comments.html

    MySQLのコメント構文 - Qiita
  • Coding guidelines

    STOP READING IMMEDIATELY THIS PAGE PROBABLY DOES NOT PERTAIN TO YOU. These are Coding Guidelines for Contributors to TypeScript. This is NOT a prescriptive guideline for the TypeScript community. These guidelines are meant for contributors to the TypeScript project's codebase. We have chosen many of them for team consistency. Feel free to adopt them for your own team. AGAIN: This is NOT a prescrip

    Coding guidelines
  • Create JSDoc Comments for JavaScript IntelliSense - Visual Studio 2015

    This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

    Create JSDoc Comments for JavaScript IntelliSense - Visual Studio 2015
  • 「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話(補足編) - 土屋つかさの技術ブログは今か無しか

    前回書いた「「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話( http://d.hatena.ne.jp/t_tutiya/20170519/1495197904 )」は土屋のブログ記事にしては珍しくはてブやコメント、twitterで反響を幾つか頂きました。その中の幾つかを紹介します。分かっているとは思うけど、サンプルコードはJavaScriptを意識してますがてきとーです。 案1:マジックナンバーを定数化する MAX_OPAQUE = 1.0f //定数宣言のつもり if (alpha < MAX_OPAQUE){ //処理A } "1.0f"に意図を設定すればコメントが不要なのではないか説。うーん、これはちょっと難しいかな……。"MAX_OPAQUE"が正しい変数名だとは思えませんが、どんな名前にすれば意図が説明できるのかちょっと思いつきません。また、数式が複雑

    「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話(補足編) - 土屋つかさの技術ブログは今か無しか
  • 「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話 - 土屋つかさの技術ブログは今か無しか

    土屋はプログラマの中でもかなりコメントが多いタイプだと思っています。理想を言えばコード1行ごとにコメントを書きたいくらいです(当は、識別子を全部日語で書きたいと思っているのですが、これはまた別の話)。 これは土屋がPDL(Program Design Language https://www.gamedev.net/resources/_/technical/general-progra... )開発スタイルの薫陶を受けているからなのですが、それとは別に「そもそも日人には英語ベースのソースコードを高速に読解するのは無理がある」と考えているからです。 また、より質的な課題があると思っていて、プログラミング業界的には「コードがドキュメントであるべき(≒正しく実装されたコードであれば、コメントは最低限になる)」という風潮がありますが、土屋は、これはプログラマが夢見る幻想に過ぎず、「質的

    「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話 - 土屋つかさの技術ブログは今か無しか
  • JavaScriptのコメントは不要か? | POSTD

    コード中にコメントを書くべきでしょうか? 是が非でも避けるべきでしょうか? それとも控えめに書けばいいでしょうか? 開発者たちはそれぞれ、ソフトウェアを開発する際にどのように、そしてどんな時にコメントを書くかについて、独自の考え方を持っています。この記事では私の意見を述べますが、これが誰にも当てはまるというわけではありません。 なお、関数型プログラミングまたはオブジェクト指向プログラミングの原則に則ってJavaScriptで書かれたソフトウェアに絞った上で、私の意見を述べることにします。 コメントと保守性 この記事では、保守性のあるコードを書く場合について考えます。つまり、以下のようなコードです。 簡単に理解できる 簡単に拡張できる 簡単にデバッグできる 簡単にテストできる 保守性のあるコードには、大量のコメントが必要でしょうか? 明確に書かれたコードであるならば、大量のコメントは不要だと

    JavaScriptのコメントは不要か? | POSTD
  • いまさら聞けない「コードの英語」超入門 - クックパッド開発者ブログ

    広告事業部の鈴木達矢です。コーディングをしてると変数やメソッド名の付け方に悩むことって多々ありますよね。逆にコードを読んでいると単語の選択がこれでいいのかなという時や、動詞の活用形が間違っていてよく意味がわからない、時に潔く日語の変数名になっていることも見かけます。でもプログラミング言語の単語が英語をベースにしていますし、Railsを使っている場合は日語が規約(Convention)に合わなかったりします(複数形が無いなど)。それから動詞の活用形が違っていると主語(動作の主体)が変わってしまい、意味が変わってしまいます。その結果コードの可読性が落ち混乱を招きやすくなります。 いくつかの基的な法則だけおさえておけばコーディング中に可読性の高い単語の選択ができるようになります。今回はそれを目的に、英語の扱いに都度時間を費やしてしまうような方に向けていくつかの法則をご紹介します。*1 変数

    いまさら聞けない「コードの英語」超入門 - クックパッド開発者ブログ
  • Gitのコミットメッセージの書き方 | POSTD

    (訳注:2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注:2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳: プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション:なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest

    Gitのコミットメッセージの書き方 | POSTD
  • if elseのコメントの書き方 - アーキテクチャをスマートに。

    プログラミングの話題です。 if〜else構文のコメントを書くときって、みなさんどのように書きますか? 単純 if 文の場合 単純if文の場合は、ブロックの直前に書くことがよくあると思います。 例えば、C系の言語で言うと以下のような書き方です。 // ゼロの場合 if (value == 0) { funcA(); } たまに、ブロックの中にコメントを置く人も見かけます。 個人的には好きじゃないですが、まぁそんなに目くじら立てて言うほど悪い書き方でもないと思います。 if (value == 0) { // ゼロの場合 funcA(); } if else の場合 では if else の場合はどうなるかというと、それぞれのブロック内にコメントを置くのが普通だと思います。 ブロックの直前には、if else 全体の説明となるコメントを書いたりします。 (コメントの内容はともかく、位置に注目

    if elseのコメントの書き方 - アーキテクチャをスマートに。
  • Gitのコミットメッセージの書き方 - Qiita

    Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 (2014年12月17日追記) 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど!と思ったコメントをもとに少し修正・加筆してみました。 (2022年1月4日追記) 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目:変更内容の要約(タイトル、概要) 2行目 :空行 3行目以降:変更した理由(内容、詳細) 日語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 (多すぎても悩むので

    Gitのコミットメッセージの書き方 - Qiita
  • 1