タグ

sourceとprogrammingに関するmanabouのブックマーク (5)

  • なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ - エンジニアHub|Webエンジニアのキャリアを考える!

    なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ システム開発会社「アクシア」の代表として、自社・他社含め、さまざまなエンジニアのコードを読んできた米村歩さん。そんな米村さんの持論は、「コードの可読性は生産性に多大な影響を与える」ということ。可読性の低いコードはどんな弊害をもたらし、どうすれば改善できるのか――。チーム開発を効率化するコードの「可読性」について綴っていただきました。 プロフェッショナルのエンジニアには、「可読性」の高いコードを書くスキルは必要不可欠です。単に目的とする処理が実行できればよいわけではありません。しかし実際の開発業務の中では、可読性は意外と軽視されてしまいがちです。 経験の浅い駆け出しのエンジニアにとっては、可読性の重要さを肌感覚で理解するのは難しいかもしれません。また、新人エンジニアに対してプログラミング言語や開発ツールについて

    なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ - エンジニアHub|Webエンジニアのキャリアを考える!
  • 「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話(補足編) - 土屋つかさの技術ブログは今か無しか

    前回書いた「「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話( 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... )開発スタイルの薫陶を受けているからなのですが、それとは別に「そもそも日人には英語ベースのソースコードを高速に読解するのは無理がある」と考えているからです。 また、より質的な課題があると思っていて、プログラミング業界的には「コードがドキュメントであるべき(≒正しく実装されたコードであれば、コメントは最低限になる)」という風潮がありますが、土屋は、これはプログラマが夢見る幻想に過ぎず、「質的

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

    はじめに この記事は、僕が配属当初に先輩からよく言われた「ソースコードはしゃべるように書け」について、それが具体的に何を意味するのかを、配属から6年経った今改めて考えてみる記事です。 その先輩はすでに辞め新しいステップへ進まれてしまったためにその真意を直接聞き直して確認することはできないのですが、今の僕なりの解釈、ということで書いてみます。 とは言え、「ソースコードはしゃべるように書け」は「ソースコードの読みやすさ」という意味では役に立つ考え方ですが、それがどんな場面でも正しいかというとそうではないと思っています。おそらく、自然言語に近づけた書き方よりも、より機械の仕組みに近づけた書き方をした方がはるかに効率がよかったり、安全な言語や場面もあると思います。 また、仕様自体が複雑だったり、既存のソースがすでに汚いなどの理由で、この記事に書いたようなことがすんなり実行できる環境というもの自体が

    ソースコードはしゃべるように書け - Qiita
  • tokuhirom blog

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

  • 1